[arch-general] Fwd: A plea for communication from Arch devs & maintainers

[Archange]

Le 03/11/2021 à 22:47, Jonas Witschel via arch-general a écrit :
> On 2021-11-03 10:46, Sam Mulvey wrote:
>> On 11/3/21 03:42, Jonas Witschel wrote:
>>> Opening a bug report with the necessary information is very simple,
>> With as much respect as I can textually apply, I would not describe the
>> description that follows as "simple."
> With "simple", I was referring to the fact that you do not have to find the
> security issue and think of an appropriate text for the bug tracker yourself,
> that part is all automated. The only thing the user needs to provide is a
> suggestion on how to actually fix the issue. Yes, this can be hard if there is
> no upstream release with a fix available, but that is exactly the issue with
> external contributions:
>
> It is one thing to know that a package is out of date. To this end, it is
> possible to flag packages for the maintainer's attention. This is useful since
> Arch does not have a central version update checker, so it is up to the
> individual maintainers to keep track of upstream updates.
>
> However, what people often do not realise (which is certainly not their fault,
> but probably stems from unfamiliarity with the packaging ecosystem) is that
> bumping the version number in a PKGBUILD is *not* the hard part. What takes
> time is actually building, testing and releasing the updated package.
> Unfortunately, Arch is not in a position to automate these tasks yet, so this
> has to be done by the individual maintainers in the (often limited) time they
> are able to afford to spend for Arch.
>
> This does not mean in any way that external contributions are not welcome!
> Updating and testing an outdated package yourself locally can be a great place
> to start. If you experience any issues, like having to apply patches, test
> suite failures that you need to overcome etc., opening a bug report for these
> is highly welcome! Even if you do not experience issues, mentioning the fact
> that you have built and tested the updated package yourself in an out-of-date
> flag is useful since it helps the maintainer evaluate the danger of breakage
> when upgrading the repository package.

Thanks Jonas, you wrote the mail I wanted to sent. :)

I’d like to emphasize that contributions are welcome, even in the bug 
tracker as long as they are not trivial changes that don’t bring value. 
Of course this is less ideal than something like Gitlab MR/GitHub PR 
(though some people are working on this), but it gets the job done when 
people put the time to properly formulate and explain their changes. ;)

What is not welcome is a simple pkgver bump, because as Jonas said this 
is not the hard part*. What is welcome is a well researched ticket, 
explaining the issue/possible improvements, linking upstream 
commit/tickets/etc. where relevant, and explaining how to address the 
situation (by e.g. eventually providing a diff). Two good somewhat 
recent examples: https://bugs.archlinux.org/task/70106 and 
https://bugs.archlinux.org/task/72544 (note, this is also a way to get 
yourself known by dev/TUs and eventually becoming one of us, we would 
recruit loqs if they wanted — but they don’t).

All that being said, we certainly do lack human resources, helpful 
contribution guidelines, etc., all types of area we are trying to 
improve. They are great projects in the working that should simplify the 
work of Arch maintainers and the inclusion of external contributions a 
lot, but since most of us have so little available time we are able or 
willing to spend on Arch (remember we all have lives, and that none of 
us get paid for working on Arch), things are advancing slowly (and I 
won’t blame anyone for this, as for one Arch would not be getting much 
more of my free time until I get substantially more).

Regards,
Bruno/Archange

*: Although quite an extreme example by the amount of changes versus the 
amount of the maintainer available free time (me), it took me roughly a 
year to have enough of it to look deeply into vtk9 changes, package the 
dependencies, solve multiple issues (including several PR in different 
upstream projects). While a vtk9 package was available in the AUR, it 
did not provide most of the features, and certainly did not take into 
account several of the issues we had while rebuilding dependent 
packages. I was asked several times by people why I did not bump yet, I 
explained the issue and how people could help, but then it seems people 
realized this was difficult because I did not get further answers.