1 |
On 06-07-2022 15:50:30 +0200, Michał Górny wrote: |
2 |
> On Mon, 2022-07-04 at 16:19 +0200, Florian Schmaus wrote: |
3 |
> > I'd like to propose a new metadata XML element for packages: |
4 |
> > |
5 |
> > <non-maintainer-commits-welcome/> |
6 |
> > |
7 |
> > Maintainers can signal to other developers (and of course contributors |
8 |
> > in general) that they are happy with others to make changes to the |
9 |
> > ebuilds without prior consultation of the maintainer. |
10 |
> |
11 |
> I don't think adding such an element is a good idea. In my opinion, |
12 |
> this will strengthen the assumption that "unless otherwise noted, you |
13 |
> don't dare touch anything" (even though that's not your goal). "Common |
14 |
> sense" should really be good enough for almost everything. |
15 |
|
16 |
Right, "common sense". The problem with that one, is that "common" is |
17 |
not as "common" as you think it is. Ask a bunch of people, and you'll |
18 |
find that what they consider "common" isn't the same. |
19 |
|
20 |
So, if you do this, then please define clearly what you think is OK. |
21 |
For example for me: |
22 |
|
23 |
- feel free to add patches necessary for operation |
24 |
- feel free to fix constructs (like an if or case that should apply for |
25 |
something else/different/mode) |
26 |
- feel free to fix typos |
27 |
- please do not needlessly change style: if you do not "maintain" the |
28 |
ebuild, respect the style of the maintainer, so only add the changes |
29 |
you need, keep it minimal, respect the original even though you don't |
30 |
like it (and don't use QA as an excuse to change style) |
31 |
- when you make a change, make sure you check for bugs in the following |
32 |
days, so you can cleanup yourself should there be fallout |
33 |
|
34 |
> I mean, I do realize that 10 years ago, in the golden years of Gentoo, |
35 |
> it was considered normal for developers to be like "my package, my |
36 |
> fortress, don't you dare add systemd unit or I will retire" but today I |
37 |
> think we're aiming for a more welcoming developer base, and I think |
38 |
> we're actually going in that direction. What I'm afraid is that some |
39 |
> people will use this as an excuse to push back once again. |
40 |
|
41 |
Not sure I have the same memories of how it used to be 10 years ago. I |
42 |
actually think it is pretty much the same as it is now, as it was then. |
43 |
Different and fewer people, but still different |
44 |
preferences/opinions/common sense. |
45 |
|
46 |
> Can you really think of a case when common sense really, really wouldn't |
47 |
> work? I mean, sure, we all make mistakes but we should be able to learn |
48 |
> from them and do better next time. This also implies package |
49 |
> maintainers learning that they're not the only people who will ever |
50 |
> touch the package in question and starting to document the pitfalls. |
51 |
|
52 |
Honestly, I've never been a fan of "maintainership". It basically is |
53 |
some sort of "sign" that says "beware for the dog, stay away". However, |
54 |
it's true that sometimes people really delve into a package, and thereby |
55 |
know very much how it works, and what you should/should not do. |
56 |
Something like LLVM is a good example, maybe. Anyway, in such |
57 |
situation, I think extreme care should be taken by non-maintainers. |
58 |
Dunno how to best indicate that, and/or if that's feasible -- like you |
59 |
said, it quickly ends up being an excuse for declaring a package to be |
60 |
off-limits. |
61 |
|
62 |
Fabian |
63 |
|
64 |
-- |
65 |
Fabian Groffen |
66 |
Gentoo on a different level |