Dormant Accounts - summary
Gervase Markham
discussion. The new policy is going to be as follows:
"SCM accounts inactive for more than 6 months may be disabled. If your
account has been disabled, you can have it re-enabled by <a>filing a
bug</a> in mozilla.org/Server Operations: Account Requests. Please make
sure you familiarize yourself with <a>current committing rules and
responsibilities</a>."
I will pass the names of the currently-dormant accounts to IT for them
to disable. I will also ask them what is the most appropriate severity
for such a bug. Re-enablement is technically simple, and so should be
able to happen very quickly - I would hope, often within minutes. But we
don't want to get people out of bed at 3am with a pager call.
* If we find that account reactivations are a common occurrence, we will
reconsider increasing the value of N.
* If we find it becomes common that people whose accounts are
reactivated are messing things up due to outdated knowledge, we will
consider strengthening the requirements for reactivation.
Gerv
Pascal Chevrel
For any disabling of localizers account on SVN, I want to be CCed on a
bug disabling their account. Some localizers work on web parts once or
twice a year for the major release and some have good reasons to be
absent for a year, for example our Turkish web localizer is now doing
his military service and won't commit in the 8 months to come, I
wouldn't want his account to be deactivated because of that.
Pascal
Mike Beltzner
our running code, not for our websites. Is this policy for all SCM or
just SCM for the code? Not sure that it makes a difference, other than
as Pascal writes below, it feels like there are higher numbers of
occasional committers to the web repositories.
cheers,
mike
On 2009-10-20, at 10:05 AM, Pascal Chevrel wrote:
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
Mike Connor
On 20-Oct-09, at 10:05 AM, Pascal Chevrel wrote:
> For any disabling of localizers account on SVN, I want to be CCed on
> a bug disabling their account. Some localizers work on web parts
> once or twice a year for the major release and some have good
> reasons to be absent for a year, for example our Turkish web
> localizer is now doing his military service and won't commit in the
> 8 months to come, I wouldn't want his account to be deactivated
> because of that.
Conversely, I _want_ his account to be deactivated because of that.
As long as server ops are quick about re-enabling access when he's
back, that's a clear case where disabling the account on a temporary
basis would make perfect sense.
-- Mike
Gervase Markham
> For any disabling of localizers account on SVN,
How do we tell which accounts belong to localizers?
> I want to be CCed on a
> bug disabling their account. Some localizers work on web parts once or
> twice a year for the major release and some have good reasons to be
> absent for a year, for example our Turkish web localizer is now doing
> his military service and won't commit in the 8 months to come, I
> wouldn't want his account to be deactivated because of that.
Why not, if to get it reactivated, one has to file a bug and wait half
an hour? If he's on military service, he's unlikely to notice his
account being abused.
Deactivating someone's account is not a criticism. :-)
Gerv
Mike Shaver
>
> On 20-Oct-09, at 10:05 AM, Pascal Chevrel wrote:
>
>> disabling their account. Some localizers work on web parts once or twice a
>> year for the major release and some have good reasons to be absent for a
>> year, for example our Turkish web localizer is now doing his military
>> service and won't commit in the 8 months to come, I wouldn't want his
>> account to be deactivated because of that.
>
> as server ops are quick about re-enabling access when he's back, that's a
> clear case where disabling the account on a temporary basis would make
> perfect sense.
Yes, I agree completely. Deactivating someone's account because
they're dormant isn't a punishment, and someone who knows they're
going to be inactive for a while should ideally be *telling* us that
so that we can deactivate until they come back. The account is of no
use to them during that period, but still represents attack surface:
it's just about the purest case I can imagine in support of such
deactivation.
Mike
Pascal Chevrel
> On 20/10/09 15:05, Pascal Chevrel wrote:
>> For any disabling of localizers account on SVN,
>
> How do we tell which accounts belong to localizers?
they are in the @localizers group on svn
>
> > I want to be CCed on a
>> bug disabling their account. Some localizers work on web parts once or
>> twice a year for the major release and some have good reasons to be
>> absent for a year, for example our Turkish web localizer is now doing
>> his military service and won't commit in the 8 months to come, I
>> wouldn't want his account to be deactivated because of that.
>
> Why not, if to get it reactivated, one has to file a bug and wait half
> an hour? If he's on military service, he's unlikely to notice his
> account being abused.
>
> Deactivating someone's account is not a criticism. :-)
I am more concerned about loosing contributors and the additional
administrative process, my personal experience is that giving localizers
svn access can take up to 3 weeks...
Pascal
Mike Shaver
> I am more concerned about loosing contributors and the additional
> administrative process, my personal experience is that giving localizers svn
> access can take up to 3 weeks...
For initial access, maybe -- this should be literally less than 24
hours. If it isn't, please have someone call my cell phone and I'll
make sure it happens quickly.
Mike
Pascal Chevrel
ok :)
pascal
Axel Hecht
Do we have the technical means to return useful error messages on hg
and/or svn for disabled accounts?
Just looking at the problems people have with getting their hg access
back up, it'd be really useful to get something more constructive than
"no suitable response from remote server". That was for "I forgot to set
my user name in ssh config", fwiw.
Axel
Gervase Markham
> Do we have the technical means to return useful error messages on hg
> and/or svn for disabled accounts?
It would be nice, wouldn't it? :-) I'll ask, but what would you change
about the policy if the answer is "no"? Or would you just ask me to make
sure the documentation covered this case?
Gerv
Axel Hecht
I'm selfish here, as I expect that Pascal and I will end up as first
line of defense for a good deal of those. I need a way to tell if
someone's account is disabled.
If we can't have an error message, I'd change the policy so that IT at
least has an intranet wiki page that's up-to-date on disabled accounts.
Or some other means to figure that out.
I guess that l10n-drivers would benefit from having an update on
disabled l10n accounts, too.
Axel
Mike Shaver
if their account is disabled, in addition to us sending them mail
if/when we disable it. I think that's a precondition here.
Mike
Reed Loden
Gervase Markham
> I'm selfish here, as I expect that Pascal and I will end up as first
> line of defense for a good deal of those. I need a way to tell if
> someone's account is disabled.
IT tells me it would be possible to implement a sensible error message.
I'm exploring this possibility with them. (Does anyone think that, if
implemented, an explanatory error message on attempted login would _not_
be sufficient?)
If it turns out to be too hard, then we'll implement the wiki page solution.
Gerv
Gervase Markham
> IT tells me it would be possible to implement a sensible error message.
> I'm exploring this possibility with them. (Does anyone think that, if
> implemented, an explanatory error message on attempted login would _not_
> be sufficient?)
https://bugzilla.mozilla.org/show_bug.cgi?id=524080 .
Gerv
Reed Loden
Gervase Markham <ge...@mozilla.org> wrote:
> I will pass the names of the currently-dormant accounts to IT for
> them to disable.
Now that I've actually seen the list of accounts to be deactivated[1],
I can say that both the policy and the tools used in gathering the
list of dormant accounts need work.
With regards to the policy, the 6 month period of dormancy should
take into account all SCMs, not each individual SCM. It does not make
sense to disable somebody's CVS account just because he/she has been
using SVN or Hg exclusively over the last 6 months.
With regards to the tools, all three generated lists have issues. The
list created for Hg is just completely wrong, given that it lists people
like Zack Weinberg who just received his Hg access within the last few
months [2] and has been actively committing patches. Mark Hammond is on
that list, too, and I know he's been working on the raindrop project for
Mozilla Labs. There are others, too, but those are just some examples.
It would be useful to know how Gerv is creating the list for Hg. The
list for SVN also surprises me, as it lists members of IT, who I know
use a private SVN repository for things, and such set up with various
POSIX requirements holds that they have svn_mozilla set even though
they may not commit to the general SVN repository. rebron just got his
SVN account working in the last week[3], so he shouldn't be removed. The
CVS list doesn't seem to take into account that there are four separate
CVS repositories, as it includes a large number of localizers (/l10n)
[4] and web developers (/www)[5].
Once all these issues are resolved, we can try this again. :)
~reed
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=524153
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=478100
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=521816
[4] http://bonsai-l10n.mozilla.org
[5] http://bonsai-www.mozilla.org
Gervase Markham
> Now that I've actually seen the list of accounts to be deactivated[1],
> I can say that both the policy and the tools used in gathering the
> list of dormant accounts need work.
Thank you for your helpful comments.
> With regards to the policy, the 6 month period of dormancy should
> take into account all SCMs, not each individual SCM. It does not make
> sense to disable somebody's CVS account just because he/she has been
> using SVN or Hg exclusively over the last 6 months.
I think it does. There are many people who have CVS accounts who will
never use them again, because they don't work on branches that old. But
if they continue to be valuable contributors in Hg for the next five
years, does that mean we never disable their CVS account?
> The
> list created for Hg is just completely wrong, given that it lists people
> like Zack Weinberg who just received his Hg access within the last few
> months [2] and has been actively committing patches. Mark Hammond is on
> that list, too, and I know he's been working on the raindrop project for
> Mozilla Labs. There are others, too, but those are just some examples.
> It would be useful to know how Gerv is creating the list for Hg.
It would probably make most sense to post my code; should I just attach
it to a newsgroup message?
Briefly: find a list of directories from http://hg.mozilla.org; scrape
that page and all the one-level subdir pages for repository names;
download and parse the pushlog for each repository.
> The
> list for SVN also surprises me, as it lists members of IT, who I know
> use a private SVN repository for things, and such set up with various
> POSIX requirements holds that they have svn_mozilla set even though
> they may not commit to the general SVN repository.
I originally wanted to use LDAP logs. My advice directly from IT was to
use the public SVN logs. Therefore it's a bit rich to now come back and
complain that my method doesn't take into account the private SVN
repositories! :-) How would you suggest fixing this problem?
> rebron just got his
> SVN account working in the last week[3], so he shouldn't be removed.
Hmm, yes; there's a problem here, in that people who have never checked
in because they got their accounts yesterday will show up as dormant.
Perhaps the right solution is to run the script twice, two weeks apart,
and only list those accounts which are flagged as dormant by both runs.
> The
> CVS list doesn't seem to take into account that there are four separate
> CVS repositories, as it includes a large number of localizers (/l10n)
> [4] and web developers (/www)[5].
So Bonsai's "All files in the repository" search is a little
misleadingly-named, then... I will look into updating it to include
those repositories.
Gerv
Mike Shaver
> It does not make
> sense to disable somebody's CVS account just because he/she has been
> using SVN or Hg exclusively over the last 6 months.
I think it does, actually. This dormant switch is _exactly_ about
unused accounts, not "people who don't contribute any more". If
someone switches to just reviewing patches and wrangling spreadsheets
and getting hatemail about blocklist entries (ahem) then their unused
VCS accounts should be disabled. I don't need my SVN account, even if
I have an hg one that I use periodically.
The core issue here is that VCS accounts are non-zero exposure, and if
they're not being used there's no corresponding benefit. We should
disable at whatever granularity is efficient, and re-enable with
tremendous alacrity.
Disabling isn't a punishment. It shouldn't be an ordeal. If it's
used as the former, or turns into the latter, we should just fix that
problem.
(Another idea would be to also mail the account holder when an account
is used to push. Could even mail the voucher for the first 30 days of
someone's account-having!)
Mike
mco...@mozilla.com
> On Fri, Oct 23, 2009 at 2:31 PM, Reed Loden <re...@reedloden.com>
> wrote:
>> It does not make
>> sense to disable somebody's CVS account just because he/she has been
>> using SVN or Hg exclusively over the last 6 months.
>
> I think it does, actually. This dormant switch is _exactly_ about
> unused accounts, not "people who don't contribute any more". If
> someone switches to just reviewing patches and wrangling spreadsheets
> and getting hatemail about blocklist entries (ahem) then their unused
> VCS accounts should be disabled. I don't need my SVN account, even if
> I have an hg one that I use periodically.
I agree 100% here. I haven't committed to CVS in a very long time,
nor do I expect to do so. That account should be disabled now, IMO.
- Mike
Phil Ringnalda
> Briefly: find a list of directories from http://hg.mozilla.org; scrape
> that page and all the one-level subdir pages for repository names;
> download and parse the pushlog for each repository.
It's not clear to me from either the previous thread's discussion of
davida or the bug - is this intended to be "disable people's
mozilla-central (and maybe comm-central) bits" or "disable their hg
accounts completely"? The attachment listing the unused hg accounts
appears to include people with very active hg accounts, that are only
active in hg.mozilla.org/users/*.
Gervase Markham
> It's not clear to me from either the previous thread's discussion of
> davida or the bug - is this intended to be "disable people's
> mozilla-central (and maybe comm-central) bits" or "disable their hg
> accounts completely"?
The latter.
> The attachment listing the unused hg accounts
> appears to include people with very active hg accounts, that are only
> active in hg.mozilla.org/users/*.
Yes; that's a bug in the script. Or rather, http://hg.mozilla.org/users/
has a different HTML format to the other parallel pages, and I didn't
notice, and therefore the script did not pick up the repos there. I've
fixed the script in the current round of fixes, so the newer script will
not have this problem.
There is no intention to disable Hg accounts people are using in any way.
Gerv
Mike Shaver
> There is no intention to disable Hg accounts people are using in any way.
Do (will) we have 6-month historical data for push-to-try? For some
users I can see that being the most valuable aspect of push access
(which I think also argues that we should make it much easier for
people to get, since the web-based LDAP analogue is trivial; another
thread, another day).
Mike
Gervase Markham
> Do (will) we have 6-month historical data for push-to-try? For some
> users I can see that being the most valuable aspect of push access
> (which I think also argues that we should make it much easier for
> people to get, since the web-based LDAP analogue is trivial; another
> thread, another day).
As far as I can tell, we do, yes. The try trees have a pushlog just like
any other tree. Unless http://hg.mozilla.org/try/pushlog doesn't
actually produce the data you are thinking of.
And yes, we should make getting try access easier. That's part of the
project to harmonize commit access policies, which I just finished
revising a draft of. Expect more in this area in the next few weeks.
Gerv
Mike Shaver
> As far as I can tell, we do, yes. The try trees have a pushlog just like
> any other tree. Unless http://hg.mozilla.org/try/pushlog doesn't
> actually produce the data you are thinking of.
Well, we periodically purge that repo to constrain the growth of it,
so I wanted to make sure that we didn't make accounts look dormant if
we had such a purge in the window under inspection.
Mike
Gervase Markham
> Well, we periodically purge that repo to constrain the growth of it,
> so I wanted to make sure that we didn't make accounts look dormant if
> we had such a purge in the window under inspection.
Ah.
How often is "periodically"?
We could regularly download the pushlog to avoid losing the info. Or we
could time purges to happen just after we do an run of account disabling.
Gerv
Mike Shaver
> How often is "periodically"?
You know, now and then. (When we notice it hurting.)
> We could regularly download the pushlog to avoid losing the info. Or we
> could time purges to happen just after we do an run of account disabling.
Actually, we may not purge the pushlog db at all, since it's not part
of the hg repo metadata that hurts us as it grows. ted or catlee
would know, I'm sure...
Mike
Phil Ringnalda
> On 28/10/09 12:23, Mike Shaver wrote:
>> Well, we periodically purge that repo to constrain the growth of it,
>> so I wanted to make sure that we didn't make accounts look dormant if
>> we had such a purge in the window under inspection.
>
> Ah.
>
> How often is "periodically"?
First time in June, and again in July, that I could find bugs for, and
apparently August that I couldn't, since the pushlog starts then, in
http://hg.mozilla.org/try/pushloghtml/90
> We could regularly download the pushlog to avoid losing the info. Or we
> could time purges to happen just after we do an run of account disabling.
Given the way they've happened so far, I don't think I'd count on being
able to control the timing. Either a cron job that crawls the logs, or
an hg hook that feeds a script, seems less likely to miss things
(particularly if it's possible to remove user repos, where you're even
less likely to be able to insist that it only happen when you're done
with them).
Axel Hecht
We can rip out the userlist when pruning the pushlog db, including a
"last known push date".
Axel
Gervase Markham
> list created for Hg is just completely wrong, given that it lists people
> like Zack Weinberg who just received his Hg access within the last few
> months [2] and has been actively committing patches. Mark Hammond is on
> that list, too, and I know he's been working on the raindrop project for
> Mozilla Labs. There are others, too, but those are just some examples.
Now I have correctly included the user/ repositories, both these people
are now flagged as active. Can you give me any more examples? :-)
> list for SVN also surprises me, as it lists members of IT, who I know
> use a private SVN repository for things, and such set up with various
> POSIX requirements holds that they have svn_mozilla set even though
> they may not commit to the general SVN repository.
How would IT like to deal with this? Is there a viewvc instance for
their SVN repository against which they could run the scraping script?
Or do they want to vet the list by hand every time?
> CVS list doesn't seem to take into account that there are four separate
> CVS repositories, as it includes a large number of localizers (/l10n)
> [4] and web developers (/www)[5].
You say there are four, but you name only an additional two (making
three). Where is the fourth one, and does it have a bonsai?
Gerv
Benjamin Smedberg
> How would IT like to deal with this? Is there a viewvc instance for
> their SVN repository against which they could run the scraping script?
> Or do they want to vet the list by hand every time?
I would think that the LDAP server itself keeps a log of login attempts and
what app they originated from: I know that it does for at least a while,
since incorrect logins with my username get reported to me via email. How
hard would it be to go directly to the LDAP server, instead of scraping
around in obviously incomplete sets of data in various VCS systems?
--BDS
Reed Loden
Gervase Markham <ge...@mozilla.org> wrote:
> Now I have correctly included the user/ repositories, both these people
> are now flagged as active. Can you give me any more examples? :-)
Not right now. Once I see your updated lists, I may be able to find
somebody else that would be another example.
> How would IT like to deal with this? Is there a viewvc instance for
> their SVN repository against which they could run the scraping script?
> Or do they want to vet the list by hand every time?
You'll need to talk to IT. I don't think there's a ViewVC instance
anywhere that you could use, though. When you request updated lists of
people from IT, you could just request the membership of
"svn_sysadmins" and then exclude those people...
> You say there are four, but you name only an additional two (making
> three). Where is the fourth one, and does it have a bonsai?
The private CVS repository where horrid things like Talkback are kept,
and no, there isn't a Bonsai for it.
~reed
Gervase Markham
> I would think that the LDAP server itself keeps a log of login attempts and
> what app they originated from: I know that it does for at least a while,
> since incorrect logins with my username get reported to me via email. How
> hard would it be to go directly to the LDAP server, instead of scraping
> around in obviously incomplete sets of data in various VCS systems?
That was my initial plan. I discussed it with reed and I was informed
that the LDAP server does not keep a record of when an account was "last
used". There was also an issue with giving me the logs to parse; I don't
remember what now. That was an in-person conversation so I don't have a
record of it. The feedback from IT was that I should use the public
sources of information.
Gerv
Gervase Markham
> It would probably make most sense to post my code; should I just attach
> it to a newsgroup message?
You can find my code, along with the data from my most recent CVS and
SVN crawls, here:
http://hg.mozilla.org/users/gerv_mozilla.org/active-accounts/
The Hg data was 386Mb for only 6 months, so I decided not to check it
in. We can revisit that if the new Hg list still seems to be badly wrong.
The dormant-*.csv files are the accounts that I still think are dormant
over the past 180 and 365 days. If an account appears there which
belongs to someone you think is still active, please consider:
1) Are they active in a different SCM now?
2) Do they have another account they are using instead? (Check all.csv)
3) Have they actually ever used this account at all (search bonsai or
viewvc for their name)?
IT owes me an updated version of all.csv. And of course this does not
include the private CVS and SVN repos. Other than that, I _think_ I've
taken into account all the feedback.
Gerv
Gervase Markham
level to make sure everyone who would want a chance to comment has seen it.]
You can find my code for determining the active accounts, along with
Pascal Chevrel
Hi,
I scanned the svn dormant file for people I work with and I found 2 very
active svn ones listed as dormant:
f...@striptm.com, tim.b...@gmail.com
also, the ex-interns/localizers accounts I had had deactivated last
summer that I told you about in bugzilla are still listed as dormant.
There are people there that I think *just* got an account like rebron,
so if you count people that were not active in the last 180 days, you
should remove from that list people whose account creation is less than
180 days.
Will somebody active on hg but currently not active on svn (localizers)
still keep their account? We have product working on Thunderbird 3 and
their last commit to svn for web pages was for the Thunderbird 2 release
so for these people to not commit on svn since TB2 it's normal since
there was nothing to update, but we are now preparing the new
mozillamessaging localized pages for Thunderbird 3. Also, it seems to me
that if we trust people to regularly commit in our mozilla source code,
that trust should extend to the maintenance of web pages on svn which
are much less critical.
regards,
Pascal
Gervase Markham
> I scanned the svn dormant file for people I work with and I found 2 very
> active svn ones listed as dormant:
> f...@striptm.com, tim.b...@gmail.com
Thank you. That was a sorting bug in the script which meant they moved
position in the list, and so had both a "+" line and a "-" line, and the
grep obviously extracted just the "-" line. I have updated the script to
sort both files using the same algorithm before diffing them.
Have another look now.
> also, the ex-interns/localizers accounts I had had deactivated last
> summer that I told you about in bugzilla are still listed as dormant.
Yes; as my message said, I'm still owed an updated list of all accounts
from IT which uses better queries to not include deactivated accounts.
At the moment, they show up as dormant because they are still in the
full list and yet (obviously) have not checked in recently.
> There are people there that I think *just* got an account like rebron,
> so if you count people that were not active in the last 180 days, you
> should remove from that list people whose account creation is less than
> 180 days.
Hmm. That's an interesting approach. I will ask dmoore whether he can
modify his queries to either include a creation date or to exclude the
recently-created.
> Will somebody active on hg but currently not active on svn (localizers)
> still keep their account?
In the normal course of things, they would keep their Hg account but not
their SVN account.
> We have product working on Thunderbird 3 and
> their last commit to svn for web pages was for the Thunderbird 2 release
> so for these people to not commit on svn since TB2 it's normal since
> there was nothing to update, but we are now preparing the new
> mozillamessaging localized pages for Thunderbird 3. Also, it seems to me
> that if we trust people to regularly commit in our mozilla source code,
> that trust should extend to the maintenance of web pages on svn which
> are much less critical.
It's not about trust, it's about not having unused accounts lying
around, which increase attack surface.
Definitely, if there are a large group of people who are about to start
committing to SVN again after a long gap, it makes sense not to
deactivate their accounts just before they do! Are there people working
on the TB3 website l10n who have not yet made a checkin?
Gerv
Pascal Chevrel
> Definitely, if there are a large group of people who are about to start
> committing to SVN again after a long gap, it makes sense not to
> deactivate their accounts just before they do! Are there people working
> on the TB3 website l10n who have not yet made a checkin?
Yes, we have recently started the localization of the website and we
have for example half of the locales done for in-product pages, meaning
that another half has not committed yet. I have planned an outreach to
these locales for this week end.
Pascal
Robert Kaiser
> [This seemed to pass without comment, so I'm reposting it at the top
> level to make sure everyone who would want a chance to comment has seen it.]
>
> You can find my code for determining the active accounts, along with
> the data from my most recent CVS and SVN crawls, here:
> http://hg.mozilla.org/users/gerv_mozilla.org/active-accounts/
>
> The Hg data was 386Mb for only 6 months, so I decided not to check it
> in. We can revisit that if the new Hg list still seems to be badly wrong.
Uh, did you include the (releases/)l10n-*/* repos in that hg analysis?
It looks to me like there would be a few accounts of quite active
localizers in the dormant list for hg accounts.
Robert Kaiser
Robert Kaiser
> Gervase Markham wrote:
>> The Hg data was 386Mb for only 6 months, so I decided not to check it
>> in. We can revisit that if the new Hg list still seems to be badly wrong.
>
> Uh, did you include the (releases/)l10n-*/* repos in that hg analysis?
> It looks to me like there would be a few accounts of quite active
> localizers in the dormant list for hg accounts.
And what about other hg repos, even ones that are possibly in the
toplevel? I see sil...@warwickcompsoc.co.uk in the list, who just
initialized http://hg.mozilla.org/chatzilla/pushloghtml recently...
Robert Kaiser
Gervase Markham
> Yes, we have recently started the localization of the website and we
> have for example half of the locales done for in-product pages, meaning
> that another half has not committed yet. I have planned an outreach to
> these locales for this week end.
OK. If, as seems likely, we decide to implement this policy by running
the scripts twice a month apart and disabling only those names which are
dormant in both runs, then all of these people will surely have checked
in by then. So I'm not worried.
Gerv
Gervase Markham
> Uh, did you include the (releases/)l10n-*/* repos in that hg analysis?
I included:
/l10n/* (4 l10n infrastructure projects)
/l10n-central/* (one tree per locale)
/releases/* (3 trees, none of which are l10n-related)
If there exists something like a /releases/l10n-1.9.1/*, I can't find it
using hgweb. :-| Can you expand your *s for me into specific tree names? :-)
Can you give examples of active localizers in the hg-dormant list?
Gerv
Gervase Markham
> And what about other hg repos, even ones that are possibly in the
> toplevel?
Please, please be more specific :-)
> I see sil...@warwickcompsoc.co.uk in the list, who just
> initialized http://hg.mozilla.org/chatzilla/pushloghtml recently...
Yes. The Hg run was done on October 30th, before anyone had checked into
the chatzilla repo.
We will definitely be making sure very new committers don't get marked
as dormant.
Gerv
Reed Loden
Gervase Markham <ge...@mozilla.org> wrote:
> If there exists something like a /releases/l10n-1.9.1/*, I can't find it
> using hgweb. :-| Can you expand your *s for me into specific tree names? :-)
http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/
http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/
Hidden in the list of directories at the bottom, you'll find the
following lovely text:
"releases Release branches (use releases/l10n-branchname for
l10n repos)."
Robert Kaiser
> On 05/11/09 13:49, Robert Kaiser wrote:
>> And what about other hg repos, even ones that are possibly in the
>> toplevel?
>
> Please, please be more specific :-)
ChatZilla was the example that caught my eye, as I found Silver in the
dormant list.
Robert Kaiser
Robert Kaiser
> On 05/11/09 13:46, Robert Kaiser wrote:
>> Uh, did you include the (releases/)l10n-*/* repos in that hg analysis?
>
> I included:
>
> /l10n/* (4 l10n infrastructure projects)
> /l10n-central/* (one tree per locale)
> /releases/* (3 trees, none of which are l10n-related)
>
> If there exists something like a /releases/l10n-1.9.1/*, I can't find it
> using hgweb. :-| Can you expand your *s for me into specific tree names? :-)
You actually need to add /releases/l10n-*/* then. Most localizers don't
actively work on l10n-central/* but only on the
releases/l10n-mozilla-1.9.{1,2}/* repos, which are used in actual releases.
> Can you give examples of active localizers in the hg-dormant list?
a.t...@uni-duisburg.de,Hg
gia...@telenet.ge,Hg
are two where I know the people behind them are pretty active in L10n
(German and Georgian toolkit/Firefox locale owners). There are probably
more, but those two caught my eye immediately and led me to the
conclusion that you missed some L10n stuff, e.g. the releases/ ones
where most people do almost all their L10n work.
Robert Kaiser
Gervase Markham
> You actually need to add /releases/l10n-*/* then. Most localizers don't
> actively work on l10n-central/* but only on the
> releases/l10n-mozilla-1.9.{1,2}/* repos, which are used in actual releases.
Thank you for this useful info. I've now included these trees and
generated an updated list, which is about 40 names smaller than the
previous one.
>> Can you give examples of active localizers in the hg-dormant list?
>
> a.t...@uni-duisburg.de,Hg
He appears now to be using a.t...@gmail.com, so this account is still
marked as dormant.
> gia...@telenet.ge,Hg
The new version no longer has this account listed as dormant.
Gerv
Robert Kaiser
> On 06/11/09 12:27, Robert Kaiser wrote:
>> You actually need to add /releases/l10n-*/* then. Most localizers don't
>> actively work on l10n-central/* but only on the
>> releases/l10n-mozilla-1.9.{1,2}/* repos, which are used in actual releases.
>
> Thank you for this useful info. I've now included these trees and
> generated an updated list, which is about 40 names smaller than the
> previous one.
That sounds good!
>>> Can you give examples of active localizers in the hg-dormant list?
>>
>> a.t...@uni-duisburg.de,Hg
>
> He appears now to be using a.t...@gmail.com, so this account is still
> marked as dormant.
OK, fine, didn't know he had two actual accounts.
Robert Kaiser
Mitchell Baker
seems like that's a success case right there!
ml
Robert Kaiser
Indeed, and that's quite good!
Robert Kaiser
Justin Wood (Callek)
> On Tue, Oct 20, 2009 at 12:20 PM, Mike Connor<mco...@mozilla.com> wrote:
>>
>> On 20-Oct-09, at 10:05 AM, Pascal Chevrel wrote:
>>
>>> For any disabling of localizers account on SVN, I want to be CCed on a bug
>>> disabling their account. Some localizers work on web parts once or twice a
>>> year for the major release and some have good reasons to be absent for a
>>> year, for example our Turkish web localizer is now doing his military
>>> service and won't commit in the 8 months to come, I wouldn't want his
>>> account to be deactivated because of that.
>>
>> Conversely, I _want_ his account to be deactivated because of that. As long
>> as server ops are quick about re-enabling access when he's back, that's a
>> clear case where disabling the account on a temporary basis would make
>> perfect sense.
>
> Yes, I agree completely. Deactivating someone's account because
> they're dormant isn't a punishment, and someone who knows they're
> going to be inactive for a while should ideally be *telling* us that
> so that we can deactivate until they come back. The account is of no
> use to them during that period, but still represents attack surface:
> it's just about the purest case I can imagine in support of such
> deactivation.
Yes, this is in response to a (very old) thread, but I am just getting
back from an extended hiatus from online [at home].
I was inactive for a long time [since before FF 3.5 release anyway], not
knowing when I would be back. I was in possession of my computer, and
thus my ssh key the whole time, so no security hole from my end there.
Given you "should be telling you", would my situation also warrant the
"please tell us..." clause there. Or if there is _no_ potential for
someone else to aquire my ssh key _and_ I plan to return should I
refrain from saying anything about "I should be deactivated" [as did
happen in my case]?
-
~Justin Wood (Callek)
Mike Connor
On 9-Jan-10, at 2:43 AM, Justin Wood (Callek) wrote:
> Yes, this is in response to a (very old) thread, but I am just
> getting back from an extended hiatus from online [at home].
>
> I was inactive for a long time [since before FF 3.5 release anyway],
> not knowing when I would be back. I was in possession of my
> computer, and thus my ssh key the whole time, so no security hole
> from my end there.
Your first assumption is that your machine could not be compromised.
If your account was compromised, you wouldn't have known.
> Given you "should be telling you", would my situation also warrant
> the "please tell us..." clause there. Or if there is _no_ potential
> for someone else to aquire my ssh key _and_ I plan to return should
> I refrain from saying anything about "I should be deactivated" [as
> did happen in my case]?
Deactivation shouldn't be a major hurdle to overcome, so I'm not sure
why you wouldn't simply have the account deactivated for that 7-8
month hiatus and come back to it.
-- Mike
Mike Shaver
> I was inactive for a long time [since before FF 3.5 release anyway], not
> knowing when I would be back. I was in possession of my computer, and thus
> my ssh key the whole time, so no security hole from my end there.
Your account can be used without your key, such as for try-server or
other LDAP-based auth, and likely for more things in the future.
While it's *unlikely* that your account would be compromised, it
sounds like it was *certain* that you weren't using it, and would be
restarting in the future, so my risk calculus would indicate that you
should ask to be deactivated. It doesn't hurt you, and makes everyone
a little safer.
Mike
Justin Wood (Callek)
Fair enough, when and if I go away again I will be certain to ask for
its dormancy happening before it is auto-detected.
Thank you both for the clarity.
-
Justin Wood (Callek)
Mike Shaver
> Fair enough, when and if I go away again I will be certain to ask for its
> dormancy happening before it is auto-detected.
That would be very thoughtful of you. Thanks a bunch!
Mike