On 07.07.22 09:45, Michal Prívozník wrote:
I think that rejecting a contribution (regardless of the flag) should be based on technical merit, rather than individual maintainers personal preferences. I do understand some packages are like your babies, you watch them grow, fine tune everything. But in the end, if somebody finds a bug in the ebuild/eclass/... and is even willing to provide a fix, we should have a discussion about the proposed fix rather than refer to a flag (or lack of thereof) when closing the MR (unmerged).
It was never the intention to create a scenario where maintainers reject a contribution based on such a flag. Gentoo, being free and open source software, if fully aligned with the spirit of FOSS, which *everyone* can use, study, share and *improve*.
With the replies in mind, I gave this some more thought. I think the best default is "everyone can propose changes to the maintainer, on which the maintainer has to act within a reasonable amount of time".
However, there are maybe cases where trivial fixes for low-maintenance packages are for some reason not merged into ::gentoo and the maintainer is unresponsive. If those packages where flagged with <non-maintainer-commits-welcome/>, then I would be less reluctant to commit them to ::gentoo. After committing, I would always inform the maintainer.
On the other hand, there is the situation where seemingly innocent changes could cause some fallout, because this is the kind of package where you assume you know what is going on from reading the ebuild and playing with it, but you actually don't. Such packages could carry a flag indicating that all changes require review by the maintainer. It appears that <non-maintainer-commits-disallowed/> gives the wrong impression, so maybe <changes-require-maintainer-ack/>?
- Flow
