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 |
> |