> On 5 Jul 2022, at 04:24, Ionen Wolkens <io...@gentoo.org> wrote: > > On Mon, Jul 04, 2022 at 10:53:41PM -0400, Ionen Wolkens wrote: >> On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote: >>> On Mon, Jul 04, 2022 at 04:19:12PM +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. >>>> >>>> Of course, this is not a free ticket to always make changes to packages >>>> that you do not maintain without prior consultation of the maintainer. I >>>> would expect people to use their common sense to decide if a change may >>>> require maintainer attention or not. In general, it is always a good >>>> idea to communicate changes in every case. >>>> >>>> The absence of the flag does not automatically allow the conclusion that >>>> the maintainer is opposed to non-maintainer commits. It just means that >>>> the maintainer's stance is not known. I do not believe that we need a >>>> <non-maintainer-commits-disallowed/> flag, but if the need arises, we >>>> could always consider adding one. Although, in my experience, people >>>> mostly like to communicate the "non-maintainer commits welcome" policy >>>> with others. >>>> >>>> WDYT? >>> >>> Personally I think something per-maintainer rather than per package >>> would be simpler, and allow to say more as needed. >> >> ... and that could also extend to projects so can clarify policy in >> a single place that's easy to find. >> >> Like base-system@ probably do not want random uninformed commits, >> but games@, sound@, and such? > > Also, for projects, presenting it more as exception rules makes sense. > Especially for all these semi-random understaffed projects, there's > really a handful that would have some "do nots". > >> >>> >>> Think like devaway instructions, but something more permanent and >>> not for being away, e.g. >>> "feel free to touch my packages except this big important one, and >>> or do or do not do this to them" > > -'or do' :eyes: > > To add more as an example, personally I don't mind non-maintainer commits > but don't particularly want people to start full on bumping my packages > when I /do/ intend to handle them in a timely fashion and probably had > plans for them, perhaps even already a local WIP ebuild and such. So > I'd likely have something along these lines. A simple tag feels like a > bit too "free for all". >
You've nailed something I was wondering about but couldn't really articulate. The only time I really care/don't want someone to do it: - a package genuinely is snowflakey (which is the exception), like it's somehow fragile - the situation is as you described Almost makes one wonder about per-package notes again, although it wouldn't fix the issue wrt projects. Best, sam
signature.asc
Description: Message signed with OpenPGP
