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

[Ionen Wolkens]

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