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.
