Gentoo Archives: gentoo-dev

From: waebbl-gentoo <waebbl-gentoo@××××××.net>
To: Ionen Wolkens <ionen@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] <non-maintainer-commits-welcome/> proposal
Date: Tue, 05 Jul 2022 05:44:21
Message-Id: 20220705070955.3aad3229@artus
In Reply to: Re: [gentoo-dev] proposal by Ionen Wolkens
1 On Mon, 4 Jul 2022 22:49:25 -0400
2 Ionen Wolkens <ionen@g.o> wrote:
3
4 > On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote:
5 > > I'd like to propose a new metadata XML element for packages:
6 > >
7 > > <non-maintainer-commits-welcome/>
8 > >
9 > > Maintainers can signal to other developers (and of course contributors
10 > > in general) that they are happy with others to make changes to the
11 > > ebuilds without prior consultation of the maintainer.
12 > >
13 > > Of course, this is not a free ticket to always make changes to packages
14 > > that you do not maintain without prior consultation of the maintainer. I
15 > > would expect people to use their common sense to decide if a change may
16 > > require maintainer attention or not. In general, it is always a good
17 > > idea to communicate changes in every case.
18 > >
19 > > The absence of the flag does not automatically allow the conclusion that
20 > > the maintainer is opposed to non-maintainer commits. It just means that
21 > > the maintainer's stance is not known. I do not believe that we need a
22 > > <non-maintainer-commits-disallowed/> flag, but if the need arises, we
23 > > could always consider adding one. Although, in my experience, people
24 > > mostly like to communicate the "non-maintainer commits welcome" policy
25 > > with others.
26 > >
27 > > WDYT?
28 >
29 > Personally I think something per-maintainer rather than per package
30 > would be simpler, and allow to say more as needed.
31 >
32 > Think like devaway instructions, but something more permanent and
33 > not for being away, e.g.
34 > "feel free to touch my packages except this big important one, and
35 > or do or do not do this to them"
36 >
37
38 I think it would be more efficient if we use a flag on a per-maintainer
39 basis. But it adds extra overhead, if the maintainer doesn't want some
40 special packages to be touched, or if special cases, like bumps need to
41 be avoided.
42
43 We could add a central file, something like the metadata/AUTHORS file
44 with this information. Possibly in a structured format like xml or json
45 to make it machine readable as well and the information can be
46 extracted and shown e.g. on the wiki or p.g.o site.
47
48 Something like the devaway
49 instructions could lock out proxy maintainers, which don't have access
50 to the Gentoo infrastructure.
51
52 > >
53 > > - Flow
54 > >
55 >

Attachments

File name MIME type
waebbl-gentoo@posteo.net.asc text/plain