Skip to content

Communities on gitlab.postmarketos.org

There are quite a few SoC or device specific organisations hosted on GitLab.com and GitHub.com, where folks have independently organised to maintain patched Linux support for specific devices. See https://wiki.postmarketos.org/wiki/SoC_Communities for details.

Depending on our runner capacity, it would be nice to allow these communities to join us over on gitlab.postmarketos.org if they want to.

Currently, these SoC communities operate entirely outside of pmOS, they have their own organisations and ways of solving problems, as well as often having their own channels and users. This has lead to some siloing (where one group solve a common problem, but others don't know about it -- e.g. building nightly images for testing new device ports, automated merging of stable kernels, etc). Currently, postmarketOS doesn't really have a place for this kind of information to be shared.

Having device/soc communities be a core part of gitlab.postmarketos.org would let us improve visibility for them, level the playing field with shared access to runners and such, and make it easier for folks to participate in these different communities without having to traverse git forges.

Proposal outline

In-keeping with our efforts to on-board more people as postmarketOS developers, I think we have a fairly unique opportunity to try something new -- unifying permissions.

By moving all SoC communities under a common namespace, we can grant folks who are trusted members of the community (they maintain support for some soc/device) developer access across the namespace, and of course maintainer access for the subgroup they maintain. This is quite similar to the approach taken by GNOME in giving foundation members access to their GitLab. It reduces the hierarchy and removes the technical barriers for someone to take over maintainership of an otherwise dead project, by assuming some basic level of trust and making it purely a social issue. The idea is basically that if you can be trusted to maintain/develop software for the community, you can be trusted not to push to some other project without first talking with the maintainer.

Implementation

We already have a solid process for folks to get push access to most of the postmarketOS repos (with the exception of pmOS stable), this (as the name implies) requires a level of trust, and this model was actually largely based on GNOME's approach.

We can simply put soc/device communities under the pmOS namespace (e.g. gitlab.com/postmarketos/qcom-sdm845), and give device maintainers maintainer permission (and developer permission for the whole postmarketOS namespace). We can expand the Trusted Contributor role to include device maintainers.

Note that this would not imply that device maintainers should merge pmaports MRs (or push to any other pmOS repo), it just turns the question into a social one and not a technical one (if you've been around for a while and maintaining some device, and you want to start reviewing other MRs and eventually merging them, this model would make it trivially easy for you to do so, if you start leaving good reviews and approvals someone will eventually ask you to start merging as well).

In general, I think this model of reducing the technical barriers for participation, and leaning more on the community and social norms to gain "permission" to push/approve/merge to various parts of the project is a net positive. I think the GNOME project have demonstrated that this approach can work, and I think we should adopt it.

As for onboarding, once we have decided what requirements make sense for device maintainers to become trusted contributors (or if we use a different label, whatever), we can then invite folks to open an issue (with the TC template or similar), mentioning where their group lives currently and what scope it is, so we can create a new subgroup and give them access.

Permissions

The maintainers of a particular org will keep maintainer access, this would only be lost if they become inactive for a long time and someone else begins to take over the project.

Naming scheme

I would suggest using the scheme <vendor>-<family> for the groups, where vendor is qcom, mtk, amlogic, etc, family is either the device, soc, or wildcard as appropriate (e.g. sdm845, sm7x50, etc), we can take these on a case-by-case basis.

I'd like to get feedback from the team about this, as well as from device/SoC community maintainers, is this something you'd be interested in?

List on interested communities

Please leave a comment linking to the community you maintain to be added.

Edited by Administrator
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information