Subject: team-maintained packages

From: Ariadne Conill <[email-masked]>
Date: Mon, 08 Jun 2020 02:13:49 -0600

Hello,

Now that Gitlab is deployed and in place, it is possible to have teams as 
groups in gitlab, such as the core group[1].

As many maintainers and developers collaborate on packages anyway, I believe 
it is useful to formalize this arrangement.

Accordingly, I believe that we should allow Gitlab groups to own packages to 
achieve that.  A Gitlab group can be assigned issues in the issue tracker, and 
can have designated "owners" of the group.  Groups are also publicly viewable.  
This solves the traditional accountability issue with team maintenance.

From an APKBUILD perspective, the maintainer line would look like this:

# Maintainer: Alpine KDE team <https://gitlab.alpinelinux.org/groups/kde>
# Coordinator: Whoever <[email-masked]>

The "coordinator" role would be the preferred member in the group for contact 
about the package, but the team as a whole could also make decisions about the 
package as well.

Thoughts?

Ariadne

[1]: https://gitlab.alpinelinux.org/groups/core

---

From: Rasmus Thomsen <[email-masked]>
Date: Mon, 08 Jun 2020 10:45:33 +0200

On Mon, 2020-06-08 at 02:13 -0600, Ariadne Conill wrote:
> Hello,
> 
> ...
> 
> # Maintainer: Alpine KDE team <
> https://gitlab.alpinelinux.org/groups/kde>

Hello,

I think I overall like the idea of having maintenance teams (as long as
it's not mandatory to be in one to be permitted to touch an APKBUILD),
but I don't really see the point of having a coordinator. If you have a
preferred member which should be contacted for changes the APKBUILD
might as well be maintained by that individual directly.

Also, I'm not sure if we're having enough people who are actually
interested in forming such teams to make them actually viable. E.g. the
GNOME team would probably be just me, and KDE possibly you and
PureTryOut. I think that it might just end up being a lot of
bureaucracy without any substantial gain in the end when maintainers
aren't responsive enough and as such core members end up deciding
whether changes are merged or not in the end anyway.

Regards,

Rasmus

---

From: Ariadne Conill <[email-masked]>
Date: Mon, 08 Jun 2020 02:54:39 -0600

Hello,

> might as well be maintained by that individual directly.

That is a fair point.

> whether changes are merged or not in the end anyway.

I think we do.  I also think that with some of the other changes I have in 
mind, we will be able to get more cross-distribution pollination going on in 
the APKBUILDs.  But I am still thinking on the best way to achieve that right 
now.

The idea is to avoid bureaucracy, and just have a group point of contact for 
packages.  Normal policies including non-maintainer pushes would apply to 
group maintained packages.

Thanks,
Ariadne

---

From: Natanael Copa <[email-masked]>
Date: Mon, 8 Jun 2020 10:59:47 +0200

On Mon, 08 Jun 2020 02:13:49 -0600

> This solves the traditional accountability issue with team maintenance.

I am in favor of this.

> about the package, but the team as a whole could also make decisions about the 

I like the idea. The thing I am mostly worried about is when everyone
on the team thinks that someone else will take care of an incoming
issue, resulting in nobody doing it. I think that a "coordinator" role
for each team solves that.

I wonder if it is necessary to list the coordinator in every APKBUILD.
It gives us unnecessary work when role changes. Should be enough with
the url to the team.

---

From: Rasmus Thomsen <[email-masked]>
Date: Mon, 08 Jun 2020 11:12:13 +0200

On Mon, 2020-06-08 at 10:59 +0200, Natanael Copa wrote:
> [...]

Isn't the idea to have teams so that everyone can look at any APKBUILD
the team maintains when they have time/feel like it? I think that:

1) We'll have a hard time finding people with enough time to coordinate
a team.
2) We'll place too much workload on the coordinator instead of just
distributing the load across all members of the teams.

Also, I'm not quite sure what the coordinator would do. They could poke
someone from the team they think could review the MR, but if that
person were interested in reviewing the MR they'd probably do so when
they get the email for the team-ping on that MR. So the coordinator
would either end up reviewing the MR (defeating the point of the team)
or would have to poke indiviuals who really should just look at the
team notifications if they're interested in being in the team.

Regards,

Rasmus

---

From: Natanael Copa <[email-masked]>
Date: Mon, 8 Jun 2020 12:46:53 +0200

On Mon, 08 Jun 2020 11:12:13 +0200
Rasmus Thomsen <[email-masked]> wrote:

> the team maintains when they have time/feel like it? 

Sure.

> I think that:

I don't think the teams will be bigger than 1-2 initially so there will
not be any coordination work. But it will prepare us to scale. It will
also serve as a form of documentation on who takes care of what.

But I agree, we don't want needless administrative work.

> Also, I'm not quite sure what the coordinator would do. They could
> poke someone from the team they think could review the MR, but if that

I think anyone in the team could review and merge the MRs if the teams
wants that. I also support that even people who are not on the team
should be able to review and merge MRs, like we do now.

Coordinators role would be to have overview and be a communication
point for the team. A contributor wants to help with something, lets
say documentation, and it is known that there are 2 other people
working on it too. Who should the contributor speak with to avoid
double work? The coordinator.

I expect the coordinator role be nothing more than a name in the
documentation of who is doing what initially, but the role will be more
significant as the size of the team increases.

-nc

---

From: Sören Tempel <[email-masked]>
Date: Tue, 09 Jun 2020 12:59:46 +0200

I like the proposal in general, I am not so sure about team coordinators
though.

> double work? The coordinator.

I think team coordination is something that could just be decided
internally by the team itself. For instance, an IRC channel or similar
would imho also be sufficient for coordination within the team without
having a central team coordinator.

Cheers,
Sören

---

From: Rasmus Thomsen <[email-masked]>
Date: Tue, 09 Jun 2020 13:31:43 +0200

> having a central team coordinator.

Maybe the gitlab group could be used for communication since we'll have
one per team anyway I think.

Regards,

Rasmus

---

From: Will Sinatra <[email-masked]>
Date: Tue, 9 Jun 2020 07:42:26 -0400

Would the teams cover single packages, or rather large concepts?

Would there be for instance a lisp team in charge of all lisp packages, or
just an SBCL team in charge of SBCL, and a CLISP team in charge of CLISP,
etc.

---

From: Natanael Copa <[email-masked]>
Date: Tue, 9 Jun 2020 14:23:52 +0200

On Tue, 9 Jun 2020 07:42:26 -0400

> Would the teams cover single packages, or rather large concepts?

Depends on the need, but I'd guess teams make more sense for larger
concepts, like documentation, infra, kernel, toolchain, GNOME.

Some teams may be unrelated packages (like developer relations), while
others may be about maintaining a group of packages (for example kernel)

The idea is to create teams as the need for them shows up.

> just an SBCL team in charge of SBCL, and a CLISP team in charge of CLISP,

Depends on what the need is and what makes sense. If there is only a
single person interested in those things there may not be need to
create a team either.

---

From: Timothy Legge <[email-masked]>
Date: Tue, 9 Jun 2020 09:24:37 -0300

I am willing to help out with Perl packages.  I have not ventured much
further at this point.

---

From: Timothy Legge <[email-masked]>
Date: Tue, 9 Jun 2020 09:26:07 -0300

On Tue, Jun 9, 2020 at 8:42 AM Will Sinatra <[email-masked]> wrote:
> Would there be for instance a lisp team in charge of all lisp packages, or just an SBCL team in charge of SBCL, and a CLISP team in charge of CLISP, etc.
>

---

From: Natanael Copa <[email-masked]>
Date: Tue, 9 Jun 2020 15:12:55 +0200

On Tue, 9 Jun 2020 09:26:07 -0300

> I am willing to help out with Perl packages.  I have not ventured much

Very nice!

I think this illustrates the value of having teams or SIGs (special
interest group).

-nc

---

From: Ariadne Conill <[email-masked]>
Date: Tue, 09 Jun 2020 20:11:50 -0600

Hello,

> having a central team coordinator.

Teams/SIGs/whatever we want to call them can organize however they wish.  The 
purpose of the coordinator role is to provide a point of contact for the team, 
be it for newcomers who are interested in joining the team or if the core team 
requires something from a specific team*.

(* I have plans for splitting the core team into a few new teams, that allow 
for people to participate according to their expertise instead of being on a 
catch-all but lets make baby steps.)

Ariadne

---

From: Ariadne Conill <[email-masked]>
Date: Tue, 09 Jun 2020 20:37:05 -0600

Hello,

On Monday, June 8, 2020 2:13:49 AM MDT Ariadne Conill wrote:
> achieve that.  A Gitlab group can be assigned issues in the issue tracker,
> and can have designated "owners" of the group.  Groups are also publicly
> viewable. This solves the traditional accountability issue with team
> maintenance.
> The "coordinator" role would be the preferred member in the group for
> contact about the package, but the team as a whole could also make
> decisions about the package as well.
> 
> Thoughts?
> 
> Ariadne
> 

As an update to this, it appears we have consensus on the following points:

1. Teams should exist and be managed using Gitlab.
2. Teams may own packages, the Maintainer entry points to their Gitlab group 
URI.
3. Teams should have a coordinator role that is reflected as the "Owner" role 
in the group.  The coordinator role may change from time to time based on 
consensus of the group.

Accordingly, I would like to propose the following groups as an initial test 
of this proposal.  The member lists here are not exhaustive, I know I am 
missing people who would probably like to be members or should be members of 
these teams.

* Alpine desktop team

This team focuses on coordination of desktop-wide packaging, policy, theming 
etc.  This team does not just produce packaging, but also themes (perhaps an 
alpine-backgrounds package for example), and software that integrates desktop 
environments with Alpine features, such as apk-tools integration, live desktop 
environment, GUI installer, etc.  Basically a catch-all group to deal with the 
meta issues surrounding plumbing the alpine desktop.

Members: myself, Cogitri (as coordinator), PureTryOut, Leo

* X11/Wayland

This team focuses on maintenance of X11 and Wayland.

Members: ncopa, Cogitri, Leo

* KDE

This team focuses on maintenance of KDE.

Members: myself, PureTryOut (coordinator).

* Toolchain

This team formalizes the current maintenance arrangement with the toolchain.  
It would take over maintenance of binutils, gcc, llvm, musl, pkgconf and other 
core toolchain packages.

Members: myself, mps, fabled, ncopa (coordinator)

* Kernel

Same story as toolchain but with kernel.

Members: myself, ncopa (coordinator), mps

* Development Tools

This group deals with producing/maintaining software such as atools, abuild 
etc.

Members: Leo, ncopa (and whoever else is working on these kinds of tools, 
ncopa probably as coordinator here)

There are other parts of the system that could benefit from this, but lets wait 
on those until we become more comfortable with team maintenance and SIGs in 
general.

Ariadne

---

From: Leo <[email-masked]>
Date: Thu, 11 Jun 2020 21:53:08 -0300

Hello

> 
> * Alpine desktop team
> 
> This team focuses on coordination of desktop-wide packaging, policy,
> theming etc.  This team does not just produce packaging, but also
> themes (perhaps an alpine-backgrounds package for example), and
> software that integrates desktop environments with Alpine features,
> such as apk-tools integration, live desktop environment, GUI
> installer, etc.  Basically a catch-all group to deal with the meta
> issues surrounding plumbing the alpine desktop.
> 

I'd like to not be in this group.

> 
> * Development Tools
> 
> This group deals with producing/maintaining software such as atools,
> abuild etc.
> 
> Members: Leo, ncopa (and whoever else is working on these kinds of
> tools, ncopa probably as coordinator here)
> 

I'd like to be in this group.

Regards
Leo

---

From: Kevin Daudt <[email-masked]>
Date: Wed, 1 Jul 2020 22:04:21 +0200

> > viewable. This solves the traditional accountability issue with team

Sadly, you cannot assign issues to groups in Gitlab (and apparently
unlikely to be added[0]). I think as an alternative we could assign it
to the coordinator who can delegate it, perhaps combined with mentioning
the group.

> > # Maintainer: Alpine KDE team <https://gitlab.alpinelinux.org/groups/kde>

I assume abuild, apk-tools and aports-turbo have no issues with this?
(mainly the url in the e-mail part).

> [..]

As no one seems to have opposed this, I think we can go ahead and start
creating these groups.

I will be creating this as 'user' groups, which means creating projects
will be disabled. This is consistent how we did it for the currently
existing groups as well.

Kevin

[0]:https://gitlab.com/gitlab-org/gitlab/-/issues/6008

---

From: Kevin Daudt <[email-masked]>
Date: Wed, 8 Jul 2020 22:13:21 +0200

> [0]:https://gitlab.com/gitlab-org/gitlab/-/issues/6008

I've now added members to these teams and made them public. Do we also
want a Gnome team btw?

Let me know if you think anything should be changed.

Kevin

---

From: Rasmus Thomsen <[email-masked]>
Date: Wed, 08 Jul 2020 22:44:32 +0200

On Wed, 2020-07-08 at 22:13 +0200, Kevin Daudt wrote:
>  Do we also want a Gnome team btw?

Hm, I guess we can make one but I don't think anyone but me would be in
that team right now (but could be useful for future proofing).

---

From: Ariadne Conill <[email-masked]>
Date: Fri, 10 Jul 2020 10:08:51 -0600

On Wednesday, July 8, 2020 2:13:21 PM MDT Kevin Daudt wrote:
> > > > As many maintainers and developers collaborate on packages anyway, I
> > > > believe it is useful to formalize this arrangement.
> > > > 
> > > > Accordingly, I believe that we should allow Gitlab groups to own
> > > > packages to achieve that.  A Gitlab group can be assigned issues in
> > > > the issue tracker, and can have designated "owners" of the group. 
> > > > Groups are also publicly viewable. This solves the traditional
> > > > accountability issue with team maintenance.
> > 
> > > > # Maintainer: Alpine KDE team
> > > > <https://gitlab.alpinelinux.org/groups/kde>
> > 
> > > 2. Teams may own packages, the Maintainer entry points to their Gitlab
> > > group URI.
> > > 3. Teams should have a coordinator role that is reflected as the "Owner"
> > > role in the group.  The coordinator role may change from time to time
> > > based on consensus of the group.
> > > 
> > > Accordingly, I would like to propose the following groups as an initial
> > > test of this proposal.  The member lists here are not exhaustive, I
> > > know I am missing people who would probably like to be members or
> > > should be members of these teams.
> > > 
> > > [..]
> > > 
> > > There are other parts of the system that could benefit from this, but
> > > lets wait on those until we become more comfortable with team
> > > maintenance and SIGs in general.
> > > 
> > > Ariadne
> > 

I think the next step is to validate that aports-turbo will work with the 
change.  Based on what I have seen of the code it should be fine, but would be 
nice to verify it.

Ariadne