Gentoo Archives: gentoo-dev

From: "Rick \\\"Zero_Chaos\\\" Farina" <zerochaos@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
Date: Tue, 04 Dec 2012 08:09:45
Message-Id: 50BDAFE2.6000702@gentoo.org
In Reply to: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds by hasufell
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 On 12/02/2012 10:21 AM, hasufell wrote:
5 > As I was told in my recruiting process we usually don't just fix up
6 > ebuilds of other devs unless it's trivial, very severe or something.
7 >
8 > The usual process is nothing new: try to contact the maintainer, open a
9 > bug, set a deadline when you will go and fix yourself.
10 >
11 > Only question is now what is a sane soft limit, before you go on and fix
12 > stuff.
13 >>From a discussion in #gentoo-dev we thought 2-4 weeks depending on the
14 > severity of the bug is fine. Ofc this should exclude major changes or
15 > delicate packages from base-system/core/toolchain.
16 >
17 > I tried to document that a bit:
18 > https://bugs.gentoo.org/show_bug.cgi?id=445402
19 >
20 > any objections? This is nothing new, just a clarification of already
21 > existing policy and a reminder.
22 >
23 >
24 If we are going to document this policy and make it official (which
25 since it's not documented it's not official) then it only makes sense to
26 have an opt-out option. I personally don't wish to see my users suffer
27 for 2-4 weeks because I'm busy and people are pretending to be polite.
28
29 I have no issue with this policy, but to do it without an explicit
30 option to opt-out is not acceptable to me. I would suggest something in
31 the metadata.xml under the maintainer section. We could have a specific
32 maintainer section : <maintainer><name>help welcome></name></maintainer>
33 or a specific tag to put under our own maintainer section
34 <maintainer><name>Rick Farina</name><demeanor>just fix it</demeanor></name>
35
36 I currently, and will continue to maintain a completely open policy on
37 my packages. To write in the rules that this is not acceptable would be
38 more than rude.
39
40 Thanks,
41 Zero
42
43 PS> I don't actually mean for either of those suggestions to be used
44 mind you, it's just an example.
45 -----BEGIN PGP SIGNATURE-----
46 Version: GnuPG v2.0.19 (GNU/Linux)
47 Comment: Using GnuPG with undefined - http://www.enigmail.net/
48
49 iQIcBAEBAgAGBQJQva/iAAoJEKXdFCfdEflKFkwP/jBl4I1qFtTPFh52FfBJF7yX
50 h4fQSisiYYFitwzWDVoxjkAbKdfdSTxmevkJfRUfIz7AG+8rBjrndHJscwQQXCCm
51 3533r5B0ql6cXI38pb7WSJdc6xplXx1NVTsPFwxn7rmJVKddFPfa8nOv1dUfjjFN
52 16Yc6B2oV9rfb0AkaUdnAYNJLgjP5gL7AXIJoScUcPVXJZ/glWp/ADmlN+sKsKoy
53 bOBe1Hbm2Z5tTNPun4zOqKtb34daBbLjbtYHz4fR2r+MdbgHQKUIdO1z8iBE6+fR
54 /cOCbN+64jG7Yz3G1n+6rXfFBocRjkin8fEk4hXaZ7FkHOa5w7ONRNFvqmQ+BBfa
55 4SlI/scZ6lEDMi4GDFMdX/ShdaptXvHYcaJIKyE//EP6Q40Ijtqe2HUv1eUjbR5V
56 /HfTapF8YnxX6NZwQPTihpMv3TCneTbKH3anHuWLR3wK0SAMraP6zqYIImfPG0Pt
57 ePm+dRQ6ocZIoDuGroYX9gInqLRqeI+2EWFLMvN3VkDq358N1tX5PhGfTw6AUCw7
58 ao3iZkE3n49xywSYzDAsschoV7iWoJfBdSYbcqRcok/3Z1sEBRd6P2wc6NMFJbO3
59 rWpCDj3vrg08Up6CJIgAsh4r3e5McAcvwycTcWEaDCDgRujjcJN6iN5JR4zur5AK
60 JNc0sFc3rrPHo4Pyu079
61 =ZBY6
62 -----END PGP SIGNATURE-----

Replies