I didn't have time until now to get caught up with this thread. Having
gone through it a couple times, I'd like to up-level and just discuss
the requirements.
I can see two possible requirements.
One is ensuring that contributions are covered by an appropriate legal
agreement.
Another is ensuri
> "Rich" == Richard Lowe writes:
Rich> So, you ditched some context here. Was the original mail on an
Rich> external list?
No, internal. I no longer have the start of the thread, but I might be
able to dig it out of an archive if you really need it.
Rich> That said, I think it's pretty fu
Stephen Hahn wrote:
>> That's not exactly what I meant, what I was asking was if a person has
>> commit rights on a project that delivers to ON, do they automatically
>> get ON commit rights, or do they explicitly need to be granted ON commit
>> rights in addition to their project-level rights?
Stephen Hahn wrote:
>> We also have the issue of who actually grants commit rights - is this
>> going to be by a central body, or are the GCs and projects that make up
>> ON going to manage their own committers?
>
> Both. I've been warning projects that seek to integrate into a
> consolid
Stephen Hahn writes:
> * Alan Burlison [2007-12-04 19:09]:
>> Stephen Hahn wrote:
>>
>> >>We also have the issue of who actually grants commit rights - is this
>> >>going to be by a central body, or are the GCs and projects that make up
>> >>ON going to manage their own committers?
>> >
>> >
* Alan Burlison [2007-12-04 19:09]:
> Stephen Hahn wrote:
>
> >>We also have the issue of who actually grants commit rights - is this
> >>going to be by a central body, or are the GCs and projects that make up
> >>ON going to manage their own committers?
> >
> > Both. I've been warning proje
* Alan Burlison [2007-12-03 22:19]:
> Stephen Hahn wrote:
>
> >>The problem we have is that we have no reliable way of identifying Sun
> >>employees in the current OSO database. There is a employee_id column,
> >>but there's nothing to check it is filled in correctly, or even at all.
> >>Emai
Richard Lowe wrote:
>> And as for commit roles, it is still completely unclear how commit
>> rights are going to be allocated - for example are these managed
>> centrally for all ON committers, or does each project that contributes
>> to ON manage its own pool of committers? In the absence of
Jim Walker wrote:
>> That is why the new database schema distinguishes between different
>> classes of SCA - if we know a particular person is covered by a Sun
>> SCA, we also know that their 'reference' will be a Sun employee ID,
>> and that could be checked against the corporate LDAP database
Richard Lowe wrote:
>> (I am assuming that the employee_id is only editable by site
>> administrators, and is presumed valid.)
>
> Contributor agreements are ephemeral. Sun employees are under a
> blanket SCA (in effect), a person leaving Sun should not lose their
> access, but it *would* re
Stephen Lau wrote:
> There's the case of Sun employees who have since left
> If they've filed an individual SCA, then the SCA field is filled out -
> but if they haven't, then there isn't any way to differentiate them from
> current Sun employees.
Correct.
That is why the new database sche
Stephen Hahn wrote:
>> The problem we have is that we have no reliable way of identifying Sun
>> employees in the current OSO database. There is a employee_id column,
>> but there's nothing to check it is filled in correctly, or even at all.
>> Email addresses are no use either. And if we don
Richard Lowe writes:
> Alan Burlison writes:
>
>> Richard Lowe wrote:
>>
And as for commit roles, it is still completely unclear how commit
rights are going to be allocated - for example are these managed
centrally for all ON committers, or does each project that
contributes
Alan Burlison writes:
> Richard Lowe wrote:
>
>>> And as for commit roles, it is still completely unclear how commit
>>> rights are going to be allocated - for example are these managed
>>> centrally for all ON committers, or does each project that
>>> contributes to ON manage its own pool of com
Alan Burlison writes:
> And as for commit roles, it is still completely unclear how commit
> rights are going to be allocated - for example are these managed
> centrally for all ON committers, or does each project that contributes
> to ON manage its own pool of committers? In the absence of a
Alan Burlison wrote:
> Richard Lowe wrote:
>
>> I have no idea *which* members of the parent community, and I fear the
>> kind of political stupidity such questions tend to cause when voiced
>> too loudly.
>>
>
> Ss! They might be listening! :-)
>
>
Politic stupids lurk everywher
Alan Burlison wrote:
> Stephen Lau wrote:
>
>> There's the case of Sun employees who have since left
>> If they've filed an individual SCA, then the SCA field is filled out -
>> but if they haven't, then there isn't any way to differentiate them from
>> current Sun employees.
>
> Correct.
>
Stephen Hahn writes:
> * Alan Burlison [2007-12-01 11:30]:
>> The problem we have is that we have no reliable way of identifying Sun
>> employees in the current OSO database. There is a employee_id column,
>> but there's nothing to check it is filled in correctly, or even at all.
>> Email ad
Stephen Hahn wrote:
> * Alan Burlison [2007-12-01 11:30]:
>
>> The problem we have is that we have no reliable way of identifying Sun
>> employees in the current OSO database. There is a employee_id column,
>> but there's nothing to check it is filled in correctly, or even at all.
>> Email
* Alan Burlison [2007-12-01 11:30]:
> The problem we have is that we have no reliable way of identifying Sun
> employees in the current OSO database. There is a employee_id column,
> but there's nothing to check it is filled in correctly, or even at all.
> Email addresses are no use either. A
Richard Lowe wrote:
>> And if someone
>> does a merge, aren't they the author of the resulting merge?
>
> They are the author of the merge, but they are still transferring N
> other changesets (the bits they merged in), the majority of which they
> will not be the author of.
What do the Hg hooks
Alan Burlison writes:
> Richard Lowe wrote:
>
>>> And if someone
>>> does a merge, aren't they the author of the resulting merge?
>>
>> They are the author of the merge, but they are still transferring N
>> other changesets (the bits they merged in), the majority of which they
>> will not be the
Alan Burlison writes:
> Richard Lowe wrote:
>
>> There are people other than project leads who may have cause to do
>> this. With projects, whoever does a specific merge from the parent
>> will be putting back changes they didn't author. There's also
>> situations where people import an exporte
Richard Lowe wrote:
> There are people other than project leads who may have cause to do
> this. With projects, whoever does a specific merge from the parent
> will be putting back changes they didn't author. There's also
> situations where people import an exported changeset as part
> sponsorin
Richard Lowe wrote:
> If you demand the usernames match, you still have no way to prevent
> new users colliding with SWAN usernames that as yet are not on
> opensolaris.org, for the same reason you can't do any checking on
> existing names.
Not necessarily true, the usernames could be checked aga
Richard Lowe wrote:
>> There's another issue though - there is no requirement that OSO and SWAN
>> usernames match up, and there's nothing to prevent someone outside
>> registering with a username that is the same as an existing SWAN
>> one.
>
> I'm not sure why that matters.
Because people w
Alan Burlison writes:
> Mike Kupfer wrote:
>
>> Mike> We could implement a policy [...]
>>
>> One thing to keep in mind about the policy-based approaches is that
>> there are situations where someone will need to push changes that
>> (s)he didn't commit (e.g., gatekeeper for release N+1 synching
Alan Burlison writes:
> Richard Lowe wrote:
>
>>> There's another issue though - there is no requirement that OSO and
>>> SWAN usernames match up, and there's nothing to prevent someone
>>> outside registering with a username that is the same as an existing
>>> SWAN
>>> one.
>>
>> I'm not sure w
Mike Kupfer wrote:
> Mike> We could implement a policy [...]
>
> One thing to keep in mind about the policy-based approaches is that
> there are situations where someone will need to push changes that
> (s)he didn't commit (e.g., gatekeeper for release N+1 synching up with
> the changes at the en
Mike Kupfer wrote:
> We could implement a policy that says that all changesets must use the
> correct @opensolaris.org email address. This could be enforced on
> the server. But we'd need to work through the implications of such a
> policy, like whether the os.o email address is enabled by defau
Alan Burlison writes:
> Mike Kupfer wrote:
>
>> We could implement a policy that says that all changesets must use the
>> correct @opensolaris.org email address. This could be enforced on
>> the server. But we'd need to work through the implications of such a
>> policy, like whether the os.o em
Mike Kupfer writes:
> (moving the conversation to scm-migration-dev)
>
>> "Alan" == Alan Burlison writes:
>
> Mike> As far as people using bogus email addresses with Mercurial, it's
> Mike> technically possible, but then it's also possible for people to
> Mike> commit something other than wh
> "Mike" == Mike Kupfer writes:
Mike> We could implement a policy [...]
One thing to keep in mind about the policy-based approaches is that
there are situations where someone will need to push changes that
(s)he didn't commit (e.g., gatekeeper for release N+1 synching up with
the changes at
(moving the conversation to scm-migration-dev)
> "Alan" == Alan Burlison writes:
Mike> As far as people using bogus email addresses with Mercurial, it's
Mike> technically possible, but then it's also possible for people to
Mike> commit something other than what they got code reviewed. If so
34 matches
Mail list logo
