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 <whoever@alpinelinux.org>
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
On Mon, 2020-06-08 at 02:13 -0600, Ariadne Conill wrote:
> Hello,> > ...> > # Maintainer: Alpine KDE team <> https://gitlab.alpinelinux.org/groups/kde>> # Coordinator: Whoever <whoever@alpinelinux.org>> > 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?
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
Hello,
On Monday, June 8, 2020 2:45:33 AM MDT Rasmus Thomsen wrote:
> On Mon, 2020-06-08 at 02:13 -0600, Ariadne Conill wrote:> > Hello,> > > > ...> > > > # Maintainer: Alpine KDE team <> > https://gitlab.alpinelinux.org/groups/kde>> > # Coordinator: Whoever <whoever@alpinelinux.org>> > > > 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?> > 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.
That is a fair point.
> 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.
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
On Mon, 08 Jun 2020 02:13:49 -0600
Ariadne Conill <ariadne@dereferenced.org> wrote:
> 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.
I am in favor of this.
> > >From an APKBUILD perspective, the maintainer line would look like this: > > # Maintainer: Alpine KDE team <https://gitlab.alpinelinux.org/groups/kde>> # Coordinator: Whoever <whoever@alpinelinux.org>> > 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.
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.
> > Thoughts?> > Ariadne> > [1]: https://gitlab.alpinelinux.org/groups/core>
On Mon, 2020-06-08 at 10:59 +0200, Natanael Copa wrote:
> On Mon, 08 Jun 2020 02:13:49 -0600> Ariadne Conill <ariadne@dereferenced.org> wrote:> > [...]> > > > From an APKBUILD perspective, the maintainer line would look like> > > this: > > > > # Maintainer: Alpine KDE team <> > https://gitlab.alpinelinux.org/groups/kde>> > # Coordinator: Whoever <whoever@alpinelinux.org>> > > > 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.> > 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.
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
On Mon, 08 Jun 2020 11:12:13 +0200
Rasmus Thomsen <oss@cogitri.dev> wrote:
> On Mon, 2020-06-08 at 10:59 +0200, Natanael Copa wrote:> > On Mon, 08 Jun 2020 02:13:49 -0600> > Ariadne Conill <ariadne@dereferenced.org> wrote:> > > > [...]> > > > > > From an APKBUILD perspective, the maintainer line would look like> > > > this: > > > > > > # Maintainer: Alpine KDE team < > > > https://gitlab.alpinelinux.org/groups/kde> > > > # Coordinator: Whoever <whoever@alpinelinux.org>> > > > > > 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. > > > > 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. > > 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?
Sure.
> 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.
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> 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.
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
I like the proposal in general, I am not so sure about team coordinators
though.
Natanael Copa <ncopa@alpinelinux.org> wrote:
> 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 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
On Tue, 2020-06-09 at 12:59 +0200, Sören Tempel wrote:
> Natanael Copa <ncopa@alpinelinux.org> wrote:> > 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 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.
Maybe the gitlab group could be used for communication since we'll have
one per team anyway I think.
Regards,
Rasmus
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.
On Tue, Jun 9, 2020, 7:32 AM Rasmus Thomsen <oss@cogitri.dev> wrote:
> On Tue, 2020-06-09 at 12:59 +0200, Sören Tempel wrote:> > Natanael Copa <ncopa@alpinelinux.org> wrote:> > > 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 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.>> Maybe the gitlab group could be used for communication since we'll have> one per team anyway I think.>> Regards,>> Rasmus>
On Tue, 9 Jun 2020 07:42:26 -0400
Will Sinatra <wpsinatra@gmail.com> wrote:
> 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.
> 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.
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.
> On Tue, Jun 9, 2020, 7:32 AM Rasmus Thomsen <oss@cogitri.dev> wrote:> > > On Tue, 2020-06-09 at 12:59 +0200, Sören Tempel wrote: > > > Natanael Copa <ncopa@alpinelinux.org> wrote: > > > > 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 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. > >> > Maybe the gitlab group could be used for communication since we'll have> > one per team anyway I think.> >> > Regards,> >> > Rasmus> >
I am willing to help out with Perl packages. I have not ventured much
further at this point.
On Tue, Jun 9, 2020 at 8:42 AM Will Sinatra <wpsinatra@gmail.com> wrote:
> 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.>> On Tue, Jun 9, 2020, 7:32 AM Rasmus Thomsen <oss@cogitri.dev> wrote:>>> On Tue, 2020-06-09 at 12:59 +0200, Sören Tempel wrote:>> > Natanael Copa <ncopa@alpinelinux.org> wrote:>> > > 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 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.>>>> Maybe the gitlab group could be used for communication since we'll have>> one per team anyway I think.>>>> Regards,>>>> Rasmus>>>
I am willing to help out with Perl packages. I have not ventured much
further at this point.
On Tue, Jun 9, 2020 at 8:42 AM Will Sinatra <wpsinatra@gmail.com> wrote:
>> 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.>> On Tue, Jun 9, 2020, 7:32 AM Rasmus Thomsen <oss@cogitri.dev> wrote:>>>> On Tue, 2020-06-09 at 12:59 +0200, Sören Tempel wrote:>> > Natanael Copa <ncopa@alpinelinux.org> wrote:>> > > 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 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.>>>> Maybe the gitlab group could be used for communication since we'll have>> one per team anyway I think.>>>> Regards,>>>> Rasmus
On Tue, 9 Jun 2020 09:26:07 -0300
Timothy Legge <timlegge@gmail.com> wrote:
> I am willing to help out with Perl packages. I have not ventured much> further at this point.
Very nice!
I think this illustrates the value of having teams or SIGs (special
interest group).
-nc
> > > On Tue, Jun 9, 2020 at 8:42 AM Will Sinatra <wpsinatra@gmail.com> wrote:> >> > 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.> >> > On Tue, Jun 9, 2020, 7:32 AM Rasmus Thomsen <oss@cogitri.dev> wrote: > >>> >> On Tue, 2020-06-09 at 12:59 +0200, Sören Tempel wrote: > >> > Natanael Copa <ncopa@alpinelinux.org> wrote: > >> > > 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 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. > >>> >> Maybe the gitlab group could be used for communication since we'll have> >> one per team anyway I think.> >>> >> Regards,> >>> >> Rasmus
Hello,
On Tuesday, June 9, 2020 4:59:46 AM MDT Sören Tempel wrote:
> I like the proposal in general, I am not so sure about team coordinators> though.> > Natanael Copa <ncopa@alpinelinux.org> wrote:> > 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 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.
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
Hello,
On Monday, June 8, 2020 2:13:49 AM MDT Ariadne Conill wrote:
> 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 <whoever@alpinelinux.org>> > 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
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
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.> > Members: myself, Cogitri (as coordinator), PureTryOut, Leo>
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
On Tue, Jun 09, 2020 at 08:37:05PM -0600, Ariadne Conill wrote:
> Hello,> > On Monday, June 8, 2020 2:13:49 AM MDT Ariadne Conill wrote:> > 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.
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.
> > >From an APKBUILD perspective, the maintainer line would look like this:> > # 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).
> > # Coordinator: Whoever <whoever@alpinelinux.org>> > > > 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> > 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.> > [..]> > 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>
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
On Wed, Jul 01, 2020 at 10:04:21PM +0200, Kevin Daudt wrote:
> On Tue, Jun 09, 2020 at 08:37:05PM -0600, Ariadne Conill wrote:> > Hello,> > > > On Monday, June 8, 2020 2:13:49 AM MDT Ariadne Conill wrote:> > > 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.> > 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.> > > > >From an APKBUILD perspective, the maintainer line would look like this:> > > # 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).> > > > # Coordinator: Whoever <whoever@alpinelinux.org>> > > > > > 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> > > > 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.> > > > [..]> > > > 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> > > > 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
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
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).
> Kevin
On Wednesday, July 8, 2020 2:13:21 PM MDT Kevin Daudt wrote:
> On Wed, Jul 01, 2020 at 10:04:21PM +0200, Kevin Daudt wrote:> > On Tue, Jun 09, 2020 at 08:37:05PM -0600, Ariadne Conill wrote:> > > Hello,> > > > > > On Monday, June 8, 2020 2:13:49 AM MDT Ariadne Conill wrote:> > > > 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.> > > > 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.> > > > > > >From an APKBUILD perspective, the maintainer line would look like
this:
> > > > # 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).> > > > > > # Coordinator: Whoever <whoever@alpinelinux.org>> > > > > > > > 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> > > > > > 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.> > > > > > [..]> > > > > > 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> > > > 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> > 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.
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