On 6/1/19 7:08 PM, Christian Rebischke via arch-dev-public wrote:
Hello everybody,
---------------------------- DISCLAIMER: Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. ----------------------------
inspired by the last thread about moving proprietary software to community, our general problem of getting more people involved in Arch Linux and the (for me) chaotic organisation structure and hierarchy I would like to propose a discussion about changes.
Please don't see this thread as an attack on your current position or whatever.
I would like to propose a more democratic, simplified and more contribution friendly approach for our current hierarchy and organisation structure.
At the moment we have the following three Groups (If I miss something feel free to correct me):
- Devs - Trusted Users - Support Staff
These three groups have the following 'features' and tasks:
- Devs: - Tasks: The developers care about [core] and [extra] repositories, they form a direction for the whole project 'arch linux' and they seem to have a veto-permission for TU decisions. Furthermore they have access on most infrastructure and they are maintaining/developing the core software like pacman. Some devs also care about trademarks, legal requests and finance or community events.
Core software like pacman... no one maintains pacman except for Dave, Allan, and Andrew. Being a dev does not give you authority to maintain or develop core software, being the appointed caretaker of core software gives you that authority. I'm a frequent contributor to pacman, despite being only a TU. I, a TU, am also the maintainer and developer of a different core infrastructure -- dbscripts. This is mainly because I volunteered to do so. Jouke Witteveen is the maintainer and developer of netctl, which is apparently our blessed networking utility and even distributed in [core] and as part of the official installation media and install process (not to knock his great work, but I still don't understand this choice :p as my attempted bug report to add networkmanager to the archiso should prove). Jouke is neither a TU nor a Dev, his only responsibility to the Arch Linux project is as the netctl project lead. On the topic of infrastructure, there are currently 37 Developers, and a mere 9 of them have access to the infrastructure. I'm not positive about this, but think one or more of these 9 may have been there since before being accepted as a Dev. The 10th person with infrastructure access does happen to be a forum moderator, but is not a Dev or a TU, and seems to be happy with his current level of contribution (which is admittedly mighty).
Therefore I would like to propose a discussion around the following things:
1. Simplified repositories
Currently we have [core], [extra] and [community]. These three repositories are there, because they have grown to this structure over time. At the moment I don't see any real meaning for the split of [core] and [extra]. So one suggestion would be to either: - merge [extra] and [core] - or use [extra] for a new purpose, like for example a proprietary repository, for all proprietary software. (I know that this is not possible for all packages, because we have binary blobs in device drivers and kernel modules).
Nope nope nope. The division between [core] on the one hand and [extra]/[community] on the other, is described here: https://wiki.archlinux.org/index.php/Official_repositories#core And there's pretty good and inviolable reasons for the split -- it makes no sense to try merging it with anything else. It's unrelated to who has access to package there -- but it does make some sense to restrict packaging for [core] to the core project Devs. Whether the split between [extra] and [community] makes sense is another topic, one which could, I guess, be argued. In that case, it's a lot more accurate to describe it as "two repos that are mostly similar in terms of what software goes there, with nebulously defined boundaries except for the former being restricted to only Devs".
2. Repository access
At the moment a TU can access all packages inside of the [community] repository. Therefore they are able to modify packages in a good or bad manner. This can have nice effects and bad effects, how the past has shown to use, such as: - rapid updates in case of security vulnerabilities (good effect) - updates of packages, because somebody thought it needs an update, but the real reason for the delay was a bug inside of the new version of a software (bad effect)
I'd *probably* argue that "somebody thought it needs an update" is not really a wonderful reason to bump someone else's package without at least trying to contact them and e.g. ask "can I bump this and help you comaintain it, because I use it and would like to help take care of it".
3. Organisation structure
Depending on the repository access, we could reduce our organisation structure to just two groups: Devs and maintainers (a similar approach to big distributions like Debian). Devs could still have the 'superpower' for caring about infrastructure and legal/finance stuff and the group of trusted users and support staff would merge to one group of maintainers. With person-related access to package repositories we could tear down the whole repository structure to one, maybe two, repositories and we could give co-maintainership an actual meaning (permission to modify a foreign package).
Not sure I quite understand why support staff and maintainers need to be merged, though. For example, just because someone is given keys to the wiki doesn't automatically mean you also want to give them access to a packaging role.
4. More transparency
At the moment the recruiting process for developers is pretty unclear, as well as the actual decision making inside of the developers group, veto permissions and other things. This leads to a 'they vs/with us' thinking and makes it difficult to increase contribution in the community. Therefore I would like to propose more transparency for all groups who are involved in Arch Linux development and more communication between devs and TUs. At the moment the devs will mostly say:"Ok, this is a TU thingie, so I don't need to get involved in this question regarding TU rules or rules for community or anything else".
Which sort of makes sense, I guess, at least inasmuch as a Dev can also be a TU and there are a number of people who are both, because theu're interested in and involved in TU thingies.
It would be also nice to form an actual roadmap (yes.. I know.. we are not a company, but a roadmap or overview over all current projects inside of our community would be nice). This way it would be also easier to contribute for 'outsiders'.
Roadmaps sound neat, but the question becomes "what to put in them". :p Very often, when someone has an itch to scratch about something that needs to be done, they just do it. Do-ocracy at its finest. :) That being said, I guess this would be a good time to remind everyone... we now have a Kanboard for "general" issues pertaining to making Arch Linux better: https://kanboard.archlinux.org/public/board/964f9d8069094e955512b8edf75d2bb4... Anyone who wants access to this board should please contact the devops team for a kanboard account. -- Eli Schwartz Bug Wrangler and Trusted User