Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers :
> In practice there are a lot of ways people have messed up ChangeLog 
> commits or commit messages that I would expect to confuse such author 
> extraction, even before you get to the parts of the history converted from 
> CVS.

This is also true.

I looked seriously at what it would take to recover this information
from the Emacs history, which is why I had the steps worked out in
such detail.  Having researched the matter, I did *not* offer to
actually add this wrinkle when I did their conversion...
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Joseph Myers]

On Mon, 10 Oct 2016, Eric S. Raymond wrote:

> I strongly recomend that if you want to try this, you separate it from the
> initial repo conversion.  That is, get the project to git first.  Then
> see if you can data-mine author information out of the history. If,
> and only if, you get results that look reasonable, then you patch the repo
> and force-push it, warning everyone there'll be a flag day.
> 
> The reason I recommend this is that I think you're going to have serious
> trouble getting clean authorship data with good coverage.  The data
> mining will be messy and take longer than you expect.

I also think it would be too messy, and don't think having such a flag day 
would be a good idea - once we've done the conversion we should keep 
commit ids stable (while having the commit objects from the existing git 
mirror in a disjoint set of branches not connected to the cleanly 
converted history, whether in a separate repository or not, so existing 
references to those commit ids continue to work as well - but I don't want 
to add a third set of commit ids for the same history as well).

In practice there are a lot of ways people have messed up ChangeLog 
commits or commit messages that I would expect to confuse such author 
extraction, even before you get to the parts of the history converted from 
CVS.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers :
> This is still hypothetical, since I haven't seen any scripts posted that 
> would actual implement this, or any resulting mappings of commits, and one 
> wouldn't normally expect a repository conversion to attempt to distinguish 
> committer from author when the source version control system has no such 
> distinction.

Wow.  Even attempting this would be a huge, ugly job.

I strongly recomend that if you want to try this, you separate it from the
initial repo conversion.  That is, get the project to git first.  Then
see if you can data-mine author information out of the history. If,
and only if, you get results that look reasonable, then you patch the repo
and force-push it, warning everyone there'll be a flag day.

The reason I recommend this is that I think you're going to have serious
trouble getting clean authorship data with good coverage.  The data
mining will be messy and take longer than you expect.

Here's how I'd do it:

1. Write an analyzer for commit logs.  Its goal should be to parse
   logs and produce a list of records each consiting of an author, a
   commit date, and a list of modified-file paths - one record
   per commit-log entry.

2. Run this once on each terminal commit log - that is, at each branch
   head on both the main Commit log and all its archival versions.
   Aggregate all the records, dropping duplicates.

3. Write a custom Python extension to reposurgeon that generates the
   same report, only this time per-commit and thus yielding a committer ID.

3. Set a recognition time window.  It must be more than 24 hours or you're
   going to have spurious negatives due to time-zone skew.

4. Write a program that fuzzy-matches the commit-log file-modification
   cliques to the per-commit cliques.  One aspect of "fuzzy" is the
   time window; you need to include as potential matches any commits back
   from the date of the commit-log entry *and those up to 24 hours forward*
   (time-zone skew again).  Also, you can't only look at the most recent
   matching commit if it's within the 24-hour window - time zone skew might
   mean that another one that looks older also matches, and might actually
   be more recent.

5. Try the naive implementation using a 24-hour time window.  Now look
   at the percentages of unmatched commits and commit-log entries.  If
   it's too high, how does it vary as the time window rises?

Alas, there are other dimensions of 'fuzzy'. Here are a couple:

1. Typos or omissions in the commit-log file cliques and/or author
   names.  To get good coverage you might find you need to do
   something like a Ratcliff-Obershelp fuzzy match.  Set a high
   similarity percentage, then back off it if you have lots of
   unmatched commits.

2. What if someone did two or more commits on different filesets, but
   described them in one commit-log entry?  Ideally you'd like to propagate
   the commit-log author info correctly to both, but testing for this case
   mechanically would be combinatorially explosive.  Your only hope is that
   you end up with few enough unmatched commits and commit-log entries
   that the problem can be solved manually.

Maybe you'll get lucky and the residuals (the sets of commits and commit-log
entries that don't have a match in the other set) will be tiny.  I wouldn't
count on it - I'd expect that you will trip over other noise sources and
have to figure out ways to fuzzy-match around them.

Once you have the residuals down to an acceptably low number, make your
matcher grind out a set of reposurgeon commands that patches the attributions
appropriately.  Apply.  By careful to add a predicate check that prevents
each transformation from applying if the date matches more than one commit;
those two will have to be treated as residuals and hand-patched.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Joseph Myers]

On Mon, 10 Oct 2016, Jonathan Wakely wrote:

> > My view is: contributors are free to specify what name and email address
> > they want used, but if they want something other than a single name and
> > email address for the whole commit history with a given username, it's the
> > contributor's responsibility to come up with lists of commits that use
> > each mapping rather than a hypothetical recipe based on examining
> > ChangeLogs.
> 
> We'd only need to look at the actual ChangeLogs if the commit message
> doesn't include a name and email address. And if we just use the
> committer, how do we record the author of a change?

This is still hypothetical, since I haven't seen any scripts posted that 
would actual implement this, or any resulting mappings of commits, and one 
wouldn't normally expect a repository conversion to attempt to distinguish 
committer from author when the source version control system has no such 
distinction.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Jason Merrill]

On Mon, Oct 10, 2016 at 6:38 AM, Jonathan Wakely  wrote:
> On 7 October 2016 at 22:26, Joseph Myers wrote:
>> On Fri, 7 Oct 2016, Frank Ch. Eigler wrote:
>>> FWIW, I thought at one point the consensus was that the mailmap would
>>> expand only to $use...@gcc.gnu.org rather than $userid@$organization,
>>> esp. considering the case where there is no single $organization that
>>> accurately covers the whole contribution timespan of the given $userid.
>>
>> I don't think there was any such consensus (older ids weren't from
>> gcc.gnu.org anyway so @gcc.gnu.org would be nonsense for that part of the
>> history).
>>
>> My view is: contributors are free to specify what name and email address
>> they want used, but if they want something other than a single name and
>> email address for the whole commit history with a given username, it's the
>> contributor's responsibility to come up with lists of commits that use
>> each mapping rather than a hypothetical recipe based on examining
>> ChangeLogs.
>
> We'd only need to look at the actual ChangeLogs if the commit message
> doesn't include a name and email address. And if we just use the
> committer, how do we record the author of a change?
>
> As Richi said a year ago (and my reply was drafted a year ago but not sent) 
> ...
>
> On 17 September 2015 at 11:44, Richard Biener wrote:
>> Maybe I'm missing sth but apart from the CVS imported revisions each
>> SVN revision should contain the actual change plus the changes to the
>> ChangeLog files (you can't count on the commit message itself I guess
>> as not all people replicate the ChangeLog entries there).
>
> It's probably a good start though. If the commit message does have:
>
> -MM-DD  John Doe  
>
> then it's probably reliable. If the commit message doesn't have that
> (when I'm committing my own work I don't include that line in the
> commit message) then look for ChangeLog entries in the commit.
>
>> There may be cases we can't handle and then doing some commit ID
>> mapping might be ok, but I expect 95% of the cases to work out nicely
>> so we should preserve what is in the ChangeLog entry (note that we have
>> very strict formatting requirement for the authors there).
>
> Particularly since the ChangeLog entry gives the Author, which is
> often not the same as the Committer.

Yes, very often they will be different.  This processing can, and
probably should, be done with git filter-branch after the initial
conversion.

Jason

Re: Repository for the conversion machinery

[Jonathan Wakely]

On 7 October 2016 at 22:26, Joseph Myers wrote:
> On Fri, 7 Oct 2016, Frank Ch. Eigler wrote:
>> FWIW, I thought at one point the consensus was that the mailmap would
>> expand only to $use...@gcc.gnu.org rather than $userid@$organization,
>> esp. considering the case where there is no single $organization that
>> accurately covers the whole contribution timespan of the given $userid.
>
> I don't think there was any such consensus (older ids weren't from
> gcc.gnu.org anyway so @gcc.gnu.org would be nonsense for that part of the
> history).
>
> My view is: contributors are free to specify what name and email address
> they want used, but if they want something other than a single name and
> email address for the whole commit history with a given username, it's the
> contributor's responsibility to come up with lists of commits that use
> each mapping rather than a hypothetical recipe based on examining
> ChangeLogs.

We'd only need to look at the actual ChangeLogs if the commit message
doesn't include a name and email address. And if we just use the
committer, how do we record the author of a change?

As Richi said a year ago (and my reply was drafted a year ago but not sent) ...

On 17 September 2015 at 11:44, Richard Biener wrote:
> Maybe I'm missing sth but apart from the CVS imported revisions each
> SVN revision should contain the actual change plus the changes to the
> ChangeLog files (you can't count on the commit message itself I guess
> as not all people replicate the ChangeLog entries there).

It's probably a good start though. If the commit message does have:

-MM-DD  John Doe  

then it's probably reliable. If the commit message doesn't have that
(when I'm committing my own work I don't include that line in the
commit message) then look for ChangeLog entries in the commit.

> There may be cases we can't handle and then doing some commit ID
> mapping might be ok, but I expect 95% of the cases to work out nicely
> so we should preserve what is in the ChangeLog entry (note that we have
> very strict formatting requirement for the authors there).

Particularly since the ChangeLog entry gives the Author, which is
often not the same as the Committer.




>
> [reposurgeon aside from observations with other conversions where
> different author maps were needed for different revisions: the revision
> range for commits from the gcc2 repository works in the GCC case because
> that revision range came from CVS and so there are no tags with valid
> commit authors in that range.  But if you have a repository with different
> ranges of commits having different author maps *and* those ranges contain
> SVN tags, simply specifying a range .. doesn't
> work as expected, since ranges are interpreted in reposurgeon's ordering
> of events, not SVN's ordering, and the tag events are out of sequence with
> the commit events.]
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: Repository for the conversion machinery

[Joseph Myers]

On Fri, 7 Oct 2016, Frank Ch. Eigler wrote:

> joseph wrote:
> 
> > Thanks, here are further authors map additions for new committers.
> > [...]
> > avieira = Andre Vieira 
> > [...]
> 
> FWIW, I thought at one point the consensus was that the mailmap would
> expand only to $use...@gcc.gnu.org rather than $userid@$organization,
> esp. considering the case where there is no single $organization that
> accurately covers the whole contribution timespan of the given $userid.

I don't think there was any such consensus (older ids weren't from 
gcc.gnu.org anyway so @gcc.gnu.org would be nonsense for that part of the 
history).

My view is: contributors are free to specify what name and email address 
they want used, but if they want something other than a single name and 
email address for the whole commit history with a given username, it's the 
contributor's responsibility to come up with lists of commits that use 
each mapping rather than a hypothetical recipe based on examining 
ChangeLogs.


[reposurgeon aside from observations with other conversions where 
different author maps were needed for different revisions: the revision 
range for commits from the gcc2 repository works in the GCC case because 
that revision range came from CVS and so there are no tags with valid 
commit authors in that range.  But if you have a repository with different 
ranges of commits having different author maps *and* those ranges contain 
SVN tags, simply specifying a range .. doesn't 
work as expected, since ranges are interpreted in reposurgeon's ordering 
of events, not SVN's ordering, and the tag events are out of sequence with 
the commit events.]

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

joseph wrote:

> Thanks, here are further authors map additions for new committers.
> [...]
> avieira = Andre Vieira 
> [...]

FWIW, I thought at one point the consensus was that the mailmap would
expand only to $use...@gcc.gnu.org rather than $userid@$organization,
esp. considering the case where there is no single $organization that
accurately covers the whole contribution timespan of the given $userid.

- FChE

Re: Repository for the conversion machinery

[Joseph Myers]

On Fri, 7 Oct 2016, Jason Merrill wrote:

> But if you want to do it with reposurgeon, I won't complain.  I've
> pushed my WIP to https://github.com/jicama/gcc-reposurgeon

Thanks, here are further authors map additions for new committers.

avieira = Andre Vieira 
foreese = Fritz Reese 
jemarch = Jose E. Marchesi 
jyong = Jonathan Yong <10wa...@gmail.com>
ksejdak = Jakub Sejdak 
saaadhu = Senthil Kumar Selvaraj 
seurer = Bill Seurer 
tnfchris = Tamar Christina 

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Joseph Myers]

On Fri, 7 Oct 2016, Jason Merrill wrote:

> no additional commits, and keeps other branches that were deleted in
> SVN, though I was able to work around this with a postprocessing
> script.

I suppose there's the question of what we want cases where branches might 
have been deleted to look like, both for past history and for future 
development.  Branch deletion in git is not directly equivalent to branch 
deletion in SVN because of the potential for leaving objects unreachable.  
So either you rename the branches (e.g. into dead/) or you keep tags 
pointing to their tips so the history stays reachable.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Eric S. Raymond]

Jason Merrill :
> > I've used both git-svn (sometimes with git filter-branch) and reposurgeon
> > for repository conversions.  My experience is that if there's anything at
> > all complicated or messy about the history, using git-svn for the
> > conversion is not a good idea, so I don't think that's an attractive
> > option at all.
> 
> But we're already using git-svn, and it's fine.

My hair stands on end when I hear anyone say that.  git-svn is tolerable,
if a bit flaky, for live gatewaying. It is *dangerous* for whole-history
conversions.  I wrote a public-service announcement about this a while back.

Don’t do svn-to-git repository conversions with git-svn!
  http://esr.ibiblio.org/?p=6778

It should be more widely known that git-svn is bad in this mode; it's
not because on small, linear or near-linear repos without operator
errors or CVS-conversion scar tissues it happens to work reasonably
well. GCC is not in this category.

> Specifically, reposurgeon doesn't like subdirectory branches much more
> than git-svn does, though I was able to work around that with
> branchify (and some fixes in reposurgeon).  It discards branches with
> no additional commits, and keeps other branches that were deleted in
> SVN, though I was able to work around this with a postprocessing
> script.
> 
> Most significantly, it fails to handle some commits (I noticed r137307
> and r131989), leading to incorrect file content at the top of the
> affected branches.  This is the issue that I didn't hear back from
> Eric about, which led me to consider other approaches.  Fortunately it
> marked them (as well as many others) with emptycommit tags for review.
> 
> But if you want to do it with reposurgeon, I won't complain.  I've
> pushed my WIP to https://github.com/jicama/gcc-reposurgeon

This is my fault. I think you hit that bug right around one of the times I
was being most distracted by NTPsec, and I somehow formed the mistaken
impression you had gotten past it.

I'll get back on this.  I still have your bug report in my back mail; the
first thing I need to do is fix that.  Can't promise immediate action, I'm
preparing for the 1.0 release of NTPsec (spent the last week mostly
clearing our issue list) but now that I know this is unfinished I won't
drop it until it is.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Jason Merrill]

On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers  wrote:
> On Thu, 6 Oct 2016, Jason Merrill wrote:
>
>> After I ran into a couple of reposurgeon bugs and didn't hear back
>> from you, I started investigating rewriting the existing git svn
>> mirror with git filter-branch instead.  That seems an attractive
>> option, but not long afterward I needed to shift focus to front end
>
> I've used both git-svn (sometimes with git filter-branch) and reposurgeon
> for repository conversions.  My experience is that if there's anything at
> all complicated or messy about the history, using git-svn for the
> conversion is not a good idea, so I don't think that's an attractive
> option at all.

But we're already using git-svn, and it's fine.  Introducing another
tool just adds opportunities to be affected by new and different bugs.

Specifically, reposurgeon doesn't like subdirectory branches much more
than git-svn does, though I was able to work around that with
branchify (and some fixes in reposurgeon).  It discards branches with
no additional commits, and keeps other branches that were deleted in
SVN, though I was able to work around this with a postprocessing
script.

Most significantly, it fails to handle some commits (I noticed r137307
and r131989), leading to incorrect file content at the top of the
affected branches.  This is the issue that I didn't hear back from
Eric about, which led me to consider other approaches.  Fortunately it
marked them (as well as many others) with emptycommit tags for review.

But if you want to do it with reposurgeon, I won't complain.  I've
pushed my WIP to https://github.com/jicama/gcc-reposurgeon

Jason

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

Jason Merrill  writes:

> [...]  gcc.gnu.org already refuses git connections fairly frequently
> due to overloading [...]

With the corresponding reduction in cpu load from svn users, plus the
ready adjustability of those xinetd thresholds, please don't let that
hold you back.

- FChE

Re: Repository for the conversion machinery

[Joseph Myers]

On Thu, 6 Oct 2016, Jason Merrill wrote:

> After I ran into a couple of reposurgeon bugs and didn't hear back
> from you, I started investigating rewriting the existing git svn
> mirror with git filter-branch instead.  That seems an attractive
> option, but not long afterward I needed to shift focus to front end

I've used both git-svn (sometimes with git filter-branch) and reposurgeon 
for repository conversions.  My experience is that if there's anything at 
all complicated or messy about the history, using git-svn for the 
conversion is not a good idea, so I don't think that's an attractive 
option at all.  (The non-rewritten git-svn history can be kept alongside 
the reposurgeon conversion using the git fetch command I gave in 
, so existing commit 
references remain meaningful.)

> We should also reopen discussion of workflow and branch policies.  One

There's very little there that should be done before the conversion.  We 
only need enough policy to set up hooks and repository configuration.  A 
starting point would be no non-fast-forward ref updates, either no ref 
deletions or ref deletions restricted to some defined namespace for user 
branches, commit mails to gcc-cvs continue as at present (showing the 
commit message and list of changed files, but not the full diffs), other 
hook actions such as Bugzilla updates continue as at present, all commit 
policies continue as at present.  I think people should be encouraged to 
write git-style commit messages with a meaningful summary line followed by 
something like the description in a mailing list posting of a patch, but I 
think that's a good idea independent of the conversion.

> concern I have about the git conversion is that gcc.gnu.org already
> refuses git connections fairly frequently due to overloading, and I'm
> afraid that will become much more common when current SVN users switch
> over.

That's for anonymous connections, not for git over ssh; I don't think it 
should block the conversion.  I think it's been a while since the hardware 
was refreshed, maybe it's time for work on new hardware (with or without 
an OS update to RHEL 7) to start?  (The more cores the hardware has, the 
higher the load threshold for refusing connections can be.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Jason Merrill]

On Thu, Oct 6, 2016 at 1:19 PM, Eric S. Raymond  wrote:
> Joseph Myers :
>> On Thu, 6 Oct 2016, Eric S. Raymond wrote:
>>
>> > I thought the gcc conversion was done.
>> >
>> > I can make the repository available again if it's needed.
>>
>> The conversion got stalled (I'm not sure why; maybe just Jason being busy
>> with other things) but is still intended (I'm not sure for when), so yes
>> the repository is still needed.
>
> I was unaware of this.  I thought Jason had gotten the bit in his teeth
> and finished it while I was off doing other things.

After I ran into a couple of reposurgeon bugs and didn't hear back
from you, I started investigating rewriting the existing git svn
mirror with git filter-branch instead.  That seems an attractive
option, but not long afterward I needed to shift focus to front end
development and decided to put off the conversion until the next stage
1.  And here we are coming toward the end of that stage 1 and I
haven't found time for it yet, and am not likely to before the end of
this stage 1.

> (I'm sorry for not paying closer attention, but leading the project to fix NTP
> has eaten almost all my bandwidth for most of the last two years.)
>
> What do we do to get this restarted?  I'll make the conversion-machinery
> repo visible again; what's the step after that?

As Joseph mentions, we should update the user map.

After that, I had a reposurgeon conversion of the website done apart
from the hooks, and could update that and put it in place as a good
prelude to converting the sources.

We should also reopen discussion of workflow and branch policies.  One
concern I have about the git conversion is that gcc.gnu.org already
refuses git connections fairly frequently due to overloading, and I'm
afraid that will become much more common when current SVN users switch
over.

Jason

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers :
> On Thu, 6 Oct 2016, Eric S. Raymond wrote:
> 
> > I thought the gcc conversion was done.
> > 
> > I can make the repository available again if it's needed.
> 
> The conversion got stalled (I'm not sure why; maybe just Jason being busy 
> with other things) but is still intended (I'm not sure for when), so yes 
> the repository is still needed.

I was unaware of this.  I thought Jason had gotten the bit in his teeth
and finished it while I was off doing other things.

(I'm sorry for not paying closer attention, but leading the project to fix NTP
has eaten almost all my bandwidth gor most of the last two years.)

What do we do to get this restarted?  I'll make the conversion-machinery
repo visible again; what's the step after that?
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Joseph Myers]

On Thu, 6 Oct 2016, Eric S. Raymond wrote:

> I thought the gcc conversion was done.
> 
> I can make the repository available again if it's needed.

The conversion got stalled (I'm not sure why; maybe just Jason being busy 
with other things) but is still intended (I'm not sure for when), so yes 
the repository is still needed.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers :
> On Thu, 27 Aug 2015, Eric S. Raymond wrote:
> 
> > I've made it available at:
> > 
> > http://thyrsus.com/gitweb/?p=gcc-conversion.git
> 
> What happened with this repository?  Is it somewhere else now?  Pulling in 
> my clone of git://thyrsus.com/repositories/gcc-conversion.git has produced 
> "thyrsus.com[0: 71.162.243.5]: errno=Connection refused" errors for 
> several months now.  (The most recent commit I have in my clone is
> 
> commit c9f938a379269f5b9ec861819cc226573a68dad8
> Author: Jason Merrill 
> Date:   Sat Sep 5 13:30:02 2015 -0400
> 
> Use --legacy.
> 
> ).  I noted various author map additions and one correction in 
>  - there are of course 
> further new committers since February that will require further authors 
> map updates.
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

I thought the gcc conversion was done.

I can make the repository available again if it's needed.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Joseph Myers]

On Thu, 27 Aug 2015, Eric S. Raymond wrote:

> I've made it available at:
> 
> http://thyrsus.com/gitweb/?p=gcc-conversion.git

What happened with this repository?  Is it somewhere else now?  Pulling in 
my clone of git://thyrsus.com/repositories/gcc-conversion.git has produced 
"thyrsus.com[0: 71.162.243.5]: errno=Connection refused" errors for 
several months now.  (The most recent commit I have in my clone is

commit c9f938a379269f5b9ec861819cc226573a68dad8
Author: Jason Merrill 
Date:   Sat Sep 5 13:30:02 2015 -0400

Use --legacy.

).  I noted various author map additions and one correction in 
 - there are of course 
further new committers since February that will require further authors 
map updates.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Eric S. Raymond]

Richard Biener :
> Not sure why we can't label the individual commits with Authors scraped
> from the ChangeLog entries in that commit.  Some commits even have
> multiple authors after all!  And if that fails I'd rather use the @gcc.gnu.org
> identity.

Because associating ChangeLog entries with repo commits is really
hard.  You talk as though there's a neat 1-1 mapping with every commit
containing one correctly-written ChangeLog comment.  That's never the
case in the wild, and any plan that assumes it will be is doomed.

I've been to this rodeo before on other GNU projects and the problem
is pretty much AI-complete.  That is, a human can do it relatively easily by
applying contextual knowledge, a computer program can't.

We can't count on the dates to match. There's a whole world of pain
there beginning with the fact that the ChangeLog timestamp and the
commit timestamp can easily be generated across opposite sides
of a top-of-second even if the ChangeLog timestamp was made by a Lisp
hook in Emacs.  And continuing with timezone and DST fooups.

We also can't count on the Subversion username of the commit to match any
address in the ChangeLog comment.  In fact this is the exact problem we
started out trying to solve.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Richard Biener]

On Thu, Sep 17, 2015 at 12:41 PM, Eric S. Raymond  wrote:
> Richard Biener :
>> Not sure why we can't label the individual commits with Authors scraped
>> from the ChangeLog entries in that commit.  Some commits even have
>> multiple authors after all!  And if that fails I'd rather use the 
>> @gcc.gnu.org
>> identity.
>
> Because associating ChangeLog entries with repo commits is really
> hard.  You talk as though there's a neat 1-1 mapping with every commit
> containing one correctly-written ChangeLog comment.  That's never the
> case in the wild, and any plan that assumes it will be is doomed.
>
> I've been to this rodeo before on other GNU projects and the problem
> is pretty much AI-complete.  That is, a human can do it relatively easily by
> applying contextual knowledge, a computer program can't.
>
> We can't count on the dates to match. There's a whole world of pain
> there beginning with the fact that the ChangeLog timestamp and the
> commit timestamp can easily be generated across opposite sides
> of a top-of-second even if the ChangeLog timestamp was made by a Lisp
> hook in Emacs.  And continuing with timezone and DST fooups.
>
> We also can't count on the Subversion username of the commit to match any
> address in the ChangeLog comment.  In fact this is the exact problem we
> started out trying to solve.

Maybe I'm missing sth but apart from the CVS imported revisions each
SVN revision should contain the actual change plus the changes to the
ChangeLog files (you can't count on the commit message itself I guess
as not all people replicate the ChangeLog entries there).

There may be cases we can't handle and then doing some commit ID
mapping might be ok, but I expect 95% of the cases to work out nicely
so we should preserve what is in the ChangeLog entry (note that we have
very strict formatting requirement for the authors there).

Richard.

> --
> http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Eric S. Raymond]

Richard Biener :
> Maybe I'm missing sth but apart from the CVS imported revisions each
> SVN revision should contain the actual change plus the changes to the
> ChangeLog files (you can't count on the commit message itself I guess
> as not all people replicate the ChangeLog entries there).
> 
> There may be cases we can't handle and then doing some commit ID
> mapping might be ok, but I expect 95% of the cases to work out nicely
> so we should preserve what is in the ChangeLog entry (note that we have
> very strict formatting requirement for the authors there).

All I can say is every time I've tried this it's been a nightmare, and
when you say "apart from CVS imported revisions" my hair stands on
end.  And the GCC history is two and a half times the size of the next
largest repo I've tried this on.

If you want to try writing the program to do this data analysis, go right
ahead. Somebody would have to pay me real money to try.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Richard Biener]

On Thu, Sep 17, 2015 at 4:57 AM, DJ Delorie  wrote:
>
> "Frank Ch. Eigler"  writes:
>> That makes sense, but how many people are in cagney's shoes
>
> I am one of those people - I have two email addresses listed in
> MAINTAINERS, with two sets of copyright papers filed with the FSF (a
> personal assignment and a work one).  I use the appropriate email
> address for each commit depending on which maintainership role I'm
> reflecting.
>
> Neither address is "obsolete" and neither address is @gcc.gnu.org.
>
> Using d...@gcc.gnu.org would imply that is my email address, but email
> sent there would vanish.

Would it?  You're supposed to have a valid forwarding address on that.

> But I did discuss my case with esr and understand it's not as easy to
> solve as we'd like it to be.

Not sure why we can't label the individual commits with Authors scraped
from the ChangeLog entries in that commit.  Some commits even have
multiple authors after all!  And if that fails I'd rather use the @gcc.gnu.org
identity.

Richard.

Re: Repository for the conversion machinery

[Jeff Law]

On 09/17/2015 10:24 AM, Richard Earnshaw wrote:

[ snip ]



No, I'm not going to do that work; and personally, I don't think it's
worth holding up the switch to wait for that to be done.

Agreed.

Jeff

Re: Repository for the conversion machinery

[Michael Matz]

Hi,

On Thu, 17 Sep 2015, Richard Earnshaw wrote:

> None of this has any chance of working for any commits to the pre-egcs 
> sources.  In those days there was no version control on the ChangeLog 
> file.
> 
> My feeling is we could spend months ratholing on this particular problem 
> rather than making real progress on moving forward.  If it will help to 
> move things forward, I'm happy to accept that for the purposes of 
> conversion we should just use 'committer id' and drop any attempt to 
> reconstruct 'author id' for each patch.

I don't see why the problems with some ranges of commits should prevent us 
doing better for those ranges where there are no such problems.  I thought 
reposurgeon (I haven't looked at it) had the ability to postprocess 
commits and dig out additional info, and assumed it would be more or less 
trivial to add such sed-greping.


Ciao,
Michael.

Re: Repository for the conversion machinery

[Richard Earnshaw]

On 17/09/15 16:15, Michael Matz wrote:
> Hi,
> 
> On Thu, 17 Sep 2015, Eric S. Raymond wrote:
> 
>> All I can say is every time I've tried this it's been a nightmare, and 
>> when you say "apart from CVS imported revisions" my hair stands on end.  
>> And the GCC history is two and a half times the size of the next largest 
>> repo I've tried this on.
>>
>> If you want to try writing the program to do this data analysis, go 
>> right ahead.
> 
> A start would be:
> svn diff -c50004 | sed -ne \
> '/^+++.*ChangeLog/,/^Index/s/^+.*[0-9] *\([^0-9]*[(<].*@.*[)>]\).*$/\1/p'
> 
> Sometimes (e.g. for some CVS imported commits) the commit to ChangeLog 
> files was done in a different revision than the changes themself (it 
> wasn't a very good CVS to subversion conversion), so for that the above 
> doesn't find the address (it will be the revision before or after that 
> touches ChangeLog, but no other files).  But it's fairly reasonable for 
> newer revisions.  Might need adjustments for even different date or email 
> address formats.  Feeding it all revisions when you have extracted them 
> already should give a resonable estimate for who the real author was.
> 
> 
> Ciao,
> Michael.
> 

None of this has any chance of working for any commits to the pre-egcs
sources.  In those days there was no version control on the ChangeLog file.

My feeling is we could spend months ratholing on this particular problem
rather than making real progress on moving forward.  If it will help to
move things forward, I'm happy to accept that for the purposes of
conversion we should just use 'committer id' and drop any attempt to
reconstruct 'author id' for each patch.

R.

Re: Repository for the conversion machinery

[Richard Earnshaw]

On 17/09/15 17:08, Michael Matz wrote:
> Hi,
> 
> On Thu, 17 Sep 2015, Richard Earnshaw wrote:
> 
>> None of this has any chance of working for any commits to the pre-egcs 
>> sources.  In those days there was no version control on the ChangeLog 
>> file.
>>
>> My feeling is we could spend months ratholing on this particular problem 
>> rather than making real progress on moving forward.  If it will help to 
>> move things forward, I'm happy to accept that for the purposes of 
>> conversion we should just use 'committer id' and drop any attempt to 
>> reconstruct 'author id' for each patch.
> 
> I don't see why the problems with some ranges of commits should prevent us 
> doing better for those ranges where there are no such problems.  I thought 
> reposurgeon (I haven't looked at it) had the ability to postprocess 
> commits and dig out additional info, and assumed it would be more or less 
> trivial to add such sed-greping.
> 
> 
> Ciao,
> Michael.
> 

Well if that's the case then someone ought to be able to produce a meta
file that could be supplied to Eric, that looked something like

$SVN: r
$Committer: 
$Author:...
$Author:...
$Author:...
...

$SVN:...
$Committer:
$NoAuthors




For the entire repo.  I'm sure if we had something like that, *and we
were happy that it were accurate enough*, then it would be
straight-forward enough to include it in the conversion process.

No, I'm not going to do that work; and personally, I don't think it's
worth holding up the switch to wait for that to be done.

R.

Re: Repository for the conversion machinery

[Michael Matz]

Hi,

On Thu, 17 Sep 2015, Eric S. Raymond wrote:

> All I can say is every time I've tried this it's been a nightmare, and 
> when you say "apart from CVS imported revisions" my hair stands on end.  
> And the GCC history is two and a half times the size of the next largest 
> repo I've tried this on.
> 
> If you want to try writing the program to do this data analysis, go 
> right ahead.

A start would be:
svn diff -c50004 | sed -ne \
'/^+++.*ChangeLog/,/^Index/s/^+.*[0-9] *\([^0-9]*[(<].*@.*[)>]\).*$/\1/p'

Sometimes (e.g. for some CVS imported commits) the commit to ChangeLog 
files was done in a different revision than the changes themself (it 
wasn't a very good CVS to subversion conversion), so for that the above 
doesn't find the address (it will be the revision before or after that 
touches ChangeLog, but no other files).  But it's fairly reasonable for 
newer revisions.  Might need adjustments for even different date or email 
address formats.  Feeding it all revisions when you have extracted them 
already should give a resonable estimate for who the real author was.


Ciao,
Michael.

Re: Repository for the conversion machinery

[Eric S. Raymond]

Michael Matz :
> I don't see why the problems with some ranges of commits should prevent us 
> doing better for those ranges where there are no such problems.  I thought 
> reposurgeon (I haven't looked at it) had the ability to postprocess 
> commits and dig out additional info, and assumed it would be more or less 
> trivial to add such sed-greping.

reposurgeon can do a lot, including regexp search-replace on
metadata or the content blobs. The problem is knowing what transfornations
to write.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Eric S. Raymond]

Richard Earnshaw :
> Well if that's the case then someone ought to be able to produce a meta
> file that could be supplied to Eric, that looked something like
> 
> $SVN: r
> $Committer: 
> $Author:...
> $Author:...
> $Author:...
> ...
> 
> $SVN:...
> $Committer:
> $NoAuthors
> 
> 
> 
> 
> For the entire repo.  I'm sure if we had something like that, *and we
> were happy that it were accurate enough*, then it would be
> straight-forward enough to include it in the conversion process.

Given somthing like that, yes, the mapping to reposurgeonm commands
would be easy.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[DJ Delorie]

Richard Biener  writes:
>> Using d...@gcc.gnu.org would imply that is my email address, but email
>> sent there would vanish.
>
> Would it?  You're supposed to have a valid forwarding address on that.

Frank tested it and it does seem to forward to me, so I guess so.

Re: Repository for the conversion machinery

[Jeff Law]

On 09/16/2015 09:26 AM, Andrew Cagney wrote:

On 15 September 2015 at 21:36, Frank Ch. Eigler  wrote:



cagney = Andrew Cagney 

cag...@gnu.org?


Good point.  The email identities of people change over time; forcing
a single arbitrary one to label all contributions is at best imprecise
and at worse a miscrediting.  (This is one way in which the impersonal
use...@gcc.gnu.org aliases work better.)


It strikes me as the least bad and quickest option.  It also best
reflects how CVS and SVN deal with identities.
(Would it go hand-in-hand with a git commit hook ensuring that future
commits preserve this convention?  Just asking)

Two other options come to mind:

- preserve history

That is create a repo that gives the appearance that we had git all
along.   It would be high quality, useful, and most git-like; and also
one hell of a lot of work :-/   For instance, it might include commits
by:
   Andrew Cagney  
   Andrew Cagney  
   Andrew Cagney  
   Andrew Cagney  
While they are all the same individual, they reflect different points
in time.   If we'd had git all along then this, I believe, is what the
repository would have contained. There would certainly be no
expectation that 20 year old addresses were still valid, or that they
need "fixing".
So true, but as you note, it'd probably be a ton of additional work to 
preserve that level of history.





- rewrite history - use some totally arbitrary, and quickly outdated,
internet identity
I think this is main reason why @gnu.org or @gmail.com style addresses 
are preferred over employer addresses when there's > 1 address on file.


Jeff

ps.  Good to hear from you...  It's been a long time.

Re: Repository for the conversion machinery

[Andrew Cagney]

On 15 September 2015 at 21:36, Frank Ch. Eigler  wrote:
>
>>> cagney = Andrew Cagney 
>> cag...@gnu.org?
>
> Good point.  The email identities of people change over time; forcing
> a single arbitrary one to label all contributions is at best imprecise
> and at worse a miscrediting.  (This is one way in which the impersonal
> use...@gcc.gnu.org aliases work better.)

It strikes me as the least bad and quickest option.  It also best
reflects how CVS and SVN deal with identities.
(Would it go hand-in-hand with a git commit hook ensuring that future
commits preserve this convention?  Just asking)

Two other options come to mind:

- preserve history

That is create a repo that gives the appearance that we had git all
along.   It would be high quality, useful, and most git-like; and also
one hell of a lot of work :-/   For instance, it might include commits
by:
  Andrew Cagney  
  Andrew Cagney  
  Andrew Cagney  
  Andrew Cagney  
While they are all the same individual, they reflect different points
in time.   If we'd had git all along then this, I believe, is what the
repository would have contained. There would certainly be no
expectation that 20 year old addresses were still valid, or that they
need "fixing".

- rewrite history - use some totally arbitrary, and quickly outdated,
internet identity

To me this makes the least sense.  If I change my name/contact do I
have the repo rewritten with that new information?  Am I forever
required to use an arbitrarily assigned identity?  Hardly.

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

Hi -

> [...]
> >- rewrite history - use some totally arbitrary, and quickly outdated,
> >internet identity

> I think this is main reason why @gnu.org or @gmail.com style addresses 
> are preferred over employer addresses when there's > 1 address on file.

That makes sense, but how many people are in cagney's shoes (with more
than one non-gcc.gnu.org email address in their commit history)?  It
sounds like they should all be canonicalized to u...@gcc.gnu.org.

- FChE

Re: Repository for the conversion machinery

[DJ Delorie]

"Frank Ch. Eigler"  writes:
> That makes sense, but how many people are in cagney's shoes

I am one of those people - I have two email addresses listed in
MAINTAINERS, with two sets of copyright papers filed with the FSF (a
personal assignment and a work one).  I use the appropriate email
address for each commit depending on which maintainership role I'm
reflecting.

Neither address is "obsolete" and neither address is @gcc.gnu.org.

Using d...@gcc.gnu.org would imply that is my email address, but email
sent there would vanish.

But I did discuss my case with esr and understand it's not as easy to
solve as we'd like it to be.

Re: Repository for the conversion machinery

[Ramana Radhakrishnan]

On Wed, Sep 16, 2015 at 6:06 PM, Frank Ch. Eigler  wrote:
> Hi -
>
>> [...]
>> >- rewrite history - use some totally arbitrary, and quickly outdated,
>> >internet identity
>
>> I think this is main reason why @gnu.org or @gmail.com style addresses
>> are preferred over employer addresses when there's > 1 address on file.
>

> That makes sense, but how many people are in cagney's shoes (with more
> than one non-gcc.gnu.org email address in their commit history)?  It
> sounds like they should all be canonicalized to u...@gcc.gnu.org.

I think if you dug there would be enough folks who've moved employment
over time and others who may change employers over time. Fixing this
to a non gcc.gnu.org in the commit logs is just going to cause
annoyance and confusion over time and I think we're better off with
just avoiding it. After all the information is in the changelog and in
the commit - currently svn log shows username with an implicit
gcc.gnu.org.

I can certainly say I'm in those shoes - you can work that out from
the Changelogs and I'm sure there may be others too.

It sounds like gcc.gnu.org is the safest map for everyone.

regards
Ramana

>
> - FChE

Re: Repository for the conversion machinery

[Jeff Law]

On 09/16/2015 11:21 AM, Ramana Radhakrishnan wrote:

On Wed, Sep 16, 2015 at 6:06 PM, Frank Ch. Eigler  wrote:

Hi -


[...]

- rewrite history - use some totally arbitrary, and quickly outdated,
internet identity



I think this is main reason why @gnu.org or @gmail.com style addresses
are preferred over employer addresses when there's > 1 address on file.





That makes sense, but how many people are in cagney's shoes (with more
than one non-gcc.gnu.org email address in their commit history)?  It
sounds like they should all be canonicalized to u...@gcc.gnu.org.


I think if you dug there would be enough folks who've moved employment
over time and others who may change employers over time.
Agreed.  In fact, I would say that most of the contributors over time 
have more than one address due to employment changes.


Jeff

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

>> cagney = Andrew Cagney 
> cag...@gnu.org?

Good point.  The email identities of people change over time; forcing
a single arbitrary one to label all contributions is at best imprecise
and at worse a miscrediting.  (This is one way in which the impersonal
use...@gcc.gnu.org aliases work better.)

- FChE

Re: Repository for the conversion machinery

[Andrew Cagney]

On 28 August 2015 at 13:24, Jeff Law  wrote:
> cagney = Andrew Cagney 

cag...@gnu.org?

Re: Repository for the conversion machinery

[Rainer Orth]

"Eric S. Raymond"  writes:

> I've made it available at:
>
> http://thyrsus.com/gitweb/?p=gcc-conversion.git
>
> The interesting content is gcc.map (the contributor map) and gcc.lift.

The current entry

ro = Rainer Orth 

lists my old email address.  Please use r...@cebitec.uni-bielefeld.de
instead.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

RE: Repository for the conversion machinery

[Thomas Preud'homme]

Hi,

Current email address for Xuepeng Guo is terry@arm.com

Best regards,

Thomas

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Eric S. Raymond
> Sent: Thursday, August 27, 2015 10:38 PM
> To: gcc@gcc.gnu.org
> Subject: Repository for the conversion machinery
> 
> I've made it available at:
> 
> http://thyrsus.com/gitweb/?p=gcc-conversion.git
> 
> The interesting content is gcc.map (the contributor map) and gcc.lift.
> 
> Presently the only command in gcc.lift expunges the hooks directory.
> --
>   http://www.catb.org/~esr/;>Eric S.
> Raymond

Re: Repository for the conversion machinery

[Eric S. Raymond]

Rainer Orth :
> The current entry
> 
> ro = Rainer Orth 
> 
> lists my old email address.  Please use r...@cebitec.uni-bielefeld.de
> instead.

Done.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: Repository for the conversion machinery

[Julian Brown]

On Fri, 28 Aug 2015 17:50:53 +
Joseph Myers  wrote:

> shinwell = Mark Shinwell 
>   (Jane Street)

Mark's current address is mshinw...@janestreet.com.

Julian

Re: Repository for the conversion machinery

[Joseph Myers]

There's at least one case of a contributor who changed their name where 
you have the old name instead of the new one: Richard Guenther - Richard 
Biener.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Peter Bergner]

On Thu, 2015-08-27 at 10:38 -0400, Eric S. Raymond wrote:
 I've made it available at:
 
 http://thyrsus.com/gitweb/?p=gcc-conversion.git
 
 The interesting content is gcc.map (the contributor map) and gcc.lift.
 
 Presently the only command in gcc.lift expunges the hooks directory.

From your list, I also see that alanm and amodra are both listed with
Alan's old bigpond.net.au address which no longer exists.  He now uses:

   amo...@gmail.com

Peter

Re: Repository for the conversion machinery

[Eric S. Raymond]

Peter Bergner berg...@vnet.ibm.com:
 On Thu, 2015-08-27 at 10:38 -0400, Eric S. Raymond wrote:
  I've made it available at:
  
  http://thyrsus.com/gitweb/?p=gcc-conversion.git
  
  The interesting content is gcc.map (the contributor map) and gcc.lift.
  
  Presently the only command in gcc.lift expunges the hooks directory.
 
 From your list, I also see that alanm and amodra are both listed with
 Alan's old bigpond.net.au address which no longer exists.  He now uses:
 
amo...@gmail.com
 
 Peter
 

Fixed, thanks.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Joseph Myers]

All the cygnus.com addresses are out of date.  More current replacements 
for a few:

echristo = Eric Christopher echri...@gmail.com
merrill = Jason Merrill ja...@redhat.com
  (if someone appears with multiple usernames, probably make their address 
   consistent for all of them unless specifically requested otherwise)
rsavoye = Rob Savoye rob.sav...@linaro.org

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Joseph Myers]

On Fri, 28 Aug 2015, Eric S. Raymond wrote:

 Joseph Myers jos...@codesourcery.com:
  There's at least one case of a contributor who changed their name where 
  you have the old name instead of the new one: Richard Guenther - Richard 
  Biener.
 
 Is
 
 rguenth = Richard Biener rguent...@suse.de
 
 correct?

Yes, that's right (it's what he uses for current ChangeLog entries).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Eric S. Raymond]

Jeff Law l...@redhat.com:
 Given that I worked for Cygnus and still work with Red Hat, I can make a
 pass over all the @cygnus.com addresses and probably give something more
 up-to-date for most of them if that's useful.

That would be *very* useful.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Eric S. Raymond]

Peter Bergner berg...@vnet.ibm.com:
  jgrimm = Jon Grimm jgri...@us.ibm.com
 
 Jon is now at Canonical.  I'm not sure which of the two email addresses
 that seem to be active for him he prefers:
 
   jon.gr...@canonical.com 
   jon.gr...@gmail.com

I'll go wit the gmail one unless he tells mme differently; odds are it will
outlast any individual job.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Jeff Law]

On 08/28/2015 09:26 AM, Joseph Myers wrote:

All the cygnus.com addresses are out of date.  More current replacements
for a few:

echristo = Eric Christopher echri...@gmail.com
merrill = Jason Merrill ja...@redhat.com
   (if someone appears with multiple usernames, probably make their address
consistent for all of them unless specifically requested otherwise)
rsavoye = Rob Savoye rob.sav...@linaro.org
Given that I worked for Cygnus and still work with Red Hat, I can make a 
pass over all the @cygnus.com addresses and probably give something more 
up-to-date for most of them if that's useful.


jeff

Re: Repository for the conversion machinery

[Peter Bergner]

 azanella = Adhemerval Zanella azane...@linux.vnet.ibm.com

Adhemerval now works for Linaro, so his email address should be:

adhemerval.zane...@linaro.org


 bje = Ben Elliston b...@redhat.com

Ben is no longer at Red Hat...or IBM.  He went back to school and his
new email address seems to be:

b.ellis...@unsw.edu.au


 dnovillo = Diego Novillo dnovi...@redhat.com

Diego is now at google, so his email address should be:

dnovi...@google.com


 drepper = Ulrich Drepper drep...@redhat.com

Uli is no longer at Red Hat (now at Goldman Sachs?).
His last email to the GCC mailing list used this address:

drep...@gmail.com

 janis = Janis Johnson janis...@us.ibm.com

Janis is now retired.  Her personal email address as listed in
the MAINTAINERS file is:

janis.marie.john...@gmail.com


 jgrimm = Jon Grimm jgri...@us.ibm.com

Jon is now at Canonical.  I'm not sure which of the two email addresses
that seem to be active for him he prefers:

jon.gr...@canonical.com 
jon.gr...@gmail.com


 luisgpm = Luis Machado luis...@br.ibm.com

Luis is now with Codesourcery.  His email address is:

lgust...@codesourcery.com


 meissner = Michael Meissner meiss...@cygnus.com

Mike is now at IBM, but his email address in the MAINTAINERS file is:

g...@the-meissners.org


 mircea = Mircea Namolaru namol...@il.ibm.com

Mircea is now working at INRIA.  His email address is:

mircea.namol...@inria.fr


 olga = Olga Golovanevsky o...@il.ibm.com

Olga is no longer at IBM.  I believe she is now at Cavium, but her
recent GNU Cauldron presentation used this address:

golovanevsky.o...@gmail.com


 spop = Sebastian Pop sebastian@amd.com

Sebastian is now at Samsung and his address is:

s@samsung.com


Peter

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers jos...@codesourcery.com:
 There's at least one case of a contributor who changed their name where 
 you have the old name instead of the new one: Richard Guenther - Richard 
 Biener.

Is

rguenth = Richard Biener rguent...@suse.de

correct?
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers jos...@codesourcery.com:
   (if someone appears with multiple usernames, probably make their address 
consistent for all of them unless specifically requested otherwise)

I am attemoting to do that.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Richard Biener]

On August 28, 2015 5:02:39 PM GMT+02:00, Eric S. Raymond e...@thyrsus.com 
wrote:
Joseph Myers jos...@codesourcery.com:
 There's at least one case of a contributor who changed their name
where 
 you have the old name instead of the new one: Richard Guenther -
Richard 
 Biener.

Is

rguenth = Richard Biener rguent...@suse.de

correct?

Yes.

Richard.

Re: Repository for the conversion machinery

[Jeff Law]

On 08/28/2015 09:57 AM, Eric S. Raymond wrote:

Jeff Law l...@redhat.com:

Given that I worked for Cygnus and still work with Red Hat, I can make a
pass over all the @cygnus.com addresses and probably give something more
up-to-date for most of them if that's useful.


That would be *very* useful.

Here's my stab at all the @cygnus.com and @redhat.com addresses. 
There's several I lost track of through the years.



bill = Bill Cox b...@rtl.cygnus.com
Retired.  Not sure of his email address.

billm = Bill Moyer bi...@cygnus.com
Now at Sonic.net.  bi...@ciar.org

noer = Geoffrey Noer n...@cygnus.com
Now at Panasas.  I don't have an email address though.

raeburn = Ken Raeburn raeb...@rtl.cygnus.com
Now at Permabit.  raeb...@permabit.com

abalkiss = Anthony Balkissoon abalk...@redhat.com
No clue on this one, not with Red Hat anymore.

aluchko = Aaron Luchko aluc...@redhat.com
Grad Student at University of Alberta.

bbooth = Brian Booth bbo...@redhat.com
Student at Simon Fraser University.  b...@sfu.ca

djee = David Jee d...@redhat.com
No clue.  Not with Red Hat anymore

fitzsim = Thomas Fitzsimmons fitz...@redhat.com
No clue.  Not with Red Hat anymore

hiller = Matthew Hiller hil...@redhat.com
No clue.  Not with Red Hat anymore

jknaggs = Jeff Knaggs jkna...@redhat.com
Not with Red Hat anymore

spolk = Syd Polk sp...@cygnus.com
Now at Mozilla.  sydp...@gmail.com

apbianco = Alexandre Petit-Bianco apbia...@redhat.com
Now at Google.  apbia...@serialhacker.org

bkoz = Benjamin Kosnik b...@redhat.com
b...@gnu.org

cchavva = Chandra Chavva ccha...@redhat.com
Cavium Networks  ccha...@caviumnetworks.com

clm = Catherine Moore c...@redhat.com
Code Sourcery  c...@codesourcery.com

graydon = Graydon Hoare gray...@redhat.com
Now at Stellar Development.  I don't know his email address.

jimb = Jim Blandy j...@redhat.com
Now at Mozilla I believe.  j...@red-bean.com

kgallowa = Kyle Galloway kgall...@redhat.com
He's at twitter now, but I don't have an email address.

rsandifo = Richard Sandiford rsand...@redhat.com
ARM rdsandif...@googlemail.com

tromey = Tom Tromey tro...@redhat.com
Now at Mozilla I believe.  t...@tromey.com

cagney = Andrew Cagney cag...@redhat.com
No longer with Red Hat.  Not sure where he is now.

chastain = Michael Chastain chast...@redhat.com
Not with Red Hat anymore.  Spent some time at Google, but 
I don't think he's there anymore either. 

dlindsay = Don Lindsay dlind...@redhat.com
Not with Red Hat anymore.  Was at Cisco for a period of time
(linds...@cisco.com).  Not sure if he's still there.

trix = Tom Rix t...@redhat.com
Not with Red Hat anymore.  No idea where he is now.


All these are still current:
aldyh = Aldy Hernandez al...@redhat.com
amacleod = Andrew Macleod amacl...@redhat.com
aoliva = Alexandre Oliva aol...@redhat.com
aph = Andrew Haley a...@redhat.com
brolley = Dave Brolley brol...@redhat.com
carlos = Carlos O'Donell car...@redhat.com
click = Nick Clifton ni...@redhat.com
davem = David S. Miller da...@redhat.com
dj = DJ Delorie d...@redhat.com
dmalcolm = David Malcolm dmalc...@redhat.com
fche = Frank Ch. Eigler f...@redhat.com
fnasser = Fernando Nasser fnas...@redhat.com
gary = Gary Benson gben...@redhat.com
gavin = Gavin Romig-Koch ga...@redhat.com
green = Anthony Green gr...@redhat.com
jakub = Jakub Jelinek ja...@redhat.com
jason = Jason Merrill ja...@redhat.com
jkratoch = Jan Kratochvil jan.kratoch...@redhat.com
kevinb = Kevin Buettner kev...@redhat.com
kseitz = Keith Seitz kse...@sources.redhat.com
ktietz = Kai Tietz kti...@redhat.com
law = Jeff Law l...@redhat.com
merrill = Jason Merrill ja...@redhat.com
mpolacek = Marek Polacek pola...@redhat.com
nickc = Nick Clifton ni...@redhat.com
oliva = Alexandre Oliva aol...@redhat.com
palves = Pedro Alves pal...@redhat.com
pmuldoon = Phil Muldoon pmuld...@redhat.com
rth = Richard Henderson r...@redhat.com
scox = Stan Cox s...@redhat.com
tiemann = Michael Tiemann tiem...@redhat.com
torvald = Torvald Riegel trie...@redhat.com
vmakarov = Vladimir Makarov vmaka...@redhat.com
wcohen = William Cohen wco...@redhat.com

Re: Repository for the conversion machinery

[Peter Bergner]

On Fri, 2015-08-28 at 11:00 -0400, Eric S. Raymond wrote:
 Peter Bergner berg...@vnet.ibm.com:
  On Thu, 2015-08-27 at 10:38 -0400, Eric S. Raymond wrote:
   I've made it available at:
   
   http://thyrsus.com/gitweb/?p=gcc-conversion.git
   
   The interesting content is gcc.map (the contributor map) and gcc.lift.
   
   Presently the only command in gcc.lift expunges the hooks directory.
  
  From your list, I also see that alanm and amodra are both listed with
  Alan's old bigpond.net.au address which no longer exists.  He now uses:
  
 amo...@gmail.com

It looks like you have a cut/paste error, with Alan's email address:

alanm = Alan Modra amodra@amo...@gmail.com
amodra = Alan Modra amodra@amo...@gmail.com

s/amodra@amodra@/amodra@/

Peter

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers jos...@codesourcery.com:
 FWIW, updates for some out-of-date codesourcery.com addresses:
 
 dgutson = Daniel Gutson daniel.gut...@tallertechnologies.com
 mmitchel = Mark Mitchell mark.patrick.mitch...@gmail.com
 mmitchell = Mark Mitchell mark.patrick.mitch...@gmail.com
 pbrook = Paul Brook p...@nowt.org
   (don't know if it's his preferred address, but it's his domain so
is likely be valid)
 qiyao = Yao Qi qiyao...@gmail.com

Thanks for sending these in contrib map format; it makes the merge easier,

 I don't have other addresses for the following immediately to hand,
 but the codesourcery.com ones are out of date:
 
 jwlemke = James Lemke jwle...@codesourcery.com
   (retired)
 kazu = Kazu Hirata k...@codesourcery.com
   (Cadence)
 oldham = Jeffrey D. Oldham old...@codesourcery.com
   (Google)
 samuel = Alex Samuel sam...@codesourcery.com
   (?)
 shinwell = Mark Shinwell shinw...@codesourcery.com
   (Jane Street)
 vprus = Vladimir Prus vladi...@codesourcery.com
   (?)

Not much we can do besides keep the old ones. For purposes of sites like
OpenHub they're at least better than nothing.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Joseph Myers]

FWIW, updates for some out-of-date codesourcery.com addresses:

dgutson = Daniel Gutson daniel.gut...@tallertechnologies.com
mmitchel = Mark Mitchell mark.patrick.mitch...@gmail.com
mmitchell = Mark Mitchell mark.patrick.mitch...@gmail.com
pbrook = Paul Brook p...@nowt.org
  (don't know if it's his preferred address, but it's his domain so
   is likely be valid)
qiyao = Yao Qi qiyao...@gmail.com

I don't have other addresses for the following immediately to hand,
but the codesourcery.com ones are out of date:

jwlemke = James Lemke jwle...@codesourcery.com
  (retired)
kazu = Kazu Hirata k...@codesourcery.com
  (Cadence)
oldham = Jeffrey D. Oldham old...@codesourcery.com
  (Google)
samuel = Alex Samuel sam...@codesourcery.com
  (?)
shinwell = Mark Shinwell shinw...@codesourcery.com
  (Jane Street)
vprus = Vladimir Prus vladi...@codesourcery.com
  (?)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Eric S. Raymond]

Peter Bergner berg...@vnet.ibm.com:
 On Fri, 2015-08-28 at 11:00 -0400, Eric S. Raymond wrote:
  Peter Bergner berg...@vnet.ibm.com:
   On Thu, 2015-08-27 at 10:38 -0400, Eric S. Raymond wrote:
I've made it available at:

http://thyrsus.com/gitweb/?p=gcc-conversion.git

The interesting content is gcc.map (the contributor map) and gcc.lift.

Presently the only command in gcc.lift expunges the hooks directory.
   
   From your list, I also see that alanm and amodra are both listed with
   Alan's old bigpond.net.au address which no longer exists.  He now uses:
   
  amo...@gmail.com
 
 It looks like you have a cut/paste error, with Alan's email address:
 
 alanm = Alan Modra amodra@amo...@gmail.com
 amodra = Alan Modra amodra@amo...@gmail.com
 
 s/amodra@amodra@/amodra@/
 
 Peter
 
 

Fixed, thanks.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Eric S. Raymond]

Jeff Law l...@redhat.com:
 Here's my stab at all the @cygnus.com and @redhat.com addresses. There's
 several I lost track of through the years.

Would you please resend this as a contrib map with the updated
addresses in it?  I find that when I hand-edit these in I make too
many cut'n'paste errors. Given a contrib map, repomapper -u can do it
all in one go.

If you don't know a current address for the person, we'll just leave the
redhat one in place - best we can do.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Mark Wielaard]

On Fri, Aug 28, 2015 at 11:24:30AM -0600, Jeff Law wrote:
 abalkiss = Anthony Balkissoon abalk...@redhat.com
 No clue on this one, not with Red Hat anymore.

 aluchko = Aaron Luchko aluc...@redhat.com
 Grad Student at University of Alberta.

 djee = David Jee d...@redhat.com
 No clue.  Not with Red Hat anymore

 kgallowa = Kyle Galloway kgall...@redhat.com
 He's at twitter now, but I don't have an email address.

These all worked on GNU Classpath and gcj, but I don't
have a current email address for them.
 
 fitzsim = Thomas Fitzsimmons fitz...@redhat.com
 No clue.  Not with Red Hat anymore

Works at Cisco now. fitz...@fitzsim.org

Cheers,

Mark

Re: Repository for the conversion machinery

[Jeff Law]

On 08/28/2015 12:29 PM, Eric S. Raymond wrote:

Jeff Law l...@redhat.com:

Here's my stab at all the @cygnus.com and @redhat.com addresses. There's
several I lost track of through the years.


Would you please resend this as a contrib map with the updated
addresses in it?  I find that when I hand-edit these in I make too
many cut'n'paste errors. Given a contrib map, repomapper -u can do it
all in one go.

If you don't know a current address for the person, we'll just leave the
redhat one in place - best we can do.

Will do, but won't get to it today.  Monday most likely.

jeff

Re: Repository for the conversion machinery

[David Edelsohn]

On Fri, Aug 28, 2015 at 1:24 PM, Jeff Law l...@redhat.com wrote:

 trix = Tom Rix t...@redhat.com
 Not with Red Hat anymore.  No idea where he is now.

Tom now works for Juniper Networks.  A recent email address is:

trix = Tom Rix tc...@bellsouth.net

- David

Repository for the conversion machinery

[Eric S. Raymond]

I've made it available at:

http://thyrsus.com/gitweb/?p=gcc-conversion.git

The interesting content is gcc.map (the contributor map) and gcc.lift.

Presently the only command in gcc.lift expunges the hooks directory.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Joseph Myers]

On Thu, 27 Aug 2015, Eric S. Raymond wrote:

 FX fxcoud...@gmail.com:
  [context for the Fortran list: the svn repo is about to be converted into a 
  git repo, which will be the official gcc repo onwards]
  
  Hi Eric,
  
  I realize that some of our Fortran maintainers (and committers) are not 
  listed in the map file:
  
  Fortran Janne Blomqvist j...@gcc.gnu.org
  Fortran Tobias Burnus   bur...@net-b.de
  Fortran Daniel Franke   
  franke.dan...@gmail.com
  Fortran Daniel Kraftd...@domob.eu
  Fortran Mikael Morinmikael.mo...@sfr.fr
  Fortran Janus Weil  ja...@gcc.gnu.org
  
  Is that normal?
 
 Do they have actual commits in the repository or were their commits shipped
 as patches and merged by a core maintainer?
 
 If the former, then I don't know why they're not in the map.  It contains
 an entry for every distinct Unix username it could extract.  What usernames
 should I expect these people to have?

For example:

r225805 | jb | 2015-07-15 00:00:23 -0700 (Wed, 15 Jul 2015) | 9 lines

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Richard Earnshaw]

On 27/08/15 17:16, Eric S. Raymond wrote:
 Paulo Matos pmatos@linki.tools:


 On 27/08/15 16:56, Paulo Matos wrote:

 I noticed I am not on the list (check commit r225509, user pmatos) either.

 And thanks for your help on this transition.


 r188804 | mkuvyrkov ma...@codesourcery.com

 for example.
 
 Do you know a full name for this person?
 

Maxim Kyvyrkov (now maxim.kuvyr...@linaro.org).

R.

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joel Sherrill joel.sherr...@oarcorp.com:
 
 
 On 8/27/2015 11:03 AM, Eric S. Raymond wrote:
 Paulo Matos pmatos@linki.tools:
 I noticed I am not on the list (check commit r225509, user pmatos) either.
 
 And thanks for your help on this transition.
 
 I've added you to the map.
 
 
 I will pile on. I may be in the history under at least three email addresses.
 
 j...@oarcorp.com
 joel.sherr...@oarcorp.com
 j...@gcc.gnu.org
 
 If it isn't too much trouble, just map me to the j...@gcc.gnu.org and I
 will try to be better about using that in ChangeLog entries in the future.

Done.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Joseph Myers]

273 missing usernames (this is based on grepping the output of svn log on 
an rsync mirror of the repository, so it's possible one or two could be 
spurious, but should be pretty accurate).  I've made no attempt to map 
these to emails yet.

aaw
abalkiss
abel
abennett
abutcher
acsawdey
aesok
ahyangyi2
ak
alalaw01
aldot
amker
amonakov
ams
andreabo
andreao
andrewjenner
apop
asharif
asutton
avelenko
azanella
baldrick
bd3
belagod
bergner
blzut3
boger
brooks
bstarynk
bviyer
carlos
carrot
cbaylis
ccoutant
cesar
cfairles
cfang
chaoyingfu
chefmax
chrbr
cltang
clyon
cmatthews
congh
crowl
dalecki
danielh
dardiss
darkbeer
davek
davids
davidxl
dcarrera
dehao
delesley
dgutson
dinar
dmalcolm
dodji
dominiq
domob
dougkwan
dsh
dvyukov
dwarak
dyuste
eager
edlinger
edmarwjr
eedelman
egavrin
emsr
eraman
erven
espindola
evancheng
eweddington
fabien
fdumont
froydnj
fyang
gandalf
gary
gchare
george
gfunck
gganesh
gingold
gjl
glisse
gretay
grosser
gshobaki
gsvelto
halewang
hariharans
harshit
haubi
hinnant
hjagasia
hmchang
hutchinsonandy
iains
ibolton
ibuclaw
ienkovich
iusmanov
iverbin
jamborm
jamesbowman
jasonwucj
jayants
jbeniston
jbglaw
jcmvbkbc
jfreeman
jgreenhalgh
jiez
jingyu
jiwang
jkratoch
jnorris
jsjodin
jyasskin
jye2
karthikkumar
kaushikp
kcc
kgallowa
ktietz
ktkachov
kuba
kugan
kvanhees
kwilliam
kyukhin
langton
lcwu
lekernel
lifeng
liqin
liujiangning
lixialiu
llozano
lmillward
ludo
luisgpm
maddox
manu
martinthuresson
marxin
mcrosier
meadori
meheff
meibf
merzlyakovao
mgretton
michaelh
mircea
miyuki
mkuvyrkov
mpf
mpolacek
msebor
mshawcroft
mueller
mwahab
mzakirov
naveenh
nenadv
nsz
nvachhar
olegendo
olegr
olga
palves
pbiggar
pmarlier
pmderodat
pmj
pmuldoon
pogma
pompa
ppalka
ppluzhnikov
prachigodbole
prathamesh3492
pronesto
pthaugen
ptomsich
pzhao
qiyao
qneill
raksit
ramana
rask
redfire
renlin
revitale
rkidd
rmh
robc
romangareev
rsavoye
rschuster
rts
rus
rwild
sabre
saliu
sam
sameerad
sandeep
sandra
sh
shenders
shenhan
shinwell
simartin
simonb
singhai
singler
smw
sofiane
spark
spyffe
sterling
sylvestre
tbm
tbsaunde
tejohnson
tema
tglek
thopre01
ths
tiloschwarz
timshen
tlafage
tlaurenzo
tmsriram
tneumann
tocarip
tomby
torvald
trifunovic
trippels
tschwinge
tsmigiel
tudalova
uecker
uramakrishna
vapier
vehre
vekumar
victork
ville
vondele
vp
vprus
vries
walt
wmi
wschmidt
xguo
xmj
xur
ygribov
yroux
yufeng
zaks
zippel
zqchen

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[FX]

[context for the Fortran list: the svn repo is about to be converted into a git 
repo, which will be the official gcc repo onwards]

Hi Eric,

I realize that some of our Fortran maintainers (and committers) are not listed 
in the map file:

Fortran Janne Blomqvist j...@gcc.gnu.org
Fortran Tobias Burnus   bur...@net-b.de
Fortran Daniel Franke   franke.dan...@gmail.com
Fortran Daniel Kraftd...@domob.eu
Fortran Mikael Morinmikael.mo...@sfr.fr
Fortran Janus Weil  ja...@gcc.gnu.org

Is that normal?

Also, could I ask that the email address used for me be changed from:

fxcoudert = François-Xavier Coudert coud...@clipper.ens.fr

(which has been inactive for many years now) to

fxcoudert = François-Xavier Coudert fxcoud...@gcc.gnu.org


Thanks,
FX

Re: Repository for the conversion machinery

[Eric S. Raymond]

Ian Lance Taylor i...@google.com:
 A lot of the e-mail addresses are out of date, as you know.  Would it
 be helpful to get updated e-mail addresses, or does it not really
 matter?

Updated addresses are better.  

 In gcc.map I see
 anoncvs = Anonymous CVS User anon...@gcc.gnu.org
 Are there any actual commits by this user?

I don't know yet.  Won't till my additional RAM gets here.

 In gcc.map:
 mmitchel = Mark Mitchell m...@codesourcery.com
 mmitchell = Mark Mitchell mmitch...@usa.net
 These are the same person (and the e-mail addresses are out of date).
 I don't know how the two different user IDs got in there.
 
 In gcc.map:
 click = Nick Clifton ni...@redhat.com
 nickc = Nick Clifton ni...@redhat.com
 These are the same person.  Maybe that is what is captured here, I don't know.

Yes.  I was told at least once before of a pair like this that happened
because one person was committing to GCC and EGCS under two different
usernames.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers jos...@codesourcery.com:
 For example:
 
 r225805 | jb | 2015-07-15 00:00:23 -0700 (Wed, 15 Jul 2015) | 9 lines

OK.  This means the map is not yet complete.

It will be very helpful if you can send me as many missing entries as
you notice - that is, pairs of Subversion IDs and human-mame/email IDs.

When I can make stubmap on a full conversion this should be easy
to fix up.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Paulo Matos]

On 27/08/15 16:56, Paulo Matos wrote:


I noticed I am not on the list (check commit r225509, user pmatos) either.

And thanks for your help on this transition.



r188804 | mkuvyrkov ma...@codesourcery.com

for example.

--
Paulo Matos

Re: Repository for the conversion machinery

[Matthew Wahab]

On 27/08/15 16:56, James Greenhalgh wrote:

On Thu, Aug 27, 2015 at 03:38:10PM +0100, Eric S. Raymond wrote:

I've made it available at:

http://thyrsus.com/gitweb/?p=gcc-conversion.git

The interesting content is gcc.map (the contributor map) and gcc.lift.

Presently the only command in gcc.lift expunges the hooks directory.


This appears to be missing some contributors whose usernames I recognise
(starting with me :-) )...

   jgreenhalgh = James Greenhalgh james.greenha...@arm.com (e.g. revision 
227028)
   ktkachov = Kyrylo Tkachov  kyrylo.tkac...@arm.com (e.g. r227012 )
   jiwang = Jiong Wang jiong.w...@arm.com (e.g. r227220 )
   renlin =  Renlin Li  renlin...@arm.com (e.g. r222635 )
   alalaw01 = Alan Lawrence  alan.lawre...@arm.com (e.g. r217927 )

Thanks,
James




Also

   mwahab = Matthew Wahab matthew.wa...@arm.com (r227219)

Matthew

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers jos...@codesourcery.com:
 273 missing usernames (this is based on grepping the output of svn log on 
 an rsync mirror of the repository, so it's possible one or two could be 
 spurious, but should be pretty accurate).  I've made no attempt to map 
 these to emails yet.

Jason Merrill's list later in the thread probably covers these.
I'll merge it.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Richard Earnshaw]

On 27/08/15 17:42, Eric S. Raymond wrote:
 Richard Earnshaw richard.earns...@foss.arm.com:
 On 27/08/15 17:03, Richard Earnshaw wrote:
 On 27/08/15 16:48, Eric S. Raymond wrote:

 If the former, then I don't know why they're not in the map.  It contains
 an entry for every distinct Unix username it could extract.  What usernames
 should I expect these people to have?


 Those aren't the only ones.  Just looking at the SVN log for
 gcc/config/arm/arm.md lists these userids, many of which are not in your
 list:

 For the ones I know and that may not be in your list:


 amkerBin Cheng (bin.ch...@arm.com)
 bernds   Bends Schmidt (codesourcery)

s/Bends/Bernd/ :-)

 bonzini  Paolo Bonzini
 carrot   Carrot (car...@google.com)

Real name Wei Guozhi

 cbaylis  Charles Baylis (charles.bay...@linaro.org)
 clyonChristophe Lyon (christophe.l...@linaro.org)
 dgutson Daniel Gutson (codesourcery?)
 dougkwan Doug Kwan (Google?)
 ghaziKaveh Ghazi ?
 gretay   Greta Yorsh (greta.yo...@arm.com)
 ibolton Ian Bolton (ian.bol...@arm.com)
 jgreenhalgh  James Greenhalgh (james.greenha...@arm.com)
 julesJulian Brown ? (CodeSourcery)
 ktkachov Kyrylo Tkachov (kyrylo.tkac...@arm.com)
 mgretton Matthew Gretton-Dann (matthew.gretton-d...@arm.com)
 mkuvyrkovMaxim Kuvrykov (maxim.kuvyr...@arm.com)
 mshawcroft   Marcus Shawcroft (marcus.shawcr...@arm.com)
 pb   Philip Blundel ?

Philip Blundell (ph...@gnu.org)

 pbrook   Paul Brook (CodeSourcery)
 ramana   Ramana Radhakrishnan (ramana.radhakrish...@arm.com)
 sameerad Sameera Deshpande (now at Imagination Technologies)
 sandra   Sandra Losemore ?
 sofiane  Sophiane Nachi (sophiane.na...@arm.com)
 thopre01 Thomas Preud'homme (thomas.preudho...@arm.com)
 vriesTom De Vries ? (Codesourcery?)
 yrouxYvan Roux (yvan.r...@linaro.org)
 yufeng   Yufeng Zhang (yufeng.zh...@arm.com)
 
 I have some of these.  I'll merge the rest.
 

Re: Repository for the conversion machinery

[Eric S. Raymond]

FX fxcoud...@gmail.com:
 [context for the Fortran list: the svn repo is about to be converted into a 
 git repo, which will be the official gcc repo onwards]
 
 Hi Eric,
 
 I realize that some of our Fortran maintainers (and committers) are not 
 listed in the map file:
 
 Fortran   Janne Blomqvist j...@gcc.gnu.org
 Fortran   Tobias Burnus   bur...@net-b.de
 Fortran   Daniel Franke   
 franke.dan...@gmail.com
 Fortran   Daniel Kraftd...@domob.eu
 Fortran   Mikael Morinmikael.mo...@sfr.fr
 Fortran   Janus Weil  ja...@gcc.gnu.org
 
 Is that normal?

Do they have actual commits in the repository or were their commits shipped
as patches and merged by a core maintainer?

If the former, then I don't know why they're not in the map.  It contains
an entry for every distinct Unix username it could extract.  What usernames
should I expect these people to have?

 Also, could I ask that the email address used for me be changed from:
 
 fxcoudert = François-Xavier Coudert coud...@clipper.ens.fr
 
 (which has been inactive for many years now) to
 
 fxcoudert = François-Xavier Coudert fxcoud...@gcc.gnu.org

Done.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[James Greenhalgh]

On Thu, Aug 27, 2015 at 03:38:10PM +0100, Eric S. Raymond wrote:
 I've made it available at:
 
 http://thyrsus.com/gitweb/?p=gcc-conversion.git
 
 The interesting content is gcc.map (the contributor map) and gcc.lift.
 
 Presently the only command in gcc.lift expunges the hooks directory.

This appears to be missing some contributors whose usernames I recognise
(starting with me :-) )...

  jgreenhalgh = James Greenhalgh james.greenha...@arm.com (e.g. revision 
227028)
  ktkachov = Kyrylo Tkachov  kyrylo.tkac...@arm.com (e.g. r227012 )
  jiwang = Jiong Wang jiong.w...@arm.com (e.g. r227220 )
  renlin =  Renlin Li  renlin...@arm.com (e.g. r222635 )
  alalaw01 = Alan Lawrence  alan.lawre...@arm.com (e.g. r217927 )

Thanks,
James
 

Re: Repository for the conversion machinery

[Richard Earnshaw]

On 27/08/15 16:48, Eric S. Raymond wrote:

 If the former, then I don't know why they're not in the map.  It contains
 an entry for every distinct Unix username it could extract.  What usernames
 should I expect these people to have?
 

Those aren't the only ones.  Just looking at the SVN log for
gcc/config/arm/arm.md lists these userids, many of which are not in your
list:

aesok
aldyh
amacleod
amker
amonakov
ams
aoliva
bernds
bje
bonzini
carrot
cbaylis
chrbr
clm
cltang
clyon
cpopetz
davidxl
dberlin
dgutson
dje
dougkwan
drow
erich
fyang
ghazi
gretay
hp
hubicka
ian
ibolton
jakub
jason
jgreenhalgh
jiez
jiwang
jsm28
jules
jye2
kazu
kcook
kenner
ktkachov
law
meissner
mgretton
mkuvyrkov
mmitchel
mrs
mshawcroft
mycroft
mzakirov
nathan
nickc
nico
pb
pbrook
ptomsich
ramana
rearnsha
revitale
rms
rsandifo
rth
sameerad
sandra
sofiane
steven
tege
thopre01
thorpej
uweigand
vries
wood
xguo
yroux
yufeng
zack

Re: Repository for the conversion machinery

[Eric S. Raymond]

Paulo Matos pmatos@linki.tools:
 I noticed I am not on the list (check commit r225509, user pmatos) either.
 
 And thanks for your help on this transition.

I've added you to the map.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Eric S. Raymond]

FX fxcoud...@gmail.com:
 PS: I found one username that first escaped my scripts because it contained a 
 period, so I am raising a flag here, so the same doesn’t happen to you: 
 m.hayes (commit 34779).

I have that one, thanks.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Eric S. Raymond]

David Edelsohn dje@gmail.com:
 On Thu, Aug 27, 2015 at 11:52 AM, Eric S. Raymond e...@thyrsus.com wrote:
  Joseph Myers jos...@codesourcery.com:
  Where someone is listed in MAINTAINERS, I suggest preferring that email
  address over any older address you may have got from ChangeLogs etc.
  (unless they're requested otherwise or it seems the MAINTAINERS address is
  the one that hasn't been kept up to date).
 
  Hm.  I tried to do it that way - the gccfind script I wrote looked in
  MAiNTAINERS first.
 
  For example, for Roland McGrath, rol...@hack.frob.com as in MAINTAINERS is
  probably to be preferred to rol...@delasyd.gnu.ai.mit.edu.
 
  Corrected.  I'll cheerfully accept any other corrections.
 
 dje = David Edelsohn d...@gcc.gnu.org
 edelsohn = David Edelsohn edels...@mhpcc.edu
 
 These are both me.  And I prefer dje@gmail.com, which is listed in
 MAINTAINERS.
 
 Thanks, David

Done.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Richard Earnshaw]

On 27/08/15 17:03, Richard Earnshaw wrote:
 On 27/08/15 16:48, Eric S. Raymond wrote:
 
 If the former, then I don't know why they're not in the map.  It contains
 an entry for every distinct Unix username it could extract.  What usernames
 should I expect these people to have?

 
 Those aren't the only ones.  Just looking at the SVN log for
 gcc/config/arm/arm.md lists these userids, many of which are not in your
 list:

For the ones I know and that may not be in your list:


amker   Bin Cheng (bin.ch...@arm.com)
bernds  Bends Schmidt (codesourcery)
bonzini Paolo Bonzini
carrot  Carrot (car...@google.com)
cbaylis Charles Baylis (charles.bay...@linaro.org)
clyon   Christophe Lyon (christophe.l...@linaro.org)
dgutson Daniel Gutson (codesourcery?)
dougkwanDoug Kwan (Google?)
ghazi   Kaveh Ghazi ?
gretay  Greta Yorsh (greta.yo...@arm.com)
ibolton Ian Bolton (ian.bol...@arm.com)
jgreenhalgh James Greenhalgh (james.greenha...@arm.com)
jules   Julian Brown ? (CodeSourcery)
ktkachov Kyrylo Tkachov (kyrylo.tkac...@arm.com)
mgrettonMatthew Gretton-Dann (matthew.gretton-d...@arm.com)
mkuvyrkov   Maxim Kuvrykov (maxim.kuvyr...@arm.com)
mshawcroft  Marcus Shawcroft (marcus.shawcr...@arm.com)
pb  Philip Blundel ?
pbrook  Paul Brook (CodeSourcery)
ramana  Ramana Radhakrishnan (ramana.radhakrish...@arm.com)
sameerad Sameera Deshpande (now at Imagination Technologies)
sandra  Sandra Losemore ?
sofiane Sophiane Nachi (sophiane.na...@arm.com)
thopre01Thomas Preud'homme (thomas.preudho...@arm.com)
vries   Tom De Vries ? (Codesourcery?)
yroux   Yvan Roux (yvan.r...@linaro.org)
yufeng  Yufeng Zhang (yufeng.zh...@arm.com)

Re: Repository for the conversion machinery

[Jeff Law]

On 08/27/2015 10:04 AM, FX wrote:

If the former, then I don't know why they're not in the map.


In fact, I can look at the output of “svn log” for the MAINTAINERS file, which 
probably almost everyone with commit rights has modified.
This contains 442 usernames, compared to the map’s 290. And there are probably 
more, which we’ll miss if we have to rely on manual modifications of that list…

How was the map generated?

FX



PS: I found one username that first escaped my scripts because it contained a 
period, so I am raising a flag here, so the same doesn’t happen to you: m.hayes 
(commit 34779).


Michael Hayes?

Jeff

Re: Repository for the conversion machinery

[David Edelsohn]

On Thu, Aug 27, 2015 at 11:52 AM, Eric S. Raymond e...@thyrsus.com wrote:
 Joseph Myers jos...@codesourcery.com:
 Where someone is listed in MAINTAINERS, I suggest preferring that email
 address over any older address you may have got from ChangeLogs etc.
 (unless they're requested otherwise or it seems the MAINTAINERS address is
 the one that hasn't been kept up to date).

 Hm.  I tried to do it that way - the gccfind script I wrote looked in
 MAiNTAINERS first.

 For example, for Roland McGrath, rol...@hack.frob.com as in MAINTAINERS is
 probably to be preferred to rol...@delasyd.gnu.ai.mit.edu.

 Corrected.  I'll cheerfully accept any other corrections.

dje = David Edelsohn d...@gcc.gnu.org
edelsohn = David Edelsohn edels...@mhpcc.edu

These are both me.  And I prefer dje@gmail.com, which is listed in
MAINTAINERS.

Thanks, David

Re: Repository for the conversion machinery

[Paulo Matos]

On 27/08/15 16:48, Eric S. Raymond wrote:

FX fxcoud...@gmail.com:

[context for the Fortran list: the svn repo is about to be converted into a git 
repo, which will be the official gcc repo onwards]

Hi Eric,

I realize that some of our Fortran maintainers (and committers) are not listed 
in the map file:

Fortran Janne Blomqvist j...@gcc.gnu.org
Fortran Tobias Burnus   bur...@net-b.de
Fortran Daniel Franke   franke.dan...@gmail.com
Fortran Daniel Kraftd...@domob.eu
Fortran Mikael Morinmikael.mo...@sfr.fr
Fortran Janus Weil  ja...@gcc.gnu.org

Is that normal?


Do they have actual commits in the repository or were their commits shipped
as patches and merged by a core maintainer?

If the former, then I don't know why they're not in the map.  It contains
an entry for every distinct Unix username it could extract.  What usernames
should I expect these people to have?



I noticed I am not on the list (check commit r225509, user pmatos) either.

And thanks for your help on this transition.

--
Paulo Matos

Re: Repository for the conversion machinery

[Eric S. Raymond]

FX fxcoud...@gmail.com:
  FortranJanne Blomqvist j...@gcc.gnu.org
  FortranTobias Burnus   bur...@net-b.de
  FortranDaniel Franke   
  franke.dan...@gmail.com
  FortranDaniel Kraftd...@domob.eu
  FortranMikael Morinmikael.mo...@sfr.fr
  FortranJanus Weil  ja...@gcc.gnu.org
  
  Do they have actual commits in the repository or were their commits shipped
  as patches and merged by a core maintainer?
  
  If the former, then I don't know why they're not in the map.  It contains
  an entry for every distinct Unix username it could extract.  What usernames
  should I expect these people to have?
 
 No, they did their commits themselves. Their Unix usernames are, in order: 
 jb, burnus, dfranke, domo, mikael, janus

OK, I've added them to the map.

I think what must have happened is that I made my intial stub map from
an incomplete mirror, so some names that are in passwd never made it in.
This should be easy to fix.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Joseph Myers]

Where someone is listed in MAINTAINERS, I suggest preferring that email 
address over any older address you may have got from ChangeLogs etc. 
(unless they're requested otherwise or it seems the MAINTAINERS address is 
the one that hasn't been kept up to date).

For example, for Roland McGrath, rol...@hack.frob.com as in MAINTAINERS is 
probably to be preferred to rol...@delasyd.gnu.ai.mit.edu.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers jos...@codesourcery.com:
 Where someone is listed in MAINTAINERS, I suggest preferring that email 
 address over any older address you may have got from ChangeLogs etc. 
 (unless they're requested otherwise or it seems the MAINTAINERS address is 
 the one that hasn't been kept up to date).

Hm.  I tried to do it that way - the gccfind script I wrote looked in
MAiNTAINERS first.

 For example, for Roland McGrath, rol...@hack.frob.com as in MAINTAINERS is 
 probably to be preferred to rol...@delasyd.gnu.ai.mit.edu.

Corrected.  I'll cheerfully accept any other corrections.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[FX]

 Fortran  Janne Blomqvist j...@gcc.gnu.org
 Fortran  Tobias Burnus   bur...@net-b.de
 Fortran  Daniel Franke   
 franke.dan...@gmail.com
 Fortran  Daniel Kraftd...@domob.eu
 Fortran  Mikael Morinmikael.mo...@sfr.fr
 Fortran  Janus Weil  ja...@gcc.gnu.org
 
 Do they have actual commits in the repository or were their commits shipped
 as patches and merged by a core maintainer?
 
 If the former, then I don't know why they're not in the map.  It contains
 an entry for every distinct Unix username it could extract.  What usernames
 should I expect these people to have?

No, they did their commits themselves. Their Unix usernames are, in order: jb, 
burnus, dfranke, domo, mikael, janus

In fact, if I just look at the commits to a very small subset of files 
(gcc/fortran/ChangeLog*), with “svn log”, I get the list of committers (Unix 
usernames) below. Many of them aren’t in the map at 
http://thyrsus.com/gitweb/?p=gcc-conversion.git;a=blob_plain;f=gcc.map;hb=HEAD
Out of the 10 first usernames, 3 are not (ak, aldot, baldrick).

Cheers,
FX



touille ~/devel/gcc/trunk/gcc/fortran $ for i in ChangeLog* ; do svn log $i 
|grep '^r[0-9]'|sed 's/.*| \([a-zA-Z0-9]*\) |.*/\1/' ; done | sort | uniq
aj
ak
aldot
aldyh
amacleod
amodra
amylaar
aoliva
baldrick
bdavis
bernds
bje
bonzini
bothner
brooks
burnus
canqun
carlos
crowl
dberlin
dcarrera
dfranke
dj
dje
dmalcolm
dnovillo
dodji
doko
dominiq
domob
dorit
drow
ebotcazou
echristo
edlinger
eedelman
espindola
fengwang
froydnj
fxcoudert
gchare
geoffk
george
gerald
ghazi
giovannibajo
hjl
hp
hubicka
iains
ian
jakub
jamborm
janus
jason
jb
jsm28
jvdelisle
kargl
kazu
kcook
kenner
krebbel
ktietz
ktkachov
kyukhin
langton
lauras
law
lmillward
manfred
manu
marxin
matz
meissner
meyering
mikael
miyuki
mpolacek
mrs
mueller
nathan
nickc
pault
pbrook
pinskia
pmderodat
pzhao
rakdver
reichelt
rguenth
ro
rsandifo
rth
rwild
saliu
sandra
sayle
schwab
simonb
sje
spop
srladd
steven
tbsaunde
tkoenig
tobi
toon
tromey
tschwinge
uros
uweigand
vehre
vondele
vries
wilson
zack
zadeck

Re: Repository for the conversion machinery

[Eric S. Raymond]

Joseph Myers jos...@codesourcery.com:
 On Thu, 27 Aug 2015, Ian Lance Taylor wrote:
 
  In gcc.map I see
  anoncvs = Anonymous CVS User anon...@gcc.gnu.org
  Are there any actual commits by this user?
 
 r17330, a test commit on 1998-01-13.  Presumably the test was followed by 
 fixing whatever bug allowed it.

This seems very likely to get dropped diring cleanup.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[FX]

 If the former, then I don't know why they're not in the map.

In fact, I can look at the output of “svn log” for the MAINTAINERS file, which 
probably almost everyone with commit rights has modified.
This contains 442 usernames, compared to the map’s 290. And there are probably 
more, which we’ll miss if we have to rely on manual modifications of that list…

How was the map generated?

FX



PS: I found one username that first escaped my scripts because it contained a 
period, so I am raising a flag here, so the same doesn’t happen to you: m.hayes 
(commit 34779).

Re: Repository for the conversion machinery

[Eric S. Raymond]

Paulo Matos pmatos@linki.tools:
 
 
 On 27/08/15 16:56, Paulo Matos wrote:
 
 I noticed I am not on the list (check commit r225509, user pmatos) either.
 
 And thanks for your help on this transition.
 
 
 r188804 | mkuvyrkov ma...@codesourcery.com
 
 for example.

Do you know a full name for this person?
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Joseph Myers]

On Thu, 27 Aug 2015, Ian Lance Taylor wrote:

 In gcc.map I see
 anoncvs = Anonymous CVS User anon...@gcc.gnu.org
 Are there any actual commits by this user?

r17330, a test commit on 1998-01-13.  Presumably the test was followed by 
fixing whatever bug allowed it.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Jeff Law]

On 08/27/2015 10:16 AM, Eric S. Raymond wrote:

Paulo Matos pmatos@linki.tools:



On 27/08/15 16:56, Paulo Matos wrote:


I noticed I am not on the list (check commit r225509, user pmatos) either.

And thanks for your help on this transition.



r188804 | mkuvyrkov ma...@codesourcery.com

Maxim Kuvyrkov

jeff

Re: Repository for the conversion machinery

[Richard Earnshaw]

On 27/08/15 17:20, Richard Earnshaw wrote:
 On 27/08/15 17:16, Eric S. Raymond wrote:
 Paulo Matos pmatos@linki.tools:


 On 27/08/15 16:56, Paulo Matos wrote:

 I noticed I am not on the list (check commit r225509, user pmatos) either.

 And thanks for your help on this transition.


 r188804 | mkuvyrkov ma...@codesourcery.com

 for example.

 Do you know a full name for this person?

 
 Maxim Kyvyrkov (now maxim.kuvyr...@linaro.org).
 

Duh!

Maxim Kuvyrkov (now maxim.kuvyr...@linaro.org).

R.

Re: Repository for the conversion machinery

[Ian Lance Taylor]

On Thu, Aug 27, 2015 at 7:38 AM, Eric S. Raymond e...@thyrsus.com wrote:
 I've made it available at:

 http://thyrsus.com/gitweb/?p=gcc-conversion.git

 The interesting content is gcc.map (the contributor map) and gcc.lift.

 Presently the only command in gcc.lift expunges the hooks directory.

Thanks for doing this.

A lot of the e-mail addresses are out of date, as you know.  Would it
be helpful to get updated e-mail addresses, or does it not really
matter?

In gcc.map I see
anoncvs = Anonymous CVS User anon...@gcc.gnu.org
Are there any actual commits by this user?

In gcc.map:
mmitchel = Mark Mitchell m...@codesourcery.com
mmitchell = Mark Mitchell mmitch...@usa.net
These are the same person (and the e-mail addresses are out of date).
I don't know how the two different user IDs got in there.

In gcc.map:
click = Nick Clifton ni...@redhat.com
nickc = Nick Clifton ni...@redhat.com
These are the same person.  Maybe that is what is captured here, I don't know.

Ian

Re: Repository for the conversion machinery

[Joel Sherrill]

On 8/27/2015 11:03 AM, Eric S. Raymond wrote:

Paulo Matos pmatos@linki.tools:

I noticed I am not on the list (check commit r225509, user pmatos) either.

And thanks for your help on this transition.


I've added you to the map.



I will pile on. I may be in the history under at least three email addresses.

j...@oarcorp.com
joel.sherr...@oarcorp.com
j...@gcc.gnu.org

If it isn't too much trouble, just map me to the j...@gcc.gnu.org and I
will try to be better about using that in ChangeLog entries in the future.

--joel sherrill

Re: Repository for the conversion machinery

[Eric S. Raymond]

James Greenhalgh james.greenha...@arm.com:
 On Thu, Aug 27, 2015 at 03:38:10PM +0100, Eric S. Raymond wrote:
  I've made it available at:
  
  http://thyrsus.com/gitweb/?p=gcc-conversion.git
  
  The interesting content is gcc.map (the contributor map) and gcc.lift.
  
  Presently the only command in gcc.lift expunges the hooks directory.
 
 This appears to be missing some contributors whose usernames I recognise
 (starting with me :-) )...
 
   jgreenhalgh = James Greenhalgh james.greenha...@arm.com (e.g. revision 
 227028)
   ktkachov = Kyrylo Tkachov  kyrylo.tkac...@arm.com (e.g. r227012 )
   jiwang = Jiong Wang jiong.w...@arm.com (e.g. r227220 )
   renlin =  Renlin Li  renlin...@arm.com (e.g. r222635 )
   alalaw01 = Alan Lawrence  alan.lawre...@arm.com (e.g. r217927 )

Thanks, those are useful additions,
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a

Re: Repository for the conversion machinery

[Eric S. Raymond]

Richard Earnshaw richard.earns...@foss.arm.com:
 On 27/08/15 17:03, Richard Earnshaw wrote:
  On 27/08/15 16:48, Eric S. Raymond wrote:
  
  If the former, then I don't know why they're not in the map.  It contains
  an entry for every distinct Unix username it could extract.  What usernames
  should I expect these people to have?
 
  
  Those aren't the only ones.  Just looking at the SVN log for
  gcc/config/arm/arm.md lists these userids, many of which are not in your
  list:
 
 For the ones I know and that may not be in your list:
 
 
 amker Bin Cheng (bin.ch...@arm.com)
 berndsBends Schmidt (codesourcery)
 bonzini   Paolo Bonzini
 carrotCarrot (car...@google.com)
 cbaylis   Charles Baylis (charles.bay...@linaro.org)
 clyon Christophe Lyon (christophe.l...@linaro.org)
 dgutson Daniel Gutson (codesourcery?)
 dougkwan  Doug Kwan (Google?)
 ghazi Kaveh Ghazi ?
 gretayGreta Yorsh (greta.yo...@arm.com)
 ibolton Ian Bolton (ian.bol...@arm.com)
 jgreenhalgh   James Greenhalgh (james.greenha...@arm.com)
 jules Julian Brown ? (CodeSourcery)
 ktkachov Kyrylo Tkachov (kyrylo.tkac...@arm.com)
 mgretton  Matthew Gretton-Dann (matthew.gretton-d...@arm.com)
 mkuvyrkov Maxim Kuvrykov (maxim.kuvyr...@arm.com)
 mshawcroftMarcus Shawcroft (marcus.shawcr...@arm.com)
 pbPhilip Blundel ?
 pbrookPaul Brook (CodeSourcery)
 ramanaRamana Radhakrishnan (ramana.radhakrish...@arm.com)
 sameerad Sameera Deshpande (now at Imagination Technologies)
 sandraSandra Losemore ?
 sofiane   Sophiane Nachi (sophiane.na...@arm.com)
 thopre01  Thomas Preud'homme (thomas.preudho...@arm.com)
 vries Tom De Vries ? (Codesourcery?)
 yroux Yvan Roux (yvan.r...@linaro.org)
 yufengYufeng Zhang (yufeng.zh...@arm.com)

I have some of these.  I'll merge the rest.
-- 
a href=http://www.catb.org/~esr/;Eric S. Raymond/a