Gentoo Archives: gentoo-dev

From: Florian Schmaus <flow@g.o>
To: "Michal Prívozník" <mprivozn@××××××.com>, gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] <non-maintainer-commits-welcome/> proposal
Date: Thu, 07 Jul 2022 09:10:00
Message-Id: 7b810530-842d-2361-062a-e91d00d2e2b1@gentoo.org
In Reply to: Re: [gentoo-dev] proposal by "Michal Prívozník"
1 On 07.07.22 09:45, Michal Prívozník wrote:
2 > I think that rejecting a contribution (regardless of the flag) should be
3 > based on technical merit, rather than individual maintainers personal
4 > preferences. I do understand some packages are like your babies, you
5 > watch them grow, fine tune everything. But in the end, if somebody finds
6 > a bug in the ebuild/eclass/... and is even willing to provide a fix, we
7 > should have a discussion about the proposed fix rather than refer to a
8 > flag (or lack of thereof) when closing the MR (unmerged).
9
10 It was never the intention to create a scenario where maintainers reject
11 a contribution based on such a flag. Gentoo, being free and open source
12 software, if fully aligned with the spirit of FOSS, which *everyone* can
13 use, study, share and *improve*.
14
15 With the replies in mind, I gave this some more thought. I think the
16 best default is "everyone can propose changes to the maintainer, on
17 which the maintainer has to act within a reasonable amount of time".
18
19 However, there are maybe cases where trivial fixes for low-maintenance
20 packages are for some reason not merged into ::gentoo and the maintainer
21 is unresponsive. If those packages where flagged with
22 <non-maintainer-commits-welcome/>, then I would be less reluctant to
23 commit them to ::gentoo. After committing, I would always inform the
24 maintainer.
25
26 On the other hand, there is the situation where seemingly innocent
27 changes could cause some fallout, because this is the kind of package
28 where you assume you know what is going on from reading the ebuild and
29 playing with it, but you actually don't. Such packages could carry a
30 flag indicating that all changes require review by the maintainer. It
31 appears that <non-maintainer-commits-disallowed/> gives the wrong
32 impression, so maybe <changes-require-maintainer-ack/>?
33
34 - Flow