Hi!
The working group has been working on a proposal for the Alpine Linux
governance. Before we post any suggestions we'd like to try define and
agree on current state and current problem, so we avoid discussions
which are trying to solve different problems due to disagreement what
the problem is.
Richard Mortier has written down the current state, the problems and
what features we want.
Do you think this is a good description of the current state, current
problem and desirable features?
Thanks!
-nc
# Alpine Community Governance
Per the [website](https://alpinelinux.org/about), "Alpine Linux is an
independent, non-commercial, general purpose Linux distribution
designed for power users who appreciate security, simplicity and
resource efficiency". The Community exists to support the Project which
develops the Distribution, and adheres to a [code of
conduct](https://alpinelinux.org/community/code-of-conduct.html). While
successful so far, problems are becoming apparent as the popularity of
the distribution increases, primarily due to heavy reliance on Natanael
(`@ncopa`), the project lead.
This note describes the current governance practices of the Community,
attempts to describe known problems with that practice, and suggests
some features that the Alpine Community might find desirable in any
evolution of its governance structure. It draws directly and indirectly
on many sources including the draft statement of the project [goals][],
and both the [interim][] and [draft][] new governance proposals.
[goals]: https://beta.docs.alpinelinux.org/governance/0.1a/index.html#_project_goals
[draft]: https://beta.docs.alpinelinux.org/governance/0.1a/index.html
[interim]: https://wiki.alpinelinux.org/wiki/Governance
Particular thanks to Natanael, the Governance Working Group (Allison
Randall, Kevin Daudt `_ikke_`, Richard Mortier `mort___`), William
Pitcock, and Chloe (`@SpaceToast`) have all fed into this.
## Current Practice
In effect, Natanael is Benevolent Dictator with overall responsibility
for everything. Everything includes but is not limited to:
- Team coordination and membership
- Security incidents
- Release engineering
- Governance
- Package maintenance
- Build server infrastructure
- Kernel work
- Sub-projects including abuild, boot scripts, alpine installer etc
- Docker base images
- Recruiting
- Conflict resolution
- Social media presence, marketing
- Quality assurance and testing
In some of these responsibilities he is supported by the community,
e.g., the many package maintainers take responsibility for maintaining
their own packages, but that support is often informal and
responsibility ends up reverting to him. In a handful he is more
formally supported by teams that have been formed:
- The _Core Team_ comprises those with commit rights to `aports/`,
currently around 13 people.
- An informal _Infrastructure Team_ comprising Carlo Landmeter
(`@clandmeter`), Kevin, and Drew DeVault (`@ddevault`) looks after
the Alpine Linux infrastructure (MQTT, build servers, git servers,
mailing list, patchworks, etc).
- A _Documentation Team_ comprising Chloe (`@SpaceToast`) looks after
maintaining and updating the Wiki and other documentation.
Team additions occur by "lazy consensus" -- nomination is accepted once
two or more team members indicate support. In practice, neither team
changes very frequently (perhaps the Core Team slightly more often than
the Infrastructure Team), but when changes are required, the team comes
together to discuss proposed additions, until consensus is reached. If
no consensus is reached then the proposed change is blocked until
consensus can be reached.
Team departures have occurred over the years for a variety of reasons,
with the departing individual sometimes later returning. In practice
the only person who can eject someone from a team is Natanael; this has
only very rarely actually happened.
In recent months, a distinction has become apparent within the Core
Team: while all members have the commit rights to maintain packages,
some are no longer actively participating in any other community
activity (e.g., replying to emails).
In the end, in practice, most decisions are ratified by Natanael before
being enacted anyway.
## Problems with Current Practice
There are undeniable problems with the current approach:
- It doesn't scale well as Community size increases (Natanael is
increasingly a bottleneck).
- It doesn't scale well as team size increases (risking either
increasing difficulty to reach consensus if the number in support is
increased, or risking fragmentation of the team if the size increases
while support from only two is required).
- It isn't always transparent (public and private discussions take
place via IRC and email, making it sometimes difficult to track
what's happening as well as making it difficult for newcomers to
understand practices and participate).
## Desirable Features
The governance processes of the Alpine Linux Community will need to
evolve over time, as the Community grows and as problems are
encountered and overcome. The underlying principles of the Project are
referenced above; in support of these, governance mechanisms should be:
- **Transparent**. That is, documented and designed to take place in
the open, in full view of the Community as far as possible.
- **Lightweight**. Although the Community has recently grown, and this
has triggered the need for a more formal governance structure, the
Community is still small enough that largely informal discussion and
consensus building is a satisfactory way forward for most day-to-day
matters. If growth continues to the point the more heavyweight
processes are needed, that bridge should be crossed at that point --
it would be (at best) distracting to try to write down strict rules
that cover all possible eventualities at this stage.
- **Evolvable**. Whatever processes are instituted now, they will
surely need to change. They should do so in ways that adhere to the
above two properties (Transparent; Lightweight), and which enable
further future evolution.
On Fri Oct 18, 2019 at 11:17 AM Natanael Copa wrote:
> Do you think this is a good description of the current state, current> problem and desirable features?
Yes.
Moving a discussion from IRC to the ML:
One easy way to improve the core team's bandwidth would be a simple git
hook which allowed anyone to push changes to packages for which they're
listed as the maintainer. This reduces the core team's workload to
dealing with new packages, new maintainers, etc; but removes the burden
of dealing with every change to aports.
> Moving a discussion from IRC to the ML:> > One easy way to improve the core team's bandwidth would be a simple> git> hook which allowed anyone to push changes to packages for which> they're> listed as the maintainer.
Hm, although that does sound like it'd significantly lessen the
workload on core member I dislike this approach, at least with how we
currently handle maintainership of packages. About everyone can become
a maintainer (which is a good thing IMHO since this allows people
knowing the package well but not Alpine's packaging process to be a
maintainer) as of now and I feel like it'd be best to have someone look
over the changes of maintainers which aren't that experienced with
Alpine's packaging process yet. Maybe just having somewhat strict CI
rules and only allowing a merge if CI passes would do the trick to
ensure QA is done though.
> This reduces the core team's workload to> dealing with new packages, new maintainers, etc; but removes the> burden> of dealing with every change to aports.
On Sunday, 27 October 2019 14:42:20 CET Rasmus Thomsen wrote:
> > Moving a discussion from IRC to the ML:> > > > One easy way to improve the core team's bandwidth would be a simple> > git> > hook which allowed anyone to push changes to packages for which> > they're> > listed as the maintainer.> > Hm, although that does sound like it'd significantly lessen the> workload on core member I dislike this approach, at least with how we> currently handle maintainership of packages. About everyone can become> a maintainer (which is a good thing IMHO since this allows people> knowing the package well but not Alpine's packaging process to be a> maintainer) as of now and I feel like it'd be best to have someone look> over the changes of maintainers which aren't that experienced with> Alpine's packaging process yet. Maybe just having somewhat strict CI> rules and only allowing a merge if CI passes would do the trick to> ensure QA is done though.
Then you have the problem that some packages take more time to compile than
the CI allows. For example CI time had to be increased for my fork in Gitlab
as I push KDE and Plasma changes, which almost all the time take more than 1
hour to complete. I don't think it's feasible to manually increase the set
time for every person's fork that needs it.
> > This reduces the core team's workload to> > dealing with new packages, new maintainers, etc; but removes the> > burden> > of dealing with every change to aports.
On Sun Oct 27, 2019 at 4:42 PM Bart Ribbers wrote:
> Then you have the problem that some packages take more time to compile than > the CI allows. For example CI time had to be increased for my fork in Gitlab > as I push KDE and Plasma changes, which almost all the time take more than 1 > hour to complete. I don't think it's feasible to manually increase the set > time for every person's fork that needs it.
FWIW, builds.sr.ht's limit is 4 hours and I think that we could manage
almost all builds under that deadline.
Rasmus Thomsen <oss@cogitri.dev> wrote:
> Hm, although that does sound like it'd significantly lessen the> workload on core member I dislike this approach, at least with how we> currently handle maintainership of packages.
To move my discussion contribution from the IRC to the ML: IMHO we
should rethink the aport maintainer role in general. Many package
maintainer comments are horribly outdated and contain contact
information of people who haven't committed in the past few years. Some
packages (even in main/ and community/) don't even have a maintainer
comment.
Even packages with accurate maintainer comments are often poorly
maintained, by the person maintained in the maintainer comment, i.e.
updates are done by different developers et cetera.
In my ideal scenario package upgrades would always be done by the
maintainer (would also reduce the patch queue as trivial package
upgrades are no longer part of it). It should also be possible to
contact the maintainer regarding issues with the aport and the
maintainer should be responsible for reviewing patches submitted to
GitLab/GitHub/Patchwork.
Currently, the maintainer is just some person who added their contact
information to the aport at some point in time. Debian, for instance,
has a very elaborate process for this sort of thing which might help
avoiding some of these pitfalls [0].
> Maybe just having somewhat strict CI rules and only allowing a merge> if CI passes would do the trick to ensure QA is done though.
I disagree, I don't think CI rules can ever be good enough to catch any
sort of mistakes that a manual review might find. Also consider
malicious patches added to an aport, et cetera.
Cheers,
Sören
[0]: https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer
On Sun, Oct 27, 2019 at 11:44:02AM -0400, Drew DeVault wrote:
> On Sun Oct 27, 2019 at 4:42 PM Bart Ribbers wrote:> > Then you have the problem that some packages take more time to compile than > > the CI allows. For example CI time had to be increased for my fork in Gitlab > > as I push KDE and Plasma changes, which almost all the time take more than 1 > > hour to complete. I don't think it's feasible to manually increase the set > > time for every person's fork that needs it.> > FWIW, builds.sr.ht's limit is 4 hours and I think that we could manage> almost all builds under that deadline.
FWIW, we can increase the limit as much as is necessary. The limit is
just there to prevent stuck jobs keeping hold of the runners for too
long.
At least we can discus about some git hooks that easing maintainer PR's on testing repo. Since testing repo is enabled by user and regarding the purpose of this repo, this could be a feasible idea in my opinion.
On Sunday, October 27, 2019, 4:42:45 PM GMT+3, Rasmus Thomsen <oss@cogitri.dev> wrote:
> Moving a discussion from IRC to the ML:
> > One easy way to improve the core team's bandwidth would be a simple> git> hook which allowed anyone to push changes to packages for which> they're> listed as the maintainer.
Hm, although that does sound like it'd significantly lessen the
workload on core member I dislike this approach, at least with how we
currently handle maintainership of packages. About everyone can become
a maintainer (which is a good thing IMHO since this allows people
knowing the package well but not Alpine's packaging process to be a
maintainer) as of now and I feel like it'd be best to have someone look
over the changes of maintainers which aren't that experienced with
Alpine's packaging process yet. Maybe just having somewhat strict CI
rules and only allowing a merge if CI passes would do the trick to
ensure QA is done though.
> This reduces the core team's workload to> dealing with new packages, new maintainers, etc; but removes the> burden> of dealing with every change to aports.
On Mon, 2019-10-28 at 03:31 +0000, Taner Tas wrote:
> At least we can discus about some git hooks that easing maintainer> PR's on testing repo. Since testing repo is enabled by user and> regarding the purpose of this repo, this could be a feasible idea in> my opinion.>
Sure, that _could_ be feasible but IMHO we don't have much of a problem
with the review queue of packages for testing and community, most stuff
that rots is in the main repo due to less people having push access for
those, so we wouldn't really gain much by allowing maintainers to push
to testing without a review (which does often catch errors).
> > On Sunday, October 27, 2019, 4:42:45 PM GMT+3, Rasmus Thomsen <> oss@cogitri.dev> wrote:> > > Moving a discussion from IRC to the ML:> > > > One easy way to improve the core team's bandwidth would be a simple> > git> > hook which allowed anyone to push changes to packages for which> > they're> > listed as the maintainer.> > Hm, although that does sound like it'd significantly lessen the> workload on core member I dislike this approach, at least with how we> currently handle maintainership of packages. About everyone can> become> a maintainer (which is a good thing IMHO since this allows people> knowing the package well but not Alpine's packaging process to be a> maintainer) as of now and I feel like it'd be best to have someone> look> over the changes of maintainers which aren't that experienced with> Alpine's packaging process yet. Maybe just having somewhat strict CI> rules and only allowing a merge if CI passes would do the trick to> ensure QA is done though.> > > > This reduces the core team's workload to> > dealing with new packages, new maintainers, etc; but removes the> > burden> > of dealing with every change to aports.> >
On Sun, 2019-10-27 at 17:15 +0100, Sören Tempel wrote:
> Rasmus Thomsen <oss@cogitri.dev> wrote:> > Hm, although that does sound like it'd significantly lessen the> > workload on core member I dislike this approach, at least with how> > we> > currently handle maintainership of packages.> > To move my discussion contribution from the IRC to the ML: IMHO we> should rethink the aport maintainer role in general. Many package> maintainer comments are horribly outdated and contain contact> information of people who haven't committed in the past few years.> Some> packages (even in main/ and community/) don't even have a maintainer> comment.
Yes, right now maintainership often doesn't reflect who actually takes
care of a package, but I don't think the work of always keeping this
up-to-date is worth it (considering how often people come and go in the
OSS landscape).
> Even packages with accurate maintainer comments are often poorly> maintained, by the person maintained in the maintainer comment, i.e.> updates are done by different developers et cetera.> > In my ideal scenario package upgrades would always be done by the> maintainer (would also reduce the patch queue as trivial package> upgrades are no longer part of it).
That's terrible IMHO since this often creates a "this is MY package"
mentality, disallowing people other than the maintainer upgrading the
package and as such holding up progress. I mostly noticed that in the
time I used Gentoo, sometimes patches just sat around for months
without anyone looking at them because only the maintainer was allowed
to look at them (and was absent for a long time). One solution to this
could be agressively handing over the maintainance of packages who's
maintainer has been absent to a "Alpine general" (or something along
those lines) group which will then take care of updating it until
another maintainer has been found. But I fear that that'll create lots
of bureaucratic work for little gain, which can both demotivate
maintainers (it's annoying when you first have to ask for
maintainership of a package before being able to upgrade and might even
fence off new contributors which don't know our process well) and holds
off others from doing more useful things (like updating packages).
> It should also be possible to> contact the maintainer regarding issues with the aport
Hm, IMHO contacting the maintainer directly isn't a good tactic,
because:
* Maintainers often are absent (which is just in the nature of OSS)
* Private communications aren't searchable my others (like Gitlab
issues are)
* Often asking the upstream of the package is better than asking the
maintainer
> and the> maintainer should be responsible for reviewing patches submitted to> GitLab/GitHub/Patchwork.
Again, maintainers in OSS projects often go absent without a warning,
maybe because they lost interest in the project or don't have enough
freetime to contribute anymore. This could lead to patches rotting for
a long time instead of letting a known group of coredevs review the
patch.
> Currently, the maintainer is just some person who added their contact> information to the aport at some point in time. Debian, for instance,> has a very elaborate process for this sort of thing which might help> avoiding some of these pitfalls [0].
A very elaborate process, which create lots of work and scares new
contributors off (or at least it least it does so for me). Really, the
ease of contributing to Alpine is a great thing and it'd be a shame if
we lost that.
> > Maybe just having somewhat strict CI rules and only allowing a> > merge> > if CI passes would do the trick to ensure QA is done though.> > I disagree, I don't think CI rules can ever be good enough to catch> any> sort of mistakes that a manual review might find. Also consider> malicious patches added to an aport, et cetera.
Yup, it sure isn't good enough, but just letting maintainers push
without any checks in place other than that they maintain the package
is even worse.
> Cheers,> Sören
Regards,
Rasmus
> [0]: > https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer