1 |
On 21 December 2012 08:49, Brian Dolbec <dolsen@g.o> wrote: |
2 |
> On Thu, 2012-12-20 at 21:30 -0800, "Paweł Hajdan, Jr." wrote: |
3 |
>> On 12/20/12 7:21 PM, Doug Goldstein wrote: |
4 |
>> > I'm curious who had the brain dead idea to retire Gentoo developers |
5 |
>> > that are still interested in the distro, that maintain low activity |
6 |
>> > packages for herds that are stretched way too thin, and are still |
7 |
>> > contributing to the distro in many ways other than direct CVS commits |
8 |
>> > (e.g. overlays, user support, providing hardware to other devs, etc). |
9 |
>> |
10 |
>> Dough, thank you for rising the issue. |
11 |
>> |
12 |
>> I'm receiving the undertakers@ e-mail, so I have a pretty good view of |
13 |
>> what's happening. |
14 |
>> |
15 |
>> I have several suggestions how we can improve things: |
16 |
>> |
17 |
>> 1. 3 months is too short period anyway. |
18 |
>> |
19 |
>> 2. Think through what the goals are. We do not want to retire as many |
20 |
>> people as possible. We do not want to frustrate people who do contribute |
21 |
>> to Gentoo. We do not want to discourage people who consider becoming new |
22 |
>> developers. At least I don't. |
23 |
>> |
24 |
>> 3. I think what's important is to keep packages maintained. I consider |
25 |
>> maintainership to be a duty, not a privilege. If someone is listed in |
26 |
>> metadata.xml, but is not really maintaining the package, that creates a |
27 |
>> formal illusion that the package is maintained, and may prevent other |
28 |
>> people from stepping up and taking maintenance of that package. |
29 |
>> |
30 |
>> 4. I suggest that we focus on the above: keeping packages maintained. |
31 |
>> Taking packages out of hands of inactive/overworked maintainers is good. |
32 |
>> They can always become _more_ active, which is easier if they retain cvs |
33 |
>> access. If they make a single commit every 3-6 months, I'm fine with |
34 |
>> that as long as things are maintained properly. |
35 |
>> |
36 |
>> 5. Remember that cvs/bugzilla activity is not the only way of |
37 |
>> contributing. It's probably most tanglible and very needed, but let's |
38 |
>> not reduce real people and their real world situations, and their effort |
39 |
>> to contribute to just dates and numbers. |
40 |
>> |
41 |
>> Paweł |
42 |
>> |
43 |
>> |
44 |
> |
45 |
> +1 |
46 |
> |
47 |
> Even though I am a relatively new developer, I too got an email |
48 |
> stating my inactivity (not from undertakers@). My main purpose for |
49 |
> becoming a dev was not for ebuild work, but more for coding. Three |
50 |
> months is way too short to be making that type of list. |
51 |
> |
52 |
> For all those young devs out there still in college/university. You |
53 |
> will find that time accelerates as you age. 3 months may seem a long |
54 |
> time for you now, but give it another 5-10 years and you'll discover |
55 |
> that 3 months can go by quite quickly. Especially with a family (wife, |
56 |
> kids, pets) and a full time job. |
57 |
> |
58 |
> -- |
59 |
> Brian Dolbec <dolsen@g.o> |
60 |
|
61 |
Nobody said the policy is correct. I face the same problems so the |
62 |
policy might not be appropriate anymore. However, I totally disagree |
63 |
with |
64 |
the way Doug started this thread. Calling us "brain dead" ? No sorry, |
65 |
I am not willing to discuss anything about this policy nor willing to |
66 |
change it if someone can't behave properly and ask us nicely to |
67 |
discuss the problem. We never *insulted* or *threated* anyone with |
68 |
retirement, we are extremely polite and we just ask for status updates |
69 |
in order to clean up metadata, reassign bugs and look for new |
70 |
maintainers of unattended packages. Nobody ever complained in the |
71 |
past, and all of them were willing to drop themselves from metadata |
72 |
without problems. But I never expected this attitude just for asking |
73 |
"hey are you there? do you still want to maintain all these packages? |
74 |
any ETA on coming back". Seriously... |
75 |
|
76 |
-- |
77 |
Regards, |
78 |
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 |