Enumeration of issues relating to commit access
Mitchell Baker
issues:
1. Should commit access by repo-specific? or do we want to try to
ensure some consistency across repos?
2. What is the role of super-reviewer?
3. Comm-central is not locked the way moz-central is, I'm not sure we've
decided this is the right decision or if it's related to topic 4.
4. The calendar project has not used the super-review requirement for
commit access to the calendar project. This leads to two questions that
I know of: for the future, do we want a unified policy across
repositories; and how do we resolve this for the current calendar
committers.
5. We have respected hackers that can't get commit access because of
the requirement that one of the three supporters (two module owner
/peers as vouchers and one super-reviewer) not have the same employer.
This has become an issue because so many of the module owners and peers
have been hired by Mozilla. So there is the question of how one becomes
a committer, and a separate question of how we develop new and
additional module owners.
I'd like to start by addressing the question of commit access and
employment separation first. Then we can turn to the others. I've
included them all here as a means of cataloging open issues; I'm going
to ask Gerv to make a list of all the policy issues that have been
raised but not resolved, and hope to turn to a bunch of them over the
next few months. If you think there are other issues related to *commit
access* please add to the list.
David Ascher
> The discussions on commit access have raised a few related but
> separable issues:
>
> 1. Should commit access by repo-specific? or do we want to try to
> ensure some consistency across repos?
> If you think there are other issues related to *commit access* please
> add to the list.
This is related to 1, but I at least am quite fuzzy on what the rules
are for incubator repos, the labs repo, and user repos. Who gets a user
account, why, how? I think the different goals of the different repos
means that they should have different rules, but it'd be good to have
some baseline understanding of what they are for each kind.
--david
Mitchell Baker
https://wiki.mozilla.org/Commit_Policy:Current_Procedures . When this
is a bit further along it will be a big help in understanding today, and
also thinking about what if anything should be consistent.
mitchell
Mitchell Baker
Mike Connor
On 21-May-09, at 9:08 PM, Simon Paquet wrote:
> Mitchell Baker wrote:
>
>> 4. The calendar project has not used the super-review requirement for
>> commit access to the calendar project. This leads to two questions
>> that I know of: for the future, do we want a unified policy across
>> repositories; and how do we resolve this for the current calendar
>> committers.
>
> Speaking as a member of the Calendar Project, but not necessarily
> for it,
> let me say that we never used the super-review requirement for
> calendar
> code, but did use a second-review requirement for some time.
This is more in terms of commit access, so it's a little off-topic...
> I also believe that we are not the only project which has abandoned
> the
> super-review requirement. Camino has never used it as far as I know
> and
> the Firefox-specific code (mozilla/browser) as well as the underlying
> toolkit code (mozilla/toolkit) where never covered by this
> requirement as
> far as I recall.
I need to finish that push, but /browser and /toolkit will be covered
by SR under the new policy.
-- Mike