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