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". On a related note, perhaps QA team could even be allowed to give instructions themselves when a maintainer is generally unresponsive and is giving no instructions to go with that. > > > > > > > > - Flow > > > > > > > -- > > ionen > > > > -- > ionen -- ionen
signature.asc
Description: PGP signature
