>>>>> "Tollef" == Tollef Fog Heen <tfh...@err.no> writes:
Tollef> ]] Enrico Zini
>> For guest accounts opened by DSA directly, it can be pretty much
First, at this point in time I would be very skepticle of someone
contributing to Debian enough to need porter box access but not having a
salsa account.
It's possible, but that would be a yellow flag for me in evaluating
such a request.
There are two ways I might read the above statement.
First, subservient might mean that you're worried about an attack on
salsa propagating into DSA's LDAP.
Clearly that would be bad.
So, taking an automated data feed from salsa and acting on it is
something we'd want to view with hesitation if not out right concern.
However, as I read the guest account process, it has a number of manual
steps where people are processing tickets.
I suspect that DSA actually has a script or set of scripts that go
create the guest account.
Having these scripts check to see if the name is registered at salsa and
requiring manual override to create an account if it conflicts with
salsa and appears to belong to a different user is not, in my mind,
making DSA's ldap subservient to the salsa LDAP.
It might be making one of the namespaces DSA controls interact with a
larger overlapping namespace.
It won't stop DSA from doing anything.
In fact, Enrico has demonstrated that even if DSA chooses to ignore this
project or to create conflicts everything will work out with annoyance
felt mostly be the people who are involved in a conflict.
But like the rest of us, members of DSA can register salsa accounts.
(And if DSA needed additional mechanisms to register salsa accounts, I
strongly suspect the salsa admins would cooperate in creating such a
mechanism. If not, that sounds like something to escalate.)
I think this sort of namespace interaction--trying to have fewer
namespaces in the project and increase the chances that usernames in one
part of the project overlap with another--is a good thing.
And honestly, LDAP already is subservient to salsa in that game.
People interact with salsa far before they are going to interact with
DSA LDAP.
So much of what we do is based on salsa, and that's even more true for
many of the ways initial contributors can get involved with the project.
It is almost certain that your salsa account is the first Debian account
you will need.
Even if we have some SSO solution--even if we have some other account
lifecycle process you go through to get your salsa account, you'll be
going through that process first because you want a salsa account.
Yes, it's Debian.
There will doubtless be exceptions: we have exceptions to everything.
But salsa accounts are the accounts people first run into in the vast
majority of cases.
And if you buy the argument that people's usernames should not change
as their role in the organization changes, the LDAP namespace is already
de facto subservient to the salsa namespace.
Any of the cases where that's not true are cases that frustrate and get
in the way of people trying to contribute to our community.
If you don't buy that argument--if you believe that -guest is a feature
rather than a bug, then things are more complicated.
However, assuming that the mechanisms for determining easily if someone
are a dd are adequate, I think there is a rough consensus in this
discussion that keeping the same username as your role changes is
desirable.
--Sam
