> 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 
- the situation is as you described

Almost makes one wonder about per-package notes again, although
it wouldn't fix the issue wrt projects.


Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to