Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] About some developers in devaway status that maybe are no longer active at all
Date: Fri, 08 Jul 2011 15:23:36
Message-Id: 1310138565.29572.5.camel@localhost
In Reply to: Re: [gentoo-dev] About some developers in devaway status that maybe are no longer active at all by Markos Chandras
1 El vie, 08-07-2011 a las 17:02 +0300, Markos Chandras escribió:
2 > -----BEGIN PGP SIGNED MESSAGE-----
3 > Hash: SHA512
4 >
5 > On 08/07/2011 04:31 μμ, Pacho Ramos wrote:
6 > > Due me recently taking xsane due it being not fixed/updated for a long
7 > > time, I noticed its maintainer was in devaway since 2010 September.
8 > >
9 > > Maybe they should be pinged and retired if no reply is received like
10 > > done with other cases. What do you think? :-/
11 > >
12 > > That people that seems to be inactive for a long time look to be the
13 > > following:
14 > > http://dev.gentoo.org/devaway/
15 > >
16 > > battousai -> Already in retirement process (but looks stalled since end
17 > > 2010, not sure why, probably retirement team didn't have time?) ->
18 > > https://bugs.gentoo.org/show_bug.cgi?id=34864
19 > >
20 > > blackace -> not sure about his current status, looks like he will move
21 > > to staffer per https://bugs.gentoo.org/show_bug.cgi?id=45816 , in that
22 > > case, maybe his devaway status could be removed.
23 > >
24 > > falco -> doesn't seem to be active for a long time
25 > >
26 > > fox2mike -> the same case
27 > >
28 > > markusle -> already handled in
29 > > https://bugs.gentoo.org/show_bug.cgi?id=105599
30 > >
31 > > mrpouet -> https://bugs.gentoo.org/show_bug.cgi?id=266794
32 > >
33 > > phosphan -> looks to be unavailable for some months :-/
34 > >
35 > > tanderson -> Looks to not have committed for a long time, but I think he
36 > > had other responsibilities in Gentoo (maybe the same applies to other
37 > > people listed here)
38 > >
39 > > titefleur -> already handled in
40 > > https://bugs.gentoo.org/show_bug.cgi?id=195714
41 > >
42 > > vorlon -> looks to not have committed everything to the tree since 2010
43 > >
44 > >
45 > >
46 > > As some people are already being retired (like mrpouet), I thought that
47 > > would be interesting to start dropping them from metadatas of packages
48 > > they maintain, moving them to their respective herds or to
49 > > maintainer-needed (after sending a mail to gentoo-dev announcing what
50 > > packages are up to grabs). I can do this if you want.
51 > >
52 > >
53 > > There are also some devaway entries that could probably be updated or
54 > > removed by affected developers :-/
55 > >
56 > > Best regards and thanks for taking care.
57 > Hi,
58 >
59 > Truth is that we do not touch metadata.xml entries or project pages
60 > until infra people process the accounts of the inactive developers. When
61 > a developer is being processed by the infrastructure team, then we clean
62 > metadata.xml entries and the project pages. Additionally, we announce
63 > the orphaned packages in -dev-announce mailing list. Here[1] you can see
64 > the steps we follow to retire a developer.
65 > If you want to see the pending retirements, search bugzilla for bugs
66 > assigned to retirement@g.o.
67 > As a side note, undertakers team is understaffed so we are not very fast
68 > in spotting and warning inactive developers. You can always help us if
69 > you want. Just drop an email to us.
70 >
71 > [1]:http://www.gentoo.org/proj/en/devrel/undertakers/
72 > - --
73 > Regards,
74 > Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
75
76
77 Thanks for the link
78
79 The problem of the current steps order is that, until we "Wait for
80 Infrastructure, Planet and Forums admins to retire developer in question
81 before proceeding further." (first step of point 8), some months pass
82 with bugs being ignored and ebuilds getting outdated and buggy. Why not
83 make the cleanup at first "point 8" step? I mean, just after it's
84 decided at point 7 to retire the development, try to get bugs and
85 packages properly reassigned as soon as possible to prevent them from
86 get unattended for a long time, and, after that, proceed with the
87 remaining steps. What do you think?

Attachments

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

Replies