Gentoo Archives: gentoo-project

From: Michael 'veremitz' Everitt <gentoo@×××××××.xyz>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: [gentoo-dev-announce] call for agenda items for 2020-01-12 council meeting
Date: Sun, 05 Jan 2020 15:55:42
In Reply to: Re: [gentoo-project] Re: [gentoo-dev-announce] call for agenda items for 2020-01-12 council meeting by Ulrich Mueller
1 On 05/01/20 15:45, Ulrich Mueller wrote:
2 >>>>>> On Sun, 05 Jan 2020, Piotr Karbowski wrote:
3 >> I'd like to request Council to define rules regarding maintainership
4 >> boundaries and provide guidance regarding under what conditions one is
5 >> allowed to make changes to packages that are by metadata.xml maintained
6 >> by another party.
7 >> The current situation is land of undefined rules and double standards
8 >> under disguise of 'common sense'. Although it does work for most part,
9 >> it's not uncommon to come across people that are overly territorial,
10 >> treating Gentoo packages as their own personal property, who openly
11 >> prohibit others from joining them as maintainers on packages, with the
12 >> solo reasoning that they feel territorial and do not want others
13 >> touching it.
14 >> This leads to a situations, where some bugs reported on bugzilla are not
15 >> fixed in timely fashion, even when there are other developers that are
16 >> willing to fix those bugs and deal with whatever aftermath of doing
17 >> those changes would bring.
18 >> Because those rules are unsanctioned, we have land of middle
19 >> inconvenience where one can never be sure if by declaring maintainer
20 >> fimeout and fixing a bug would not bring ComRel on him, for touching the
21 >> package one does not maintain. By defining rules and guidelines, it
22 >> would greatly benefit Gentoo as a whole as well as reduce the
23 >> frustration that come from dealing with people who are gate keeping
24 >> while being unable to provide a valid reason why they do not want anyone
25 >> toucing their property.
26 > This has been discussed a number of times in the past. I believe that
27 > the best current practice is outlined in the devmanual:
28 >
29 >
30 >
31 > Also, "request Council to define rules" normally isn't going to work,
32 > because chances are that the Council won't see this as an actionable
33 > item. So, if you want the rules to be changed (or better defined),
34 > then it will work much better if you come up with a concrete proposal
35 > and discuss it on the mailing list.
36 >
37 > Ulrich
38 Agreed with Ulm here, fwiw, this does go back and forth.
40 The only suggestion I could potentially think of (and may have arisen
41 before) is to add some kind of field in metadata.xml about any particular
42 salient issues that non-maintainers should be wary of touching, if
43 relevant. Otherwise, perhaps another field in metadata.xml as a default
44 reply/comment to any bugs opened, explaining that only 'best-effort'
45 maintenance is available for this package, and responses may be
46 particularly slow.
48 What also might warrant some further discussion, is how to handle instances
49 of devaway where maintainers haven't (most do..) set a policy for their
50 packages.


File name MIME type
signature.asc application/pgp-signature