Developer Retirements
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Olexa wrote:
> On Mon, Mar 9, 2009 at 1:44 PM, Doug Goldstein <cardoe@gentoo.org> 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.

As opposed to those same bugs being assigned to maintainer-needed and getting
lots of attention?

Marijn

- --
Sarcasm puts the iron in irony, cynicism the steel.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm1oXIACgkQp/VmCx0OL2wymACfWGNpz9UgudSfO0VkbHiXROL5
IgUAnRtIgbhQTj2pSyCC5E8VpPpQQwtR
=z5EV
-----END PGP SIGNATURE-----

Developer Retirements
 

Marijn Schouten (hkBst) wrote:


As opposed to those same bugs being assigned to maintainer-needed and getting
lots of attention?



The inactive dev can just as easily resolve a m-needed bug as one that
is assigned to himself. The added benefit that some people actually look
at the m-needed queue on rainy days. (me, patrick, loki_val, etc).


-Jeremy

Developer Retirements
 

On Monday, March 9, 2009 11:44:55 Doug Goldstein 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.
>
> What we really need is not a smaller, leaner development force. But a
> leadership team that's smaller and more effective and willing to take
> charge to get something done. I'm hoping that we can get away from the 6
> month GLEP process and towards something more streamlined.
>
> --
> Doug Goldstein


It is possible that maybe we've been too forceful in retiring people who still
wish to contribute. Sometimes it appears that way from the outside. But as
I am not on that team, I don't really know and therefore will not attempt to
pass judgement on their processes. From what I have seen and understand they
do try to make contact multiple times to understand the situation before
retiring anyone.

There is an important security aspect to retiring folks - commit abilities.
Perhaps in the case a dev wants to contribute but cannot in the near future
their commit privs can just be revoked until such time they ask for them to
be turned back on? I guess that would be an 'extended devaway' ?

Gordon Malm (gengor)

Developer Retirements
 

On Mon, 9 Mar 2009 13:44:55 -0500
Doug Goldstein <cardoe@gentoo.org> wrote:

> I'm wondering what exactly is the harm in letting developers idle for
> a while?

Nothing, as long as they don't pretend to be maintaining packages while
they idle. See compnerd and his tonne of system-packages for reference.
It unnecessarily complicates things if people just "step out" for half a
year and don't leave an .away or re-assign their packages.

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

They are not being pushed out. One commit a month is not much to ask.
That's one speeling fix per month to be considered an active dev.

If they can't be bothered to do that, well, I really feel for them, but
they should just hand over their keys and submit their yearly commit as
a patch instead. They're even welcome to CC me, citing this thread and
my promise to commit their patch and I shall do it.

Problem solved.

/loki_val

Developer Retirements
 

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
project afterwards.

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
extremely long.

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
you insist.

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.

Kind regards,

Lukasz Damentko

Developer Retirements
 

Gordon Malm <gengor@gentoo.org> posted
200903091617.48682.gengor@gentoo.org, excerpted below, on Mon, 09 Mar
2009 16:17:48 -0700:

> There is an important security aspect to retiring folks - commit
> abilities. Perhaps in the case a dev wants to contribute but cannot in
> the near future their commit privs can just be revoked until such time
> they ask for them to be turned back on? I guess that would be an
> 'extended devaway' ?

This is my concern, and one that infra has expressed on occasions when
the topic has come up before. On principle, a stale yet still active
authorization is an authorization just begging to have some cracker
stumble on it. We don't want some still active authorization and key
from two years ago getting stolen and used to try to slip a bad commit
under the radar, where the dev won't have a clue as he's not been active
for years and has forgotten the key was even stashed somewhere /to/ get
stolen.

The six-month retirement thing is a backstop to prevent things like that
from occurring. Maybe an extended "dev-away" mechanism, whereby the dev
just needs to notify devrel that he's going active again (preferably in-
person or with some inside joke or other verifiable mechanism so it's
demonstrably /not/ some cracker simply finding the key), could be
preferred to the whole inboarding, mentoring, etc, process all over again.

Then again, a lot can change in two years. The former dev may not know
about the new EAPIs and other policy and etc. changes, and having taken
the quiz and gone thru the process before, it should be easier the second
time and could be expedited, but there's an argument for still going thru
it, just to start off again on the right foot, as they say. Also, that
time would serve as an intro period between the returning dev and new
ones that have come in since his retirement. So yeah, maybe a somewhat
abridged inboarding is appropriate for a returning dev, but eliminating
it entirely, as an extended dev-away, might be going too far.

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

Developer Retirements
 

On Tue, March 10, 2009 7:07 am, Duncan wrote:
> Gordon Malm <gengor@gentoo.org> posted
> 200903091617.48682.gengor@gentoo.org, excerpted below, on Mon, 09 Mar
> 2009 16:17:48 -0700:
>
>> There is an important security aspect to retiring folks - commit
>> abilities. Perhaps in the case a dev wants to contribute but cannot in
>> the near future their commit privs can just be revoked until such time
>> they ask for them to be turned back on? I guess that would be an
>> 'extended devaway' ?
>

[...]

> We don't want some still active authorization and key
> from two years ago getting stolen and used to try to slip a bad commit
> under the radar [...]

With some devs reviewing gentoo-commits@, I highly doubt that this commit
could go unnoticed more than a few hours.

--
Pierre-Yves Rofes
Gentoo Linux Security Team

Developer Retirements
 

"Pierre-Yves Rofes" <py@gentoo.org> posted
a4345526fd26a2a6f5dd3cccb4e9767d.squirrel@mail.rof es.fr, excerpted below,
on Tue, 10 Mar 2009 11:21:55 +0100:

>> We don't want some still active authorization and key
>> from two years ago getting stolen and used to try to slip a bad commit
>> under the radar [...]
>
> With some devs reviewing gentoo-commits@, I highly doubt that this
> commit could go unnoticed more than a few hours.

That's a relatively new and very good change, and may indeed change the
thinking on this one, some. But why even risk that when (as rane just
posted) there's all deliberate effort to contact on the way out and a
fast return, for someone who hasn't put an away up, has ignored the
contact efforts or after being contacted said yes, retire me, and who
hasn't had any commits in months already, with no indication that's going
to change.

Can you imagine the PR on even a few hours' breach, when it turns out
they'd been inactive for years, but their login was still active? Would
you want it to be /your/ machines affected?

Yes, it can happen with even active devs, but the risk is considered
worth it there. But devs that have been inactive for months or years,
and who have ignored contacts or even asked to be retired after the
contact? IMO that's needless risk, (almost) entirely down-side (with
"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

Developer Retirements
 

On Tue, Mar 10, 2009 at 3:21 AM, Pierre-Yves Rofes <py@gentoo.org> wrote:
> On Tue, March 10, 2009 7:07 am, Duncan wrote:
>> Gordon Malm <gengor@gentoo.org> posted
>> 200903091617.48682.gengor@gentoo.org, excerpted below, on Mon, 09 Mar
>> 2009 16:17:48 -0700:
>>
>>> There is an important security aspect to retiring folks - commit
>>> abilities. Perhaps in the case a dev wants to contribute but cannot in
>>> the near future their commit privs can just be revoked until such time
>>> they ask for them to be turned back on? I guess that would be an
>>> 'extended devaway' ?
>>
>
> [...]
>
>> We don't want some still active authorization and key
>> from two years ago getting stolen and used to try to slip a bad commit
>> under the radar [...]
>
> 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

>
> --
> Pierre-Yves Rofes
> Gentoo Linux Security Team
>
>
>
>
>

Developer Retirements
 

On Tuesday 10 of March 2009 16:29:56 Alec Warner wrote:

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

I somewhat share the view that's rather easy to slip some parts in stream of
commits.

Would it be possible to introduce some kind of *commit*/*ebuild* *reviewing*
*system*?
So that every change to tree would need to be somewhat approved by anyone else
- just to provide extra pair of eyes to catch early some silly, obvious,
unnecessary or very tricky parts of code. It could be quite cheap to introduce
and yet not-demotivating step to increase overall quality.

I bet it's a practice already by some developers but it would be nice if it
could be introduced as a rule for everyone (possibly requiring some GLEP).
Personally I don't find it at all humiliating if someone is capable of QA my
code - I actually very appreciate it, and I guess most developers do.

Should I start separate thread?

--
regards
MM