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

Wed Nov 3 18:47:05 UTC 2021

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.

> If there isn't a problem, trying to organize the stated issues into actual
> solutions would make that clearer.

I really struggle to understand what you are trying to say here. Could you
rephrase or elaborate, please?

> 
> 
> > Finally, I would like to contest the assertion that users would need "a lot of
> > local package updates for security fixes" in order to keep a secure system:
> > looking at the open security issues in [1], the vast majority of these are
> > unresolved upstream, so no package update will solve them.
> 
> This is a very mild microcosm of my experiences with Arch Linux, and why a
> thread about "a plea for communication" speaks to me. I installed Arch for
> the first time when I did something unspeakable to a macbook and needed
> something until I fixed it. Not too long after that every device I could
> make run Arch was running Arch. Technically, it's simple and magnificent.
> 
> Yet, as soon as a person is involved simple goes out the window. Most of my
> interfaces with the Arch team have always been challenging, and every time I
> dip my toe in I end up having someone "contest" what I'm saying in varying
> degrees.   The only major package I maintain in AUR happened because I
> accidentally offended the TU who was maintaining the package.

I am genuinely sorry to hear that your experiences with staff members have been
less than ideal in the past. For the record, the statement that I disagree with
were not even your words, I was just replying to your email because you brought
up the "how to organise security updates" aspect that I wanted to illuminate
with my last email, so that felt the appropriate place to reply to.

> There are a lot of unspoken rules to the Arch Linux community. More than I'm
> used to from a volunteer organization and I work 100% in the volunteer
> space.   Thus far I have been unable to navigate it.   Since Arch continues
> to make good technical decisions-- even when I disagreed with those
> decisions-- I decided to keep using it and just keep my trap shut.

I agree that we could do far better regarding documentation on how to get
involved. I would not go as far as to call these "unspoken rules", Arch simply
has far less hard and fast guidelines than other projects, for better or worse.
I completely understand that this can intimidating and sometimes even prohibit
contribution. Therefore the goal of my last email was explaining possible ways
to take part in order to lower this barrier. If you have more questions in that
regard, please do not hesitate to get in touch! The vast majority of team
members I had the pleasure of interacting with have been welcoming and helpful
to work with.

> When someone else seemed like they were facing the same issues I was, I
> decided to speak up. [...]

Again, I want to make clear that I am not trying to invalidate your - or
anybody else's - opinion that there is no really clear-cut way towards
contributing to Arch. I am trying to fill this gap in documentation by
providing ways to contribute, in this case to the security team.

> Nonetheless, you do good work and I thank you for it.

Thank you, on behalf of the Arch team! :)

Cheers,
Jonas

-- 
Jonas Witschel
Arch Linux Developer, Trusted User and security team member
PGP key: FE2E6249201CA54A4FB90D066E80CA1446879D04
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20211103/333ef812/attachment.sig>