| 1 |
> On 5 Jul 2022, at 04:24, Ionen Wolkens <ionen@g.o> wrote: |
| 2 |
> |
| 3 |
> On Mon, Jul 04, 2022 at 10:53:41PM -0400, Ionen Wolkens wrote: |
| 4 |
>> On Mon, Jul 04, 2022 at 10:49:25PM -0400, Ionen Wolkens wrote: |
| 5 |
>>> On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote: |
| 6 |
>>>> I'd like to propose a new metadata XML element for packages: |
| 7 |
>>>> |
| 8 |
>>>> <non-maintainer-commits-welcome/> |
| 9 |
>>>> |
| 10 |
>>>> Maintainers can signal to other developers (and of course contributors |
| 11 |
>>>> in general) that they are happy with others to make changes to the |
| 12 |
>>>> ebuilds without prior consultation of the maintainer. |
| 13 |
>>>> |
| 14 |
>>>> Of course, this is not a free ticket to always make changes to packages |
| 15 |
>>>> that you do not maintain without prior consultation of the maintainer. I |
| 16 |
>>>> would expect people to use their common sense to decide if a change may |
| 17 |
>>>> require maintainer attention or not. In general, it is always a good |
| 18 |
>>>> idea to communicate changes in every case. |
| 19 |
>>>> |
| 20 |
>>>> The absence of the flag does not automatically allow the conclusion that |
| 21 |
>>>> the maintainer is opposed to non-maintainer commits. It just means that |
| 22 |
>>>> the maintainer's stance is not known. I do not believe that we need a |
| 23 |
>>>> <non-maintainer-commits-disallowed/> flag, but if the need arises, we |
| 24 |
>>>> could always consider adding one. Although, in my experience, people |
| 25 |
>>>> mostly like to communicate the "non-maintainer commits welcome" policy |
| 26 |
>>>> with others. |
| 27 |
>>>> |
| 28 |
>>>> WDYT? |
| 29 |
>>> |
| 30 |
>>> Personally I think something per-maintainer rather than per package |
| 31 |
>>> would be simpler, and allow to say more as needed. |
| 32 |
>> |
| 33 |
>> ... and that could also extend to projects so can clarify policy in |
| 34 |
>> a single place that's easy to find. |
| 35 |
>> |
| 36 |
>> Like base-system@ probably do not want random uninformed commits, |
| 37 |
>> but games@, sound@, and such? |
| 38 |
> |
| 39 |
> Also, for projects, presenting it more as exception rules makes sense. |
| 40 |
> Especially for all these semi-random understaffed projects, there's |
| 41 |
> really a handful that would have some "do nots". |
| 42 |
> |
| 43 |
>> |
| 44 |
>>> |
| 45 |
>>> Think like devaway instructions, but something more permanent and |
| 46 |
>>> not for being away, e.g. |
| 47 |
>>> "feel free to touch my packages except this big important one, and |
| 48 |
>>> or do or do not do this to them" |
| 49 |
> |
| 50 |
> -'or do' :eyes: |
| 51 |
> |
| 52 |
> To add more as an example, personally I don't mind non-maintainer commits |
| 53 |
> but don't particularly want people to start full on bumping my packages |
| 54 |
> when I /do/ intend to handle them in a timely fashion and probably had |
| 55 |
> plans for them, perhaps even already a local WIP ebuild and such. So |
| 56 |
> I'd likely have something along these lines. A simple tag feels like a |
| 57 |
> bit too "free for all". |
| 58 |
> |
| 59 |
|
| 60 |
You've nailed something I was wondering about but couldn't |
| 61 |
really articulate. |
| 62 |
|
| 63 |
The only time I really care/don't want someone to do it: |
| 64 |
- a package genuinely is snowflakey (which is the exception), like it's somehow fragile |
| 65 |
- the situation is as you described |
| 66 |
|
| 67 |
Almost makes one wonder about per-package notes again, although |
| 68 |
it wouldn't fix the issue wrt projects. |
| 69 |
|
| 70 |
Best, |
| 71 |
sam |
Archives