Ben Reser <b...@reser.org>:
> First of all the Ohloh problem has already been solved by Ohloh. You
> can claim your commits.
More pointless handwork. We ought to be designing *away* from this
sort of thing...
> 1) Some people may prefer not to use the same identity on different
> projects, even open source projects.
All my use cases and arguments map over neatly to the situation
where you have multiple public identities. The same scope, stability,
and ease-of-updating criteria apply; the only difference is that
you now want to have a per-repository settable attribution cookie
rather than one single global one.
> 2) If you allow an auto-setting of this identity to something based on
> the GECOS fields you may end up with the same individuals having
> different values.
I know. I never thought this was a good idea; I included this
protocol only for completeness.
> 3) You keep assuming that email addresses are immutably owned by
> someone. That is fundamentally not true for the vast majority of
> people and frankly is never absolutely not true.
So? Does this make it any less a good idea to support that case
properly? I think not - especially since committers to public
repositories are quite likely to be in the (admittedly minority)
group who do maintain stable addresses.
> As it stands I don't think
> Ohloh assumes that breser in this project is breser in that project.
> You have to claim those commits.
Only it's a Subversion or (probably - I haven't tested) CVS project.
I've never had to claim commits on a git repo. This make sense - the
Ohloh designers can safely assume a match in that case.
> As it stands the entire functioning of your proposed solution here is
> that people always remember to configure their unique id.
Which we know people will do from experience with DVCSes, where it's
required.
Subversion shouldn't turn into a DVCS, that's not what it's for. But
you shouldn't be too proud to learn from them, either, about things like
this.
> I don't see
> that as particularly easier than what the situation is now where you
> claim your commits.
O(1) cost vs. O(n) cost, where n is the number of repos. Q.E.D.
> Any argument that people might claim others
> commits I consider as unlikely as people setting their id to that of
> other people.
Agreed.
> Frankly, I don't think the vast majority of the user
> base cares about this problem, which gives them little incentive to
> care about setting this configuration setting.
Which is why we put in a switch admins can through to stop them from
committing until they do it. Problem solved.
> You have other reasons to desire this, but I think all of those are
> really resolved with a per-project authentication database.
> I agree with Brane though that I really don't see a problem with
> auto-revprops or a defined rev property name for this use. But I also
> think that most people just won't use this.
I'll work up a more detailed version of the proposal once I've dealt
with a few other replies.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
