On Sat, Dec 1, 2012 at 8:53 AM, Eric S. Raymond <esr_at_thyrsus.com> wrote:
> There. You're done. It's backward-compatible (older installations
> can ignore the feature and nothing breaks). It's independent of your
> authentication method, but you can add auth checks if you care enough.
> It scales well because the burden of setting up FULLNAME strings is
> small and distributed - also because project administrators only have
> to make one decision, once.
Provided that it's not the default then I don't really see a problem with this.
> I'm not certain, but if your server-side hooks work the way I think
> they do, all of this except (1) can be done in Python. Not having to
> add complexity to your C code is a significant virtue.
It's not really about complexity in my opinion. It's about the fact
that putting it in the C code would be us trying to implement local
policies which can be implemented in a hook script without us trying
to consider every possible policy.
> If you have an LDAP setup or something like that, you don't need this
> - you flip some other switch once and stuff Just Works. Which is fine:
> the point of this proposal isn't to force a DVCS-like choice, it's to
> put in place a low-effort path to Internet-scoped attribution IDs that
> will *always work*.
LDAP or something like that is going to pay off much higher dividends
for the forge project than this initiative in my opinion.
> Somebody alleged "this is a social problem". That's only half-true, but
> now I'm going to focus on the true part. "Social problem" doesn't
> mean you can or should ignore it. It means you have to lead by
> educating and jawboning your users. A large step is just being willing
> to say, where your users can see it, "Internet-scoped attributions
> are important. Here's how to make them work..."
I really don't think in the context of Subversion that this is as
important as you make it out to be. The ASF Infra folks have probably
done more repository moves than just about anyone I can think about.
They've managed to handle this without internet scoped attributions.
The only thing this really buys you is that you theoretically don't
have to worry about userid conflicts. Which technically you don't
since the svn:author field isn't used in any meaningful way anyway.
I'd say that "First Last <user_at_example.com>" does not guarantee there
are no userid conflicts since if the userid ends up being:
John Smith <jsmith_at_gmail.com>
You could still end up with a situation where John Smith 1 stops using
gmail and loses that address and John Smith 2 comes along and gets it.
Unlikely, but you still have the problem, it's just less likely.
Received on 2012-12-01 15:49:32 CET