On Mon, Mar 9, 2009 at 1:55 PM, Jeremy Olexa <firstname.lastname@example.org> wrote:
On Mon, Mar 9, 2009 at 1:44 PM, Doug Goldstein <email@example.com> wrote:
> I'm wondering what exactly is the harm in letting developers idle for a
> while? While they might not be actively committing they are still
> knowledgeable people that are just as capable as everyone else to push in a
> fix for small packages. There's lots of bugs in bugzilla with items that
> just need someone active to commit them. There's even a lot of these items
> are filed by retired Gentoo developers who could have easily pushed this fix
> for all users. The fact that someone only does one commit a year does not
> marginalize their contribution. While it may be small it is improving the
> overall quality of the distro. I'm constantly seeing developers getting
> upset over getting pushed out.
The problem comes when $idle_dev has XX bugs assigned to them and they
don't get resolved and no one else knows that there are issues. Then
users get the attitude that they shouldn't even file bugs because no
one fixes them and they just sit there.
So, I agree with you as long as $idle_dev doesn't pretend to maintain
packages and the team that they belong to doesn't consist of people of
the same activity level. (rendering the team useless too).
So let's re-assign the bugs to m-needed and not nuke the person.
03-10-2009, 04:10 PM
On Mon, Mar 9, 2009 at 10:18 PM, Lukasz Damentko <firstname.lastname@example.org> wrote:
Okay, let me explain in detail.
Undertakers contact devs who didn't touch CVS for at least two months,
are considered inactive in the bugzilla and have no current .away set.
After the initial contact, something like 3/4 of e-mailed people
respond very quickly and explain why they are gone (usually family and
work trouble, weddings, army service, health issues, moving out/in and
so on, so called real life) and in such cases we do not retire them
but let them resolve whatever trouble they are in and return to the
There are dozens of devs in the project who had such a conversation
with me or other undertakers and all can confirm retirement was
abandoned right away after they gave valid reasons for their absence
and the only consequence was poking about missing .away and asking
when they are planning to get back to work.
Those people wouldn't even be contacted if their .aways stated why
they are gone and for how long. Therefore a REMINDER: Please do set
your .away. Thanks.
The rest are usually people who already gave up on the project, just
for various reasons didn't say bye yet. They often have no commits for
many months despite undertakers poking them a bunch of times. Half a
year period without even touching CVS and bugs isn't that uncommon for
them. I can give you specific examples if you really want some. I'd
prefer to avoid pointing fingers at people though.
Those folks either say goodbye to everyone after being contacted by us
or do not respond at all, in which case, if we get no response to our
two e-mails and an open retirement bug from them after more than a
month, we consider them missing in action and go on with their
retirement. If they appear suddenly at any point of this procedure and
say they want to stay, we either abandon retirement completely or only
send them to recruiters to redo their quizzes if their absence was
I don't think how we can proceed differently in above kinds of
situations. Do you suggest we stopped e-mailing people who seem gone
from the project (how would we find out those who are really gone
then?), stopped retiring people who mail -dev/-core and say goodbye or
stopped retiring people who aren't responding to their mail and bugs
named "Retire: Person's Name" for months?
There's only one controversial group of inactive devs:
There are some people who would prefer to stay in the project although
they can't really give a good reason what for. Usually they claim they
belong to a number of projects although they don't put any regular
work into any of them and leads of this projects often haven't even
heard there's such a person on board. They sometimes were members of
this projects years ago, sometimes wanted to be members and sometimes
only imagine they are members of them. I can give specific examples if
Those we try to encourage to find a new job within Gentoo and often
they do. I can name one who yesterday did start his new Gentoo work
after years of slacking. :-)
They are the smallest group of those we contact and process, I could
maybe name 5 or 6 of those currently in Gentoo and that's it. There's
no pending retirement of such a person currently.
Really. Situation you name, when someone wanted to stay in Gentoo
despite not doing any actual work and got retired happened once or
maybe twice during the last year out of about a hundred retirements we
have processed. And all were extreme cases of close to zero activity
over many years with no promise of it ever increasing. We consider
those very carefully, they are always consulted with devrel lead. This
kind of decision isn't made lightly I can assure you.
Finally, if someone really wants to be a dev but got retired, he can
return to Gentoo within couple of weeks by reopening his retirement
bug, submitting quizzes to recruiters and waiting to get useradded.
Recruiters process returning devs extremely fast so returning to
Gentoo if someone really wants to isn't a problem at all. And there's
absolutely no way anyone from undertakers could stop someone from
being recruited again.
So summarising, the situation you're complaining about is extremely
marginal. You are invited to subscribe to retirement@ alias and read
its logs on bugzilla and see for yourself how rare occurrence it is.
I hope I explained everything completely. I'm happy to take questions
if you have any, and of course am open to suggestions.
Granted the people I've recently talked to about this or the people I remember bringing this issue up in the past had this happen to them before we had this firm policy in place so really you're addressing a lot of the issues.
But the whole act of making them go through all the hoops as a brand new developer is somewhat put off-ish to people wanting to come back. I honestly can't think of one developer that's come back and hasn't been up in arms about being made to go through all the hoops of a new developer.
03-10-2009, 04:13 PM
On Tue, Mar 10, 2009 at 8:35 AM, Duncan <email@example.com> wrote:
"almost" in there only as a CYA on an otherwise absolute "entirely"),
especially when reuptake is (as posted) so fast.
Duncan - List replies preferred. * No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." *Richard Stallman
So really an effective solution might be for the recruiters/retirement staff to change a user's shell with a script that spits out a message that says something to the effect of:
"You have been inactive for a while. Please contact recruiters to re-enable your account. This was done as a security measure."
Obviously a little friendlier would be better but everyone gets the gist. That'll prevent them from logging into infra boxes and from being able to do a commit.
03-10-2009, 04:36 PM
2009/3/10 Doug Goldstein <firstname.lastname@example.org>:
> So really an effective solution might be for the recruiters/retirement staff
> to change a user's shell with a script that spits out a message that says
> something to the effect of:
> "You have been inactive for a while. Please contact recruiters to re-enable
> your account. This was done as a security measure."
> Obviously a little friendlier would be better but everyone gets the gist.
> That'll prevent them from logging into infra boxes and from being able to do
> a commit.
First of all there's been a lot of returning devs from whom I heard no
word of complaint about the procedure. Bonsaikitten is one of them if
this argument really requires an example.
Now, if someone can't, has no time or is unwilling to redo his quiz...
what makes you think this person will make a good developer later on?
What will ensure quality of his contributions? After months or (in
most cases) years of not being a developer it's very likely the person
is out of touch with most current things in Gentoo and a conversation
with a recruiter may be really good learning experience.
I heard multiple times from recruiters that this is procedure is
necessary for returning developers. If you ask them, I'm sure they
will confirm those devs often need such refreshing and also are
appreciating the time put into it from the recruiting team.
Finally, what you are proposing (which I read as infra suspending
their access automatically instead of me or other undertaker
contacting the person first) far harsher and putting off than pretty
soft (and many say too soft) procedures we have now.
I personally would prefer to talk to such a person before suspending
them anything happens.
Please also remember that if we suspend access automatically and it's
suspended for some time, it will require jumping through hoops upon
returning just like one has to jump through them when being recruited
back. I don't think QA will allow us to just give access back without
prior checking if the person is current with everything a developer
should know. And if they did allow that, I wouldn't consider this a
03-10-2009, 05:59 PM
Doug Goldstein wrote:
> Granted the people I've recently talked to about this or the people I
> remember bringing this issue up in the past had this happen to them
> before we had this firm policy in place so really you're addressing a
> lot of the issues.
> But the whole act of making them go through all the hoops as a brand new
> developer is somewhat put off-ish to people wanting to come back. I
> honestly can't think of one developer that's come back and hasn't been
> up in arms about being made to go through all the hoops of a new developer.
The quizzes haven't changed that radically in the last couple of year.
Personally I wouldn't want people who have been inactive for ages to
just start committing as their information is more quite likely
outdated. Doesn't the fact that they complain about having to do work to
answer the quizzes prove this?
03-12-2009, 07:25 AM
tis 2009-03-10 klockan 08:29 -0700 skrev Alec Warner:
> > With some devs reviewing gentoo-commits@, I highly doubt that this commit
> > could go unnoticed more than a few hours.
> really? cause I bet I could slip something in; now I'm motivated to try ;p
Looking inside of package.mask this morning I think someone got there
# Tomas Chvatal <email@example.com> (6 Mar 2009)
You have that in between of two diffrent masks. Nothing more, nothing
So even thou some devs review gentoo-commits@ it seems like they are not
Łber-super-humans and sometimes even they miss things.
03-12-2009, 06:38 PM
Dne ńćtvrtek 12 BŇôezen 2009 09:25:17 Peter Hjalmarsson napsal(a):
> tis 2009-03-10 klockan 08:29 -0700 skrev Alec Warner:
> > > With some devs reviewing gentoo-commits@, I highly doubt that this
> > > commit could go unnoticed more than a few hours.
> > really? cause I bet I could slip something in; now I'm motivated to try
> > ;p
> Looking inside of package.mask this morning I think someone got there
> before you:
> # Tomas Chvatal <firstname.lastname@example.org> (6 Mar 2009)
> You have that in between of two diffrent masks. Nothing more, nothing
> So even thou some devs review gentoo-commits@ it seems like they are not
> √ľber-super-humans and sometimes even they miss things.
Nah actualy i just start writing at some line and spoted that i am not on the
top so i moved there and forget to remove. So please when you are updating
mask remove the line ;]
scarab@arcarius: ~/gentoo/gentoo-x86/profiles $ cvs diff -r 1.9550 -r 1.9549
RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v
retrieving revision 1.9550
retrieving revision 1.9549
diff -u -b -B -r1.9550 -r1.9549
--- package.mask 6 Mar 2009 00:57:49 -0000 1.9550
+++ package.mask 5 Mar 2009 10:34:01 -0000 1.9549
@@ -1,5 +1,5 @@
-# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.9550 2009/03/06
00:57:49 scarabeus Exp $
+# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.9549 2009/03/05
10:34:01 flameeyes Exp $
# When you add an entry to the top of this file, add your name, the date, and
# an explanation of why something is getting masked. Please be extremely
@@ -31,12 +31,6 @@
#--- END OF EXAMPLES ---
-# Tomas Chvatal <email@example.com> (6 Mar 2009)
-# Mask for removal per bug #261285
-# Unmaintained, broken, no new releases, don't work
-# due to 6.4.09
# Diego E. Petten√≤ <firstname.lastname@example.org> (5 Mar 2009)
# Masked pending removal for bug #261288, multiple issues.
# Removal scheduled for April 5th, 2009.
@@ -49,8 +43,6 @@
# better functionality with this driver
-# Tomas Chvatal <email@example.com> (6 Mar 2009)
# Thomas Sachau <firstname.lastname@example.org> (2 Mar 2009)
# Mask for removal, was merged into dev-java/fec
03-13-2009, 01:45 PM
Doug Goldstein <email@example.com> posted
eafa4c130903101013s3bb64404g9e65ca0fc8973021@mail. gmail.com, excerpted
below, on Tue, 10 Mar 2009 12:13:36 -0500:
> So really an effective solution might be for the recruiters/retirement
> staff to change a user's shell with a script that spits out a message
> that says something to the effect of:
> "You have been inactive for a while. Please contact recruiters to
> re-enable your account. This was done as a security measure."
> Obviously a little friendlier would be better but everyone gets the
> gist. That'll prevent them from logging into infra boxes and from being
> able to do a commit.
That does seem to take care of the security side (assuming the cracker
can't simply contact recruiters and get reenabled, no verification), yes.
That's my biggest concern. However, upon reading rane's replies, his
point that if retaking the quizes is hard, they probably DO need the
refresh, makes a lot of sense to me as well.
But even tho the knowledge aspect applies to every returning dev while
the security aspect above is (hopefully) low chance, lack of up-to-date
tech and policy knowledge (as addressed by the quizes) at worst breaks a
tree for a few hours or a package for perhaps a few months. If Gentoo
devs as a group are willing to live with that, so am I as a Gentoo user
and Gentoo system sysadmin. It's thus an entirely different level of
discussion than that of a relatively lower chance but much higher damage
potential security breach, which every Gentoo user (aka Gentoo system
sysadmin) therefore has an interest in.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman