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----- |