Re: [gentoo-dev] <non-maintainer-commits-welcome/> proposal

[Jaco Kroon]

Hi All,

On 2022/07/06 15:50, Michał Górny wrote:

> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote:
>> I'd like to propose a new metadata XML element for packages:
>>
>>      <non-maintainer-commits-welcome/>
>>
>> Maintainers can signal to other developers (and of course contributors
>> in general) that they are happy with others to make changes to the
>> ebuilds without prior consultation of the maintainer.
> I don't think adding such an element is a good idea.  In my opinion,
> this will strengthen the assumption that "unless otherwise noted, you
> don't dare touch anything" (even though that's not your goal).  "Common
> sense" should really be good enough for almost everything.

I agree, but also note that what I consider to be "common sense" isn't
always "your common sense".

I also agree that having some way to indicate the preference on the
specific package may be a good thing.  With various possible levels of
sensitivity.

For example, net-misc/asterisk and net-libs/pjproject is very sensitive
for me.  net-misc/dahdi{,-tools} and x11-wm/evilwm less so.  In all
cases I'd still prefer to be kept in the loop at a minimum.

As such, it looks like there is multiple options, and there are
suggestions for various tags, this is a sensible way to indicate
preference.  Eg, also, what kind of fixes don't require communication,
eg, I've seen drive-by's on the above packages to fix dependencies based
on slots because depended on packages changed their structure, or
because LUA became slotted, or adding := etc ...  This makes sense to
allow these, but if you're going to mess with my ./configure on asterisk
or pjproject without consulting with me I'm going to be upset.  A simple
code fix to fix some compile error (specific to say llvm), probably
fine, but I'd still appreciate communication as I'd like to submit that
upstream kind of thing as well.

If this does go live, then there should be a single tag where the value
indicates the level of "sensitivity", or multiple tags of which only one
is allowed.  Since some of these options may be orthogonal to each
other, a single tag with multiple attributes may be more appropriate, I
don't know, nor do I personally care that much, so far I've been
respected, and the drive-by's that has been made were all either part of
global fixes, or in the one or two cases where it was specific, was put
into the tree as ~ so were all just fine.  In one particular case it was
also masked specifically because the change depended on another change
to happen simultaneously/close together (lua slotting) - the experience
of which was most refreshing.  Obviously nothing is set in stone w.r.t.
specifics, but if the initial course is at least somewhat in the right
direction it's easier to course-correct.

I thus have no strong opinion one way or the other, but just wanted to
state the above.


Kind Regards,
Jaco