1 |
On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote: |
2 |
> I'd like to propose a new metadata XML element for packages: |
3 |
> |
4 |
> <non-maintainer-commits-welcome/> |
5 |
> |
6 |
> Maintainers can signal to other developers (and of course contributors |
7 |
> in general) that they are happy with others to make changes to the |
8 |
> ebuilds without prior consultation of the maintainer. |
9 |
> |
10 |
> Of course, this is not a free ticket to always make changes to |
11 |
> packages |
12 |
> that you do not maintain without prior consultation of the maintainer. |
13 |
> I |
14 |
> would expect people to use their common sense to decide if a change |
15 |
> 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 |
20 |
> that |
21 |
> the maintainer is opposed to non-maintainer commits. It just means |
22 |
> that |
23 |
> the maintainer's stance is not known. I do not believe that we need a |
24 |
> <non-maintainer-commits-disallowed/> flag, but if the need arises, we |
25 |
> could always consider adding one. Although, in my experience, people |
26 |
> mostly like to communicate the "non-maintainer commits welcome" policy |
27 |
> with others. |
28 |
> |
29 |
> WDYT? |
30 |
> |
31 |
> - Flow |
32 |
> |
33 |
|
34 |
Ultimately, all these things really matter when only the defaults |
35 |
change. Turn-right-on-red in the US is such a thing, because unless |
36 |
otherwise stated, it's the norm. Knowing our devbase, with roughly 75% |
37 |
mostly AWOL and barely reading the MLs, I don't think this idea will |
38 |
bring about the desired change. Instead, we should really just go for |
39 |
the <non-maintainer-commits-disallowed/> tag, because my feeling is that |
40 |
the default will be that most maintainers don't mind non-maintainer |
41 |
commits, except a select few territorial ones. |
42 |
|
43 |
David |