Dormant Accounts
Gervase Markham
been able to compare it to the output of my "active-accounts.pl" script.
Setting the time interval at six months, I get the following statistics
(fixed-width font required; note these numbers and percentages are
_active_, not _inactive_):
Active last 6 mo. Active last 12 mo. Difference
Hg: 251/536 (47%) 298/536 (56%) 47 (9%)
CVS: 94/512 (18%) 119/512 (23%) 25 (5%)
SVN: 157/334 (47%) 170/334 (51%) 13 (4%)
So it looks like 6 vs. 12 months makes some difference, but not a big
one. Of course, what we really want to know is how many people are
inactive for more than 6 months and then come back. That's harder to
work out. CVS is clearly on the way out. The high Hg dormancy rates
(over 50% in the last 6 months) are surprising, given how short a time
we've been using it; perhaps the initial list of Hg committers was based
on the list of CVS committers?
Some of the actual names are slightly surprising at first glance, but
perhaps explainable. For example, the following is an incomplete list of
addresses @mozilla.com have not (as far as I can see) checked into Hg in
the past 12 months:
blizzard
dascher
justdave
justin
ladamski
mzeier
oremj
While these are big project names, I guess perhaps they do things other
than working directly on the code, these days? The other possibility is
that my script has a bug, which is entirely possible :-)
It does raise the question of whether we keep open the accounts of
people who are clearly still major project contributors, or whether we
shut them like anyone else's and they have to ask for them to be
reopened if they need them. In one sense, these are the riskiest - who
is going to bat an eyelid if they see blizzard checking in?
Comments welcome.
Gerv
Robert Kaiser
> For example, the following is an incomplete list of
> addresses @mozilla.com have not (as far as I can see) checked into Hg in
> the past 12 months:
>
I'm sure that David Ascher has contributed to comm-central, does he have
a second account, did your analysis miss that repo, or did someone else
check in his work?
Robert Kaiser
Gervase Markham
> I'm sure that David Ascher has contributed to comm-central, does he have
> a second account,
Not unless it doesn't contain the word "ascher".
> did your analysis miss that repo,
comm-central is definitely in the list of repos the script was supposed
to include.
> or did someone else
> check in his work?
That could be true. This is where we miss Bonsai for hg, because it's
not possible to search the log for particular people.
Perhaps we could ask him?
Gerv
Gijs Kruitbosch
Looks like it, from a look at
http://hg.mozilla.org/comm-central/pushloghtml?&enddate=now&path=mailnews&startdate=1+week+ago
it seems like all his patches were checked in by Mark Banner (Standard8).
~ Gijs
L. David Baron
> That could be true. This is where we miss Bonsai for hg, because it's
> not possible to search the log for particular people.
The stuff that I've pushed to mozilla-central is:
http://hg.mozilla.org/mozilla-central/pushloghtml?user=dba...@mozilla.com
Is that something like what you were looking for?
Note that this includes changes by me and changes by other people;
it's the use of my hg push access. And none of the commits are
actually from dba...@mozilla.com, since the changeset author is
dba...@dbaron.org for things that I write.
(Were you searching the pushlog or the "From" field of the
changesets?)
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
David Ascher
pushed. By others. Was I mistaken?
On 2009-10-08, at 1:34 PM, Gijs Kruitbosch <gijskru...@gmail.com>
wrote:
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
Mark Banner
> Afaik I didn't have commit access to c-c, so all my patches have been
> pushed. By others. Was I mistaken?
Didn't you get an account so you could push to a user-repo?
Standard8
mco...@mozilla.com
down recently, but not after the lockdown.
-- Mike
On 2009-10-08, at 5:15 PM, Mark Banner <bugz...@invalid.standard8.plus.com
> wrote:
David Ascher
On 2009-10-08, at 5:44 PM, mco...@mozilla.com wrote:
> If he had, he would have had access to comm-central until we locked
> it down recently, but not after the lockdown.
>
> -- Mike
>
> On 2009-10-08, at 5:15 PM, Mark Banner <bugz...@invalid.standard8.plus.com
> > wrote:
>
Christopher Blizzard
>
> While these are big project names, I guess perhaps they do things
> other than working directly on the code, these days? The other
> possibility is that my script has a bug, which is entirely possible :-)
>
> It does raise the question of whether we keep open the accounts of
> people who are clearly still major project contributors, or whether we
> shut them like anyone else's and they have to ask for them to be
> reopened if they need them. In one sense, these are the riskiest - who
> is going to bat an eyelid if they see blizzard checking in?
I haven't touched code in a while, but it's possible that I will in the
future. Those muscles have weakened but they aren't entirely gone. :)
--Chris
Gervase Markham
> I haven't touched code in a while, but it's possible that I will in the
> future. Those muscles have weakened but they aren't entirely gone. :)
Right :-) So the question is: what's the best policy?
Do we email all the dormant people saying "please reply if you want to
keep your access"? That's a reasonable amount of admin. Or do we just
disable them?
If we make sure there's a well-documented and lightweight process for
getting re-enabled (no vouching or anything of that sort, just file a
bug on IT), then perhaps just disabling them might be OK.
Gerv
Gervase Markham
> On Thursday 2009-10-08 18:28 +0100, Gervase Markham wrote:
>> That could be true. This is where we miss Bonsai for hg, because it's
>> not possible to search the log for particular people.
>
> The stuff that I've pushed to mozilla-central is:
> http://hg.mozilla.org/mozilla-central/pushloghtml?user=dba...@mozilla.com
> Is that something like what you were looking for?
Oh, brilliant :-) Is there a query form where I might have discovered
this capability? Or is it undocumented?
> (Were you searching the pushlog or the "From" field of the
> changesets?)
I used the content of the <author> tags in the Atom pushlog:
http://hg.mozilla.org/mozilla-central/pushlog
(and, obviously, parallel URLs for all the other repos)
Gerv
Simon Paquet
>> I haven't touched code in a while, but it's possible that I will
>> in the future. Those muscles have weakened but they aren't
>> entirely gone. :)
>
> Right :-) So the question is: what's the best policy?
>
> Do we email all the dormant people saying "please reply if you want
> to keep your access"? That's a reasonable amount of admin. Or do we
> just disable them?
From a access security POV we should just disable them.
> If we make sure there's a well-documented and lightweight process
> for getting re-enabled (no vouching or anything of that sort, just
> file a bug on IT), then perhaps just disabling them might be OK.
IMO we should at least have one person vouch for the re-enabling of
a dormant user account.
This person should also have the option to ask for the full process
being applied to a re-enable candidate, e.g. if we would re-enable an
account that has been formant for 3-5 years we're not really sure,
whether the person that wants his account be active again is fully
aware of our current process, tools, policies, etc.
Simon
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog: http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
L. David Baron
> On 08/10/09 19:02, L. David Baron wrote:
>> On Thursday 2009-10-08 18:28 +0100, Gervase Markham wrote:
>>> That could be true. This is where we miss Bonsai for hg, because it's
>>> not possible to search the log for particular people.
>>
>> The stuff that I've pushed to mozilla-central is:
>> http://hg.mozilla.org/mozilla-central/pushloghtml?user=dba...@mozilla.com
>> Is that something like what you were looking for?
>
> Oh, brilliant :-) Is there a query form where I might have discovered
> this capability? Or is it undocumented?
As far as I know it's undocumented and there's no UI exposed, just
like the pushloghtml?fromchange=...&tochange=... URLs that we use
for regression ranges, and perhaps other features that I don't know
about.
Axel Hecht
Guess
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/c88bf6c80d4e/pushlog-feed.py#l244
is as close as it gets to documentation right now.
Axel
Gervase Markham
> IMO we should at least have one person vouch for the re-enabling of
> a dormant user account.
What do you hope to gain by requiring that?
> This person should also have the option to ask for the full process
> being applied to a re-enable candidate, e.g. if we would re-enable an
> account that has been formant for 3-5 years we're not really sure,
> whether the person that wants his account be active again is fully
> aware of our current process, tools, policies, etc.
I certainly think people coming back need to be pointed to the right
resources. But I think we need an optimistic rather than a pessimistic
algorithm here. Let's take it up with them in the rare instance that
they don't read the documents and mess something up. :-)
Gerv
Simon Paquet
>> IMO we should at least have one person vouch for the re-enabling of
>> a dormant user account.
>
> What do you hope to gain by requiring that?
I hope to gain enough confidence in the person, whose account is
re-enabled, that he's aware of our current policies and the
changed technical infrastructure.
Let's not forget, that we we've moved to a whole new VCS, which
offers many new possibilities to screw up. We've also moved to new
policies requiring tests, talos runs, tryserver builds, etc.
I want to have confidence that this is is really known and understood
by the person with the re-enabled account. Trust is not an indefinite
resource.
Mike Connor
On 13-Oct-09, at 7:00 AM, Simon Paquet wrote:
> Gervase Markham wrote on 13. Oct 2009:
>
>>> IMO we should at least have one person vouch for the re-enabling of
>>> a dormant user account.
>> What do you hope to gain by requiring that?
>
> I hope to gain enough confidence in the person, whose account is
> re-enabled, that he's aware of our current policies and the
> changed technical infrastructure.
>
> Let's not forget, that we we've moved to a whole new VCS, which
> offers many new possibilities to screw up. We've also moved to new
> policies requiring tests, talos runs, tryserver builds, etc.
>
> I want to have confidence that this is is really known and understood
> by the person with the re-enabled account. Trust is not an indefinite
> resource.
Trustworthiness isn't something that evaporates over time. I strongly
believe that anyone who has shown our trust to be justified in the
past is entirely capable of getting up to speed again without having
to jump through hoops.
-- Mike
Simon Paquet
>> I hope to gain enough confidence in the person, whose account is
>> re-enabled, that he's aware of our current policies and the
>> changed technical infrastructure.
>>
>> Let's not forget, that we we've moved to a whole new VCS, which
>> offers many new possibilities to screw up. We've also moved to new
>> policies requiring tests, talos runs, tryserver builds, etc.
>>
>> I want to have confidence that this is is really known and understood
>> by the person with the re-enabled account. Trust is not an indefinite
>> resource.
>
> Trustworthiness isn't something that evaporates over time. I strongly
> believe that anyone who has shown our trust to be justified in the
> past is entirely capable of getting up to speed again without having
> to jump through hoops.
I totally disagree here. People, who come back to the project after
three, four or more years will most likely have no clue about what's
happened inside the project code-, tool- and policy-wise.
These people should show their renewed commitment and this should be
evidenced by a single person as a voucher. I don't consider this
"jumping through hoops". This is just minimal due diligence to
protect our most important asset, our code repositories.
Shawn Wilsher
> I totally disagree here. People, who come back to the project after
> three, four or more years will most likely have no clue about what's
> happened inside the project code-, tool- and policy-wise.
though. We've trusted them in the past to keep up on this, and they
haven't done anything to lose that trust, so why can't we trust them
now? They have to file a bug anyway to get access back, so when we give
it back to them, we can even remind them to read up on new policies.
/sdwilsh
Robert Accettura
> Shawn Wilsher wrote:
>
> >> I totally disagree here. People, who come back to the project after
> >> three, four or more years will most likely have no clue about what's
> >> happened inside the project code-, tool- and policy-wise.
> >
> >Of course they won't know. That's not the argument being made here
> >though. We've trusted them in the past to keep up on this, and they
> >haven't done anything to lose that trust, so why can't we trust them
> >now?
>
> Because they gained that trust under different conditions then. Those
> conditions have changed, so we should at least impose some minimal
> restrictions (and requiring just one voucher is minimal compared to the
> regular process) for them to re-acquire that trust.
>
They were trusted in the past to only use commit access with an
understanding of policies and procedure. What specifically makes them
untrustworthy after an absence? What specifically leads to the belief that
said person would suddenly disregard any documentation on such policies? If
it's the result of prior incidents, that's a whole other story. But a
blanket policy seems unnecessary and burdensome.
It seems to me if the initial vouching is done right (and to my knowledge it
has been), people with commit access are pretty conscious of policy. I
don't think people suddenly come back with a disregard for policy. If there
are people blatantly disregarding policy (understanding mistakes happen to
everyone, no need to be a vcs-nazi), then those privileges should be revoked
then, not after an absence.
That said, the "How to Submit a Patch" page[1] seems like the ideal place to
add a link to "if you have commit privileges" page (does this already
exist?) and thoroughly update the process for committing, complete for each
vcs and project (if any differences). Then anyone given commit privileges,
or having them reinstated should simply be given that link when commit
privileges are turned back on. The page already discusses code review, just
needs more details on committing for those with the privilege. I think that
would be adequate for the situation. With the exception on committing code,
it's seems like a pretty good refresher at a glance.
Just my $0.02.
-R
1. https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch
Mike Connor
On 13-Oct-09, at 11:25 AM, Simon Paquet wrote:
> Mike Connor wrote on 13. Oct 2009:
>
>>> I hope to gain enough confidence in the person, whose account is
>>> re-enabled, that he's aware of our current policies and the
>>> changed technical infrastructure.
>>> Let's not forget, that we we've moved to a whole new VCS, which
>>> offers many new possibilities to screw up. We've also moved to new
>>> policies requiring tests, talos runs, tryserver builds, etc.
>>> I want to have confidence that this is is really known and
>>> understood
>>> by the person with the re-enabled account. Trust is not an
>>> indefinite
>>> resource.
>> Trustworthiness isn't something that evaporates over time. I
>> strongly believe that anyone who has shown our trust to be
>> justified in the past is entirely capable of getting up to speed
>> again without having to jump through hoops.
>
> I totally disagree here. People, who come back to the project after
> three, four or more years will most likely have no clue about what's
> happened inside the project code-, tool- and policy-wise.
That's a matter of knowledge, not trustworthiness. I trust that
someone who has been absent from the project for a considerable period
of time would ensure they're up to speed on when and where to commit
before asking for commit rights again, or at least before committing
to any repository. Have we had anyone have problems like this that
vouching would have prevented?
> These people should show their renewed commitment and this should be
> evidenced by a single person as a voucher. I don't consider this
> "jumping through hoops". This is just minimal due diligence to
> protect our most important asset, our code repositories.
These are individuals who have earned our trust already, and stayed
within the rules after they got access, who have simply taken a break
from the project and come back. Arguing that we should default to not
trusting them when they come back really just seems... bizarre, to be
frank.
All that said, let's be practical here: getting a single voucher, for
someone who's already established trustworthiness with their track
record, would be utterly trivial. You're just adding a procedural
hoop, whether you want to believe it or not.
-- Mike
Justin Dolske
> Then anyone given commit privileges,
> or having them reinstated should simply be given that link when commit
> privileges are turned back on.
Yeah, I started replying to the same effect, and noticed you beat me to
it. Another useful summary is Gerv's recent creation of:
https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities
I'm sympathetic to Simon's point, to a degree. If the conditions (and
"trust", though I don't like that loaded word) for earning commit access
have radically changed during the time someone was dormant, then I'd
agree that grandfathering someone in wouldn't make sense. EG, that's
basically the same reasoning for why Netscape employees didn't get
automatic commit access to MoFo's repo.
So then the question becomes if such a change of conditions has happened
for any currently existing accounts. It sounds to me like that's not the
case, but I'd defer to those familiar with the suitability of people
getting access in the early days of the project [is that the right
cutoff point? I'm not exactly sure how far back current accounts go].
And, of course, if such a change occurs in the future, policy can be
updated.
Justin
Simon Paquet
> I'm sympathetic to Simon's point, to a degree. If the conditions
> (and "trust", though I don't like that loaded word) for earning
> commit access have radically changed during the time someone was
> dormant, then I'd agree that grandfathering someone in wouldn't
> make sense. EG, that's basically the same reasoning for why
> Netscape employees didn't get automatic commit access to MoFo's
> repo.
Exactly.
> So then the question becomes if such a change of conditions has
> happened for any currently existing accounts. It sounds to me
> like that's not the case, but I'd defer to those familiar with
> the suitability of people getting access in the early days of the
> project [is that the right cutoff point? I'm not exactly sure how
> far back current accounts go].
Well, the policies regarding commit access have changed quite a bit
over the years. We also have a new VCS, different checkin rules, etc.
What we don't know is how large the number of past contributors
(no checkin for more than 12 months) is that will come back someday
and how long their hiatus period will be. That's simply so, because
AFAIK we haven't disabled any inactive accounts so far ever.
Simon Paquet
>> I totally disagree here. People, who come back to the project after
>> three, four or more years will most likely have no clue about what's
>> happened inside the project code-, tool- and policy-wise.
> That's a matter of knowledge, not trustworthiness. I trust that
> someone who has been absent from the project for a considerable
> period of time would ensure they're up to speed on when and where
> to commit before asking for commit rights again, or at least before
> committing to any repository.
I don't. Is your trust better than mine?
> Have we had anyone have problems like this that vouching would have
> prevented?
Sorry, but that is simply a pretty stupid question, since we haven't
disabled inactive accounts in the past. We also have not monitored
account inactivity periods as far as I know. So how would we know
that some screwup some time ago would be related to this issue or
something else. You're bringing up strawmen now.
>> These people should show their renewed commitment and this should
>> be evidenced by a single person as a voucher. I don't consider
>> this "jumping through hoops". This is just minimal due diligence
>> to protect our most important asset, our code repositories.
> These are individuals who have earned our trust already,
s/already/in the past. That is quite a difference.
> and stayed within the rules after they got access,
... and then they left and now we don't know anything about their
knowledge level and their future behavior in our codebase.
> who have simply taken a break from the project and come back.
> Arguing that we should default to not trusting them when they come
> back really just seems... bizarre, to be frank.
If your best friend from high school comes to you after 10 years,
where you had no contact at all and asks you for 200 bucks, do you
give the money to him because you trusted him in the past or do you
try to get *at least* a minimal of current information about him and
his current circumstances before you decide on the money issue?
I know that I'd do the latter, but you may be a pretty trusting guy.
> All that said, let's be practical here: getting a single voucher,
> for someone who's already established trustworthiness with their
> track record, would be utterly trivial.
I don't know how you handle the voucher issue, but I believe that
most vouchers would *at least* look at some current bugs and bugfixes
of the returned contributor before they vouch for him or her.
So in my opinion this would be anything but trivial, but you may
have a different process in mind here.
Gervase Markham
> Gervase Markham wrote on 13. Oct 2009:
>
>>> IMO we should at least have one person vouch for the re-enabling of
>>> a dormant user account.
>>
>> What do you hope to gain by requiring that?
>
> I hope to gain enough confidence in the person, whose account is
> re-enabled, that he's aware of our current policies and the
> changed technical infrastructure.
I agree that these are important goals, but getting the person to find
someone to vouch for them is not going to achieve them.
Unless you are suggesting that they need to submit several patches etc.
just as a new contributor would. In which case I would say that
implementing that policy would lead to a lot of pushback on the account
disablement side. No-one wants their account disabled if re-enabling it
is going to be such a hassle. And so the overall security of the system
is reduced.
I suggest that a better way to achieve that goal is for them to be
pointed at the Committing Rules and Responsibilities document:
https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities
and for that document to be enhanced if it doesn't contain or link to
everything you think people should know.
Gerv
Gervase Markham
> Yeah, I started replying to the same effect, and noticed you beat me to
> it. Another useful summary is Gerv's recent creation of:
>
> https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities
In fact, one of the purposes of that document was to summarise what
people needed to know, so it could be shown to people returning to the
project after dormancy.
Gerv
Mike Shaver
> Sorry, but that is simply a pretty stupid question, since we haven't
> disabled inactive accounts in the past.
We effectively did, when we switching from pserver to ssh access,
since inactive people didn't get ssh keys installed.
Mike
Mike Shaver
> most vouchers would *at least* look at some current bugs and bugfixes
> of the returned contributor before they vouch for him or her.
This highlights one of the more poignant misalignments of our current
process, of course: the "trust" (horrible word) you talk about is
related to their understanding of our checkin policies, tree control
strategies and so forth. But none of that is visible by reading their
patches, since you don't have to understand those issues at _all_ to
produce great patches for others to commit on your behalf. This is
equally true of our current commit-access policy, but I don't know
that we should compound that error by applying it again to people who
have merely gone dormant, and not rogue.
If your friend from high school showed up and asked for $200, and told
you "I have read a lot of great books lately; quiz me on Dickens!"
would that make you more likely to give him the money?
Mike
Simon Paquet
>> I hope to gain enough confidence in the person, whose account is
>> re-enabled, that he's aware of our current policies and the
>> changed technical infrastructure.
>
> I agree that these are important goals, but getting the person
> to find someone to vouch for them is not going to achieve them.
>
> Unless you are suggesting that they need to submit several patches
> etc. just as a new contributor would. In which case I would say
> that implementing that policy would lead to a lot of pushback on
> the account disablement side. No-one wants their account disabled
> if re-enabling it is going to be such a hassle. And so the overall
> security of the system is reduced.
Well, the ideal process for someone coming back would look like this:
1. X finds a bug and provides a fix
2. X rans his patch against our automated tests
3. X asks for review from Y (and gets it)
4. X tries to checkin, but finds out that it doesn't work. He asks Y
to do the checkin for him and offers to watch the tree after the
checkin
5. Y tells X that he can get his commit rights back and that we will
vouch for him "because you still seem to know what you're doing"
6. X opens up a bug to get his commit rights back (and gets them)
That doesn't sound so bad, does it?
And if someone doesn't do 2) and does not know about the tree-watching
part in 4) there's always another bug where he can try that out and
get his commit rights back after the 2nd fix has run its course.
Simon Paquet
>> Sorry, but that is simply a pretty stupid question, since we haven't
>> disabled inactive accounts in the past.
>
> We effectively did, when we switching from pserver to ssh access,
> since inactive people didn't get ssh keys installed.
Do we know how many people were affected by this? I don't exactly
remember when we switched from pserver to ssh. I just know that it
happened somewhere between January 2004 (when I got webtree cvs
access) and October 2006 (when I got code cvs access).
Also given that fact I find it pretty remarkable that nearly 50% of
our VCS accounts are inactive (not used for 12 months).
John J. Barton
> Gervase Markham wrote on 15. Oct 2009:
>
>>> I hope to gain enough confidence in the person, whose account is
>>> re-enabled, that he's aware of our current policies and the
>>> changed technical infrastructure.
>>
>> I agree that these are important goals, but getting the person to find
>> someone to vouch for them is not going to achieve them.
>>
>> Unless you are suggesting that they need to submit several patches
>> etc. just as a new contributor would. In which case I would say that
>> implementing that policy would lead to a lot of pushback on the
>> account disablement side. No-one wants their account disabled if
>> re-enabling it is going to be such a hassle. And so the overall
>> security of the system is reduced.
>
> Well, the ideal process for someone coming back would look like this:
>
> 1. X finds a bug and provides a fix
> 2. X rans his patch against our automated tests
...
Personally I think that you are crazy not to immediately welcome anyone
who gets this far. This is an open source project, not Fort Knox.
Mike Shaver
<johnj...@johnjbarton.com> wrote:
> Personally I think that you are crazy not to immediately welcome anyone who
> gets this far. This is an open source project, not Fort Knox.
I think we should just make it a ton simpler for their patches to get
into the tree, but agree that we're probably hurting ourselves with
our current stance on being able to commit things -- even more so with
the baroque process for managing trees and patches and so forth. I
think that's best handled as a separate conversation, though, and one
that won't help us get this (I hoped minor) procedural piece sorted
out.
Mike
John J. Barton
> John J. Barton wrote:
>
>>> Well, the ideal process for someone coming back would look like this:
>>>
>>> 1. X finds a bug and provides a fix
>>> 2. X rans his patch against our automated tests
>> ...
>> Personally I think that you are crazy not to immediately welcome anyone
>> who gets this far. This is an open source project, not Fort Knox.
>
> he does 1 and 2 one time? You're not serious, are you?
I am saying that anyone with so much determination and commitment that
they and install the source, build it, debugs a problem, finds a fix,
codes the patch, gets it to work, extracts the diff, attaches it to the
bug, learns about the test system, figures out how to run the tests with
the patch, and returns to the bug to report the results should
immediately be contacted and encouraged. The end result of such contact
should be access to the source tree if that is what will entice them to
continue. You'll know soon enough after contacting them if they will be
able to participate in the rest of the patch-landing process or not.
The goal of the 'process' should be to protect the project as a whole.
For that you need to emphasize bringing in interested developers, not
excluding make-believe bad guys.
jjb
John J. Barton
> John J. Barton wrote:
>
> I don't follow how bringing in interested developers and giving lots of
> one-time patchers commit rights is any way related.
But your proposal was for an elaborate process for users who had commit
access in the past. I think you have it all backwards. The policy here
ought to focus on how the community encourages a patcher to learn the
process of committing patches in an acceptable way, not on how to
precisely define the hoops they need to jump through to earn a right.
The success metric should not be how many one-time patchers got turned
away, but how many first-time patchers became community members.
jjb