Dear Christian, Thank you for your email. On Sat, 01 Jun 2019 at 19:08:30, Christian Rebischke via arch-dev-public wrote:
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.
I do not share your point of view that the organization is chaotic. You successfully explained the three roles and each of its duties within two or three clear sentences. We could certainly have a more fine-grained hierarchy but our team is not very big and I personally do not think the benefits would outweigh the extra administrative work in the long run. Do you have any concrete evidence that adding more bureaucracy would benefit the project? Any evidence that our current organizational structure prevents people from contributing (which you seemed to imply with your statement above)?
- How to be a developer?: The developers will decide in a non public and secrete ritual who is worthy to be a developer. The process is unclear.
As Gaetan already mentioned, the process is clear: somebody suggests a new developer and we discuss until a consensus is reached. Feel free to document that somewhere in our wiki if you think it needs to be documented. If you have specific concerns with that process, feel free to share them. However, I do not think anybody in the dev team ever had any objections against that procedure.
- 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).
The idea of having a separate repository for (most) proprietary sounds sensible to me.
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)
Is there any hidden suggestion here?
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).
I am confused. You are saying we are mixing too many roles above and suggesting to reduce the number of roles now?
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".
We made the process transparent already. Again, feel free to document it in a more "accessible" place. If you think these discussions should be public, please explain why. Most of the time, it is just a suggestion and a bunch of "+1", so nothing exciting there. And *if* a developer ever brings up a concern with somebody not being suited for the team due to, say, personal concerns or inappropriate behavior, I guess that candidate would prefer having that issue discussed in private.
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'.
Does not sound like a bad idea to me. Feel free to create a draft. Best regards, Lukas