Re: RFC: simple proposal for Internet-scoped IDs

Ben Reser <ben_at_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.

-- 
		Eric S. Raymond