Proposing changes to granting CVS access
Mike Connor
areas of where SR is not part of the process, and I think its time to
revisit the old requirements, especially as SR is playing a
diminishing role in our process, and the remaining active SRs are
involved in a narrower portion of the code. We have a variety of
exceptions for non-SR modules, but if one gets access for /browser
and /toolkit only, they can still check in anywhere, and eventually
will find that need. Unless we're going to restrict modules, it
makes more sense to apply a single standard across the board. NSS/
NSPR seem to be special/isolated enough that they could remain as the
sole exception.
Given that we do still require review by designated individuals (not
just anyone with CVS access) for shipping code, it seems that we
really only have the following requirements for CVS account holders:
* Recognized in and involved with the community (outside of your own
co-workers)
* Understands and follows our process (being on hook, awareness of
tree rules/state)
* Knows enough about the codebase to work without a net (i.e. can fix
bustage)
* Has enough of a track record to indicate the above (at least a
couple of months of active hacking)
Based on those criteria, I would propose we change the vouching
process to be as follows:
* All CVS account requests require a total of three vouchers (except
for NSS/NSPR)
* Vouchers must be module owners/peers for a module the individual
has patched
* At least one voucher must have a different employer than the
requestee (goes to community involvement more than anything else)
* Exceptions/escalations go through brendan
This should streamline the process, while preserving a fairly high
bar for getting access.
Thoughts?
-- Mike
Robert O'Callahan
> Based on those criteria, I would propose we change the vouching process
> to be as follows:
>
> * All CVS account requests require a total of three vouchers (except for
> NSS/NSPR)
> * Vouchers must be module owners/peers for a module the individual has
> patched
> * At least one voucher must have a different employer than the requestee
> (goes to community involvement more than anything else)
> * Exceptions/escalations go through brendan
>
> This should streamline the process, while preserving a fairly high bar
> for getting access.
>
> Thoughts?
Sounds good to me. It means we'll still have a problem where a person
who works entirely in one module won't be able to get CVS access easily.
Perhaps they'll just have to go off and fix a bug in some other module
to earn CVS privileges :-).
Rob
Mike Connor
What a terrible terrible fate to befall some poor contributor!
There's not a lot of modules where there aren't at least three people
acting as owners/peers, and if someone's doing a lot of work where
there isn't, we escalate to brendan.
-- Mike
Darin Fisher
> This has come up a few times recently, especially around ports and
> areas of where SR is not part of the process, and I think its time to
> revisit the old requirements, especially as SR is playing a
> diminishing role in our process, and the remaining active SRs are
> involved in a narrower portion of the code. We have a variety of
> exceptions for non-SR modules, but if one gets access for /browser
> and /toolkit only, they can still check in anywhere, and eventually
> will find that need. Unless we're going to restrict modules, it
> makes more sense to apply a single standard across the board. NSS/
> NSPR seem to be special/isolated enough that they could remain as the
> sole exception.
Isn't SpiderMonkey similarly restricted?
> Given that we do still require review by designated individuals (not
> just anyone with CVS access) for shipping code, it seems that we
> really only have the following requirements for CVS account holders:
>
> * Recognized in and involved with the community (outside of your own
> co-workers)
> * Understands and follows our process (being on hook, awareness of
> tree rules/state)
> * Knows enough about the codebase to work without a net (i.e. can fix
> bustage)
> * Has enough of a track record to indicate the above (at least a
> couple of months of active hacking)
>
>
> Based on those criteria, I would propose we change the vouching
> process to be as follows:
>
> * All CVS account requests require a total of three vouchers (except
> for NSS/NSPR)
> * Vouchers must be module owners/peers for a module the individual
> has patched
I agree that it is important that those who have reviewed the
contributor's code vouch for the contributor, but this rule seems a
little too strict. Maybe it is sufficient to say that at least one
(or two?) voucher(s) must be from an owner/peer for a module the
individual has patched.
It also seems sort of inefficient to force a contributor seeking CVS
write access to go patch another module just to be able to gather
enough vouchers. The alternative of escalating to Brendan does not
seem very efficient either. In many cases, it is pretty obvious from
the contributor's existing work that they meet the criteria for CVS
write access, and all we really need is some trusted individual to go
review their contributions.
-Darin
Phil Ringnalda
> * All CVS account requests require a total of three vouchers (except for
> NSS/NSPR)
> * Vouchers must be module owners/peers for a module the individual has
> patched
> * At least one voucher must have a different employer than the requestee
> (goes to community involvement more than anything else)
I *really* shouldn't be arguing against something that's clearly perfect
for me, since I'd have no problem getting three owner/peer vouchers
despite not having a single SR who's ever heard of me, but:
Accessibility. One of the biggest places for contributors-for-hire, and
it's got an owner and one peer, working for the same company, and the
same company as half the contributors. Maybe we're okay with forcing Sun
and IBM employees to fix one bug outside their job to get a rs voucher,
but that sure looks like the trouble spot at first glance.
Phil Ringnalda
Robert O'Callahan
> Accessibility. One of the biggest places for contributors-for-hire, and
> it's got an owner and one peer, working for the same company, and the
> same company as half the contributors. Maybe we're okay with forcing Sun
> and IBM employees to fix one bug outside their job to get a rs voucher,
> but that sure looks like the trouble spot at first glance.
Not really. A lot of accessibility patches get reviewed by layout peers.
Rob
Christian Biesinger
> Isn't SpiderMonkey similarly restricted?
And the LDAP SDKs, and webtools, and stuff like Rhino...
> It also seems sort of inefficient to force a contributor seeking CVS
> write access to go patch another module just to be able to gather
> enough vouchers. The alternative of escalating to Brendan does not
> seem very efficient either.
Maybe s/for a module the individual has patched//?
Mark Pilgrim
> Accessibility. One of the biggest places for contributors-for-hire, and
> it's got an owner and one peer, working for the same company, and the
> same company as half the contributors. Maybe we're okay with forcing Sun
> and IBM employees to fix one bug outside their job to get a rs voucher,
> but that sure looks like the trouble spot at first glance.
I've only been working on Firefox accessibility for a few months, but
I've already touched a *lot* of modules. Accessibility APIs of
course, but also various submodules of Toolkit, Help System, even URI
Loader. Accessibility touches everything eventually.
--
Cheers,
-Mark
Mike Connor
> On Wed, 24 May 2006 14:52:42 UTC, Mike Connor wrote:
>
>> * Understands and follows our process (being on hook, awareness of
>> tree rules/state)
>
> the "Getting CVS Write Access" page. Otherwise, how can you learn about
> it until you do it the first time? I know what is written on the
> tinderbox pages but not in detail what happens after I checked in
> something because I never did.
http://www.mozilla.org/hacking/bonsai.html perhaps?
>> * All CVS account requests require a total of three vouchers (except
>> for NSS/NSPR)
>> * Vouchers must be module owners/peers for a module the individual
>> has patched
>
> That doesn't really make it easier for ports, unless you want all CVS
> access requests for those to go through brendan. (Well, there will
> probably not that many anyway.)
I thought I replied to this last night, but looks like I didn't. I
think in the absence of appropriate vouchers, we would more
appropriately fall back on the SR list, since they are probably the
next-most-likely suspects to evaluate work in unfamiliar code.
Ports without existing module ownership should probably be talking to
our BBD (Beloved Benevolent Dictator) about establishing real ownership,
since that's a special case that is a fair bit different from just
getting on board with existing work.
-- Mike
Dave Miller
<mailman.2094.11485110...@lists.mozilla.org>, Mike
Connor <mco...@mozilla.com> wrote:
> if one gets access for /browser
> and /toolkit only, they can still check in anywhere, and eventually
> will find that need. Unless we're going to restrict modules, it
> makes more sense to apply a single standard across the board.
Is there a reason not to restrict modules? A feature I've been slated
to incorporate into despot in the near future is to be able to restrict
a given person so they can only check into a specific list of modules.
Primary motivation for this is community-supported pages on mozilla.com
since there are too many things that should be restricted there to list
a few hundred filespecs that will frequently change in the definition
of a restricted module, but it would also help for things like
webtools... we frequently grant commit access to people who hack on
webtools, which has absolutely nothing to do with any of the rest of
the Mozilla tree, and suddenly they can commit anywhere except for
social pressure not to.
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Jon Smirl
Most of you already know how this works, but I'll describe it again in
the hope that it will get considered. The Linux kernel uses
distributed source control and the git tool. There are other tools
like subversion.
In the Linux model there is one root tree controlled by Linus. He's
the only person (people cover when he is gone) with commit access.
Around him is a ring a project owners, each of these project owners
has their own tree. When a project owner is ready he tells Linus to
pull from his tree. Linus looks at the pull and makes sure that it is
only impacting the area that project owner controls or he asks for an
explanation. He trusts the project owners to make sure everything is
ok in their area.
This ring structure is then repeated. If I want to work on networking
I do so in my own tree. When my code is ready I ask the networking
project owner to pull from my tree (or I send him a patch). If the
project owner really trusts me he may grant me the ability to push
code into his tree without his approval.
The nice thing about this system is that it completely avoids the
problem of granting commit access to the main tree. The distributed
method also removes all need for CVS branches. Having worked with both
systems, I much prefer the distributed version. There are too many
times that I have seen the CVS trunk get accidentally damaged by
someone in a hurry to go someplace.
--
Jon Smirl
jons...@gmail.com
Axel Hecht
> Has moving to a different source code control model been discussed?
> Most of you already know how this works, but I'll describe it again in
> the hope that it will get considered. The Linux kernel uses
> distributed source control and the git tool. There are other tools
> like subversion.
Subversion doesn't offer any improvement on the permissions front.
> In the Linux model there is one root tree controlled by Linus. He's
> the only person (people cover when he is gone) with commit access.
> Around him is a ring a project owners, each of these project owners
> has their own tree. When a project owner is ready he tells Linus to
> pull from his tree. Linus looks at the pull and makes sure that it is
> only impacting the area that project owner controls or he asks for an
> explanation. He trusts the project owners to make sure everything is
> ok in their area.
>
> This ring structure is then repeated. If I want to work on networking
> I do so in my own tree. When my code is ready I ask the networking
> project owner to pull from my tree (or I send him a patch). If the
> project owner really trusts me he may grant me the ability to push
> code into his tree without his approval.
>
> The nice thing about this system is that it completely avoids the
> problem of granting commit access to the main tree. The distributed
> method also removes all need for CVS branches. Having worked with both
> systems, I much prefer the distributed version. There are too many
> times that I have seen the CVS trunk get accidentally damaged by
> someone in a hurry to go someplace.
>
We need branches, by concept. There is parallel development on the
previous stable branch, 1.8.0 right now, there is development in
direction of 2.0 and 3.0. However you call it, however you do it, those
are branches. I'd rather use a system that supports that concept than
hacks around it (like svn does with those shallow tree copies). Or by
putting it off to a different repos, like reported here about a
distributed system.
Axel
Christian Biesinger
> Or by
> putting it off to a different repos, like reported here about a
> distributed system.
FWIW, git supports branches the way you know it as well.
Jon Smirl
> Jon Smirl wrote:
> > Has moving to a different source code control model been discussed?
> > Most of you already know how this works, but I'll describe it again in
> > the hope that it will get considered. The Linux kernel uses
> > distributed source control and the git tool. There are other tools
> > like subversion.
>
> Subversion doesn't offer any improvement on the permissions front.
Subversion can work peer to peer with multiple repositories.
There are two ways to handle branches in git. One if the normal way
you do it with CVS. git supports this and it is often used locally.
The other way to support branches is to just have a repository for
each branch. That's something that can't be done easily with CVS but
is easy with peer to peer tools.
To do something like the layout branch you would first clone the
master tree. Do your work in this cloned tree and accept code from
other developers. Periodically pull from the master tree so that your
branch tree doesn't get too far out of sync (you don't have to do
this). When you are done, push the changes to the appropriate project
owners. They'll then push it on.to the main tree.
There is a fundamental difference in the way you look at things with
CVS vs peer to peer. With CVS there is only one repository. With peer
to peer there may be hundreds. Peer to peer is much more resilient,
if Linus were to disappear and take his repository with him nothing
would be lost since all clones contain the complete history. All you
would need to do is designate another person to take over Linus' role.
Git is also a dream for local development. Once you clone the master
you have a complete working repository on your local system. You can
do commits, make your own tags, make branches, make clones of it,
etc. This makes it easy to work on multiple things simultaneously.
When a change is ready identify the person it needs to go. Then there
are three ways to transmit, you push to them if you have write priv,
they pull from you, you generate a patch and email it. The pull/push
is great for large changes.
The whole process of R and SR review would disappear too. Review would
happen when a project owner accepts code into their repository. You
can do that once a day or once a week. SR review is equivalent of
pushing the change to the next stage of the chain. R/SR would now be
implicit in the data flow instead of explicit in bugzilla. Note that a
reviewer probably has multiple repositories. You accept the change
into a test repository first, review it, and then push it into your
good repository.
Once you use a peer to peer system you won't want to go back.
--
Jon Smirl
jons...@gmail.com
L. David Baron
> The whole process of R and SR review would disappear too. Review would
> happen when a project owner accepts code into their repository. You
> can do that once a day or once a week. SR review is equivalent of
No it wouldn't. Doing all the committing needed, watching tinderbox for
bustage and fixing it, watching for performance regressions, etc., is a
lot of work, often significantly more than reviewing the code.
Distributing that responsibility across large numbers of people is one
of the main reasons we're so keen to give cvs access to large numbers of
people.
That is, unless you want the core hackers who are capable of reviewing
patches to do nothing else other than review patches from others (i.e.,
never write their own). But I think we actually do want the people who
know the code the best writing code occasionally.
And I think somebody made this point the last time you made this claim.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
Jon Smirl
> On Sunday 2006-05-28 10:31 -0400, Jon Smirl wrote:
> > The whole process of R and SR review would disappear too. Review would
> > happen when a project owner accepts code into their repository. You
> > can do that once a day or once a week. SR review is equivalent of
>
> No it wouldn't. Doing all the committing needed, watching tinderbox for
> bustage and fixing it, watching for performance regressions, etc., is a
> lot of work, often significantly more than reviewing the code.
> Distributing that responsibility across large numbers of people is one
> of the main reasons we're so keen to give cvs access to large numbers of
> people.
Linux uses a slightly different staging system. After Linus accept
changes he runs the equivalent of the tinderbox test before making the
changes visible. If the tinder box fails he pushes the changes back to
where they came from.
It doesn't have to be Linus doing the push back, it could just as
easily be a test group. It all depends on how you construct the work
flow through the system.
There is also another process going on with Andrew and the mm builds
that I haven't described. Andrew runs an independent testing
mechanism, sort of like a beta for the kernel. By running changes
through Andrew you can be pretty sure that there won't be problems
when the change gets to Linus.
> That is, unless you want the core hackers who are capable of reviewing
> patches to do nothing else other than review patches from others (i.e.,
> never write their own). But I think we actually do want the people who
> know the code the best writing code occasionally.
I'm not sure what you are getting at. The review burden is identical
under both systems. The peer to peer system just make it easier to
pass things around.
Linus does pretty much only review, but that is his choice and not a
requirement of the system. It could just as easily be organized so
that 15 people could push changes to the master tree.
If you want, you could exactly clone the current R/SR review system
and behavior of CVS using the git tools. But then you lose all of the
benefits.
> And I think somebody made this point the last time you made this claim.
Sorry for bring this up again. Having used both systems extensively I
find the peer to peer system vastly more productive and was trying to
share that knowledge. Of course Mozilla wouldn't copy the kernel
process exactly but there may be ways to use peer to peer to increase
productivity in the Mozilla environment.
--
Jon Smirl
jons...@gmail.com
Christian Biesinger
> If you want, you could exactly clone the current R/SR review system
> and behavior of CVS using the git tools. But then you lose all of the
> benefits.
That's not true at all. You can still keep almost all, if not all, the
benefits, namely local branches, local commits, ability to work offline,
etc. And you get the additional benefit that people who are used to CVS
can continue working like they always did.
Jon Smirl
Obviously Mozilla would design their own work flows using the peer to
peer concepts. Here's two scenarios just to give you an idea of what
is possible.
First an automated staging server for the tinder boxes. By using two
trees commits could be first made to a private tree. Only after the
private tree passes the automated tinder box tests do the changes
become visible by pushing them to the public tree. If the tinderbox
fails the changes are backed out of the private tree and sent back to
where they came from for adjustment. In this model the main tree never
contains tinderbox failures.
Second, large external projects. In Mozilla CVS there is only one
central tree. If an external entity want to make extensive changes
they will want the ability to track their changes. This is usually
handled by copying the Mozilla CVS into a local CVS. But now these two
repositories aren't linked. Simple things like moves and renames in
the Mozilla CVS can make it very difficult to keep the external CVS
sync. Usually people just give up and let it get out of sync. Once
things get out of sync they start to drift further apart making
merging difficult. Peer to peer avoids this whole problem since the
peer repositories are linked via their shared history. As long as you
periodically sync with the main Mozilla repository, the drift in the
external repository is minimal. Peer systems track things like move
and rename making this process easier.
--
Jon Smirl
jons...@gmail.com
L. David Baron
> First an automated staging server for the tinder boxes. By using two
> trees commits could be first made to a private tree. Only after the
> private tree passes the automated tinder box tests do the changes
> become visible by pushing them to the public tree. If the tinderbox
> fails the changes are backed out of the private tree and sent back to
> where they came from for adjustment. In this model the main tree never
> contains tinderbox failures.
Sorry, that's not what would happen.
Unless there's only one change at a time different between the staging
tree and the main tree (which would slow commits to a crawl), there
would be failures in the main tree because:
* people commit to the main tree in a different order than the
tinderbox tree
* people commit to the tinderbox tree and then forget to commit to the
main tree
Also, for purposes of performance history, etc., the commits on the
tinderbox tree would become the more interesting history to follow. So
I suspect that people would just stop using the "main tree" and use only
the tinderbox tree.
Jon Smirl
> > First an automated staging server for the tinder boxes. By using two
> > trees commits could be first made to a private tree. Only after the
> > private tree passes the automated tinder box tests do the changes
> > become visible by pushing them to the public tree. If the tinderbox
> > fails the changes are backed out of the private tree and sent back to
> > where they came from for adjustment. In this model the main tree never
> > contains tinderbox failures.
>
> Sorry, that's not what would happen.
>
> Unless there's only one change at a time different between the staging
> tree and the main tree (which would slow commits to a crawl), there
> would be failures in the main tree because:
> * people commit to the main tree in a different order than the
> tinderbox tree
> * people commit to the tinderbox tree and then forget to commit to the
> main tree
No one ever directly commits to the public tree. The only way things
get into the public tree is by passing the tinder box process. Once a
tinderbox passes the the tinderbox automation code pushes the changes
into the public tree. Automatically pushing changes from one tree to
another is not something that can be easily done with CVS.
Changes would be batched into the private tree for tinderbox
comsumption. If you get an error from the tinderbox things going into
the private tree would stop just just like they do now until someone
sorts out the error. But the main tree is still good while this
process happens.
> Also, for purposes of performance history, etc., the commits on the
> tinderbox tree would become the more interesting history to follow. So
> I suspect that people would just stop using the "main tree" and use only
> the tinderbox tree.
Both trees will have identical history, the private tree will just
contain a few checkin that haven't made it into the public tree. When
a batch of changes moves from one tree to another they aren't
consolidated, they still look like individual changes.
Think of this as a work flow process where commits(patches) flow from
tree to tree. This is a very different model than CVS. Draw a model of
the responsibility flow in the Mozilla process on a whiteboard. Now
put a peer repository at each node in the diagram. Commits(patches)
then flow across the links. Commit rights are equivalent to granting
the ability to write to a repository.
--
Jon Smirl
jons...@gmail.com
Jon Smirl
On an error the tinderbox looks at the logs to see where the new
patches came from. It sends a copy of the tinderbox error out to
everyone who submitted patches. Note that things are arranged like an
onion, only the first layer gets these messages if a patch has been
passed around.
The tinderbox then deletes its repository with errors and clones a
copy of the known good public repository. It then sends out mail
saying that it is open for business again.
Since it doesn't know which patch contained the error it relies on
humans to resubmit the patches that were free of errors. This may be
as simple as looking at the status, seeing that it is not in the area
you cover and typing push again. This process could also be done by
having a sheriff pull from the appropriate source repositories.
When a tinderbox runs successfully the batch of patches that passed is
automatically pushed out to the main public repository. The tinderbox
is the only thing with rights to write to the main public repository.
Of course many variations on this are possible. The idea is to start
think about the work flow of patches through the system.
--
Jon Smirl
jons...@gmail.com
L. David Baron
> No one ever directly commits to the public tree. The only way things
> get into the public tree is by passing the tinder box process. Once a
> tinderbox passes the the tinderbox automation code pushes the changes
> into the public tree. Automatically pushing changes from one tree to
> another is not something that can be easily done with CVS.
Even if it's automated, it still has limited value, since:
* the nightly builds would probably be done from the tinderbox tree
(since they're done by the tinderboxes), unless we move them to
separate machines
* developers who are updating in order to commit would need to update
to the tinderbox tree in order to do manual merging that is often
necessary
So it seems like it's only valuable for developers who are updating to
the trunk for reasons other than wanting to commit. Not having to check
tinderbox before doing that has some value, but it's not huge. I still
think you're vastly overselling this particular advantage of distributed
version control.
> Both trees will have identical history, the private tree will just
No, the times things landed will be different, and that's what's
important for understanding performance data over time.
Jon Smirl
> > No one ever directly commits to the public tree. The only way things
> > get into the public tree is by passing the tinder box process. Once a
> > tinderbox passes the the tinderbox automation code pushes the changes
> > into the public tree. Automatically pushing changes from one tree to
> > another is not something that can be easily done with CVS.
>
> Even if it's automated, it still has limited value, since:
>
> * the nightly builds would probably be done from the tinderbox tree
> (since they're done by the tinderboxes), unless we move them to
> separate machines
How are nightly builds done so that they don't get broken? I'd
probably just tag each known good build in the tree and copy off the
last know good build for the nightly. The binaries should still be on
the tinderbox machines.
> * developers who are updating in order to commit would need to update
> to the tinderbox tree in order to do manual merging that is often
> necessary
Doing this depends on how you choose to set up the tinder box process.
Is it a push or pull process? Linus uses a pull process. He pulls the
changes from each project owner and merges them himself. Since the
project areas are fairly well separated he doesn't get that many
significant merges conflicts. A build sheriff could do this each time
a new tinderbox cycle is started.
The other model is a push process. Everyone will try to push their
changes into the tinder box tree when it opens. If someone gets in
front of you peer to peer systems will notice that the tree you as
pushing to contains changes that your tree doesn't have. It will force
you to pull from that tree before continuing. When you pull you'll get
the merge conflicts and have to resolve them. When resolved push your
changes back to the tinderbox tree. Repeat this process until
everything is in the tinderbox tree.
> So it seems like it's only valuable for developers who are updating to
> the trunk for reasons other than wanting to commit. Not having to check
> tinderbox before doing that has some value, but it's not huge. I still
> think you're vastly overselling this particular advantage of distributed
> version control.
Another value is that non-project owner developers never see a broken tree.
> > Both trees will have identical history, the private tree will just
>
> No, the times things landed will be different, and that's what's
> important for understanding performance data over time.
The level of time data tracked on commits varies with the peer to peer
system used. But instead of using timestamp you could just add tags
to the trees corresponding to when performance measurements were
taken.
I'm not pushing any specific peer to peer system. Picking a specific
one would be up to the core developers. I'm just trying to explain
general benefits that can be gained from using peer to peer.
--
Jon Smirl
jons...@gmail.com
L. David Baron
> [...]
Some of your suggestions are reasonable, but many of the details you
suggest are not appropriate for us. Given that you're not an active
participant in Mozilla development and don't understand what we
currently do and need, you'd probably be better of avoiding some of the
more detailed suggestions. However, since you respond to every response
to your posts, I'm going to stop responding, since I think this thread
is rapidly getting off-topic.
Other people (who have a much broader understanding of our requirements
[1]) are investigating moving to a different version control system.
dev-planning is *not* an appropriate list for discussion of those
requirements; I'd suggest dev-builds.
-David
[1] http://wiki.mozilla.org/Version_Control_System_Requirements
Robert Accettura
I'm not so sure the development/checkin process needs change... getting
CVS commit privileges is the main discussion at hand (and an appropriate
one). I think the general process works pretty good (just look at the
progress made since the Netscape layoffs and you can tell). I'd hate to
tinker with success unless there's a real solid problem identified, and
a solid coherent fix.
Regarding cvs privileges, my only suggestion would be the addition of 1
requirement:
- At least [in my opinion 6] months of documented community
participation. This is pretty generic intentionally, bugzilla activity,
newsgroup, sfx, mozillazine forums, etc. etc. My reasoning for this is
to prevent a few things, obviously the "let me do 3 bugs in 3 modules to
get my own cvs account". And much more importantly, to give candidates
a chance to understand the community dynamic, and how processes work.
It's a big tree. I think a little time also gives some time to judge
not just the quality of code the person submits, but their understanding
of the bigger picture. Of course could be exempt by brendan.
That's my only addition, no changes to the other stuff proposed by
mconnor, which looks pretty solid and logical.
-Robert
> ------------------------------------------------------------------------
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Robert Accettura
rob...@accettura.com
Robert O'Callahan
> Regarding cvs privileges, my only suggestion would be the addition of 1
> requirement:
> - At least [in my opinion 6] months of documented community
> participation.
6 would be way too long.
1 or 2, maybe.
Rob
Robert Accettura
easy to get that it becomes a normal commodity for everyone and their
dog, they should be for active developers who appear to be sticking
around for a while.
In similar vein... I think some discussion would be warranted for
inactive accounts. Though that's another topic for another day, I don't
want to derail this.
-R
Zac Bowling
better after we switched from CVS about a year and a half ago.
We don't have anything to special past alert scripts that send emails
when stuff happens in specific directories and CIA integration in Mono,
but Subversion can handle permissions with custom hook scripts any way
you want them. You can hook in scripts to deny or allow anything, even
based on what code is in the commit. Several scripts can get launched at
several different times, passed with the data at each point. You can
even modify the commit during its push to the server (even though its
not recommended because the client can get confused with some changes as
they are not notified of your update).
In a project I'm working on internally in my corp environment, we grep
to make sure that no reference to obsolete headers is called unless
checked in by a senior engineer for our root framework. We even enforce
check-in dates for when we freeze specific branches, and also we prevent
changes to the directories in the tags directory unless by admin
(everyone has permission to add a new tag, just never change it).
You can use anything you want in the hook script (just an sh script) to
can do anything. It just allows or denies based on the return code of
the script. We hacked ours together with custom security system with
ldap that simply checks the commit vs the data in the ldap with a few
queries. Like if they are in the admin group they can delete, if they
are in the contractor group, then the commit automatically sends an
email for code review and the files are stamped with a "unverified"
tag.
We are even adding a feature I hope to open source soon. Its a method
were we have a verified and unverified tree. Everyone commits into the
unverified trunk. All the code has to be verified via a web interface
that shows the diffs one by one. The commits have to be voted to be
accepted by two of the senior developers (or by one admin) so that
someone has to review it. (Also if an admin checks something in and they
tag the commit with the name "release" it will automatically push the
code to the verified tree). We have to follow a bunch of agreements for
code review for our insurance and our agreements with our share holders
and partners since we work on system critical financial software.
Pretty much you can do anything you want with subversion. I'm willing to
help if you any questions or want to set up a prototype.
Zac Bowling
z...@zacbowling.com - http://zacbowling.com/
Mono Project Maintainer - http://mono-project.com/
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Zac Bowling <z...@zacbowling.com>
Zac Bowling
CVS/SVN servers (no password auth, RSA keys only). We don't enforce
security after someone gets access since we trust our users to play
nicely and not tinker in any modules they shouldn't be in. I don't
believe we have had to revoke anyone access really though we have
slapped a few wrists.
On the Mono side, we have a little more then a 1500 shell accounts, but
I know that less then 150 of them have been in use in the past 3 months
to commit anything (some people use the their keys to access the late
breaking changes since our anon SVN servers are lagged by about 1 to 2
hours).
GNOME has dramatically more users on their CVS and has a similar
problem.
In Mono, Miguel de Icaza gives out access himself and gives access to
anyone he feels is competent (normally because they sent in a bunch of
patches that show they know what they are doing, they have a new module
or feature they already have some work on done that fits in with mono,
or because we can trust them but they need access to the breaking
changes).
I'm not sure what GNOME does anymore but we also loosy request that all
SSH keys that people send us expire in one year and someone has to
manually update the key when they email to the SVN admin.
On Sun, 2006-05-28 at 15:55 -0700, Robert Accettura wrote:
> I wouldn't argue with that.... my point is that they shouldn't be so
> easy to get that it becomes a normal commodity for everyone and their
> dog, they should be for active developers who appear to be sticking
> around for a while.
>
> In similar vein... I think some discussion would be warranted for
> inactive accounts. Though that's another topic for another day, I
> don't
> want to derail this.
--
Zac Bowling <z...@zacbowling.com>
Axel Hecht
There are minor improvements in the sense that there is a
cross-directory notification, but that has been worked around for CVS
for a long time now.
All we do is use those hooks via despot, and there is no change of
crappiness in those tools if they'd be called by svn rather than cvs.
Axel, who doesn't need replies per email.
Boris Zbarsky
> * Recognized in and involved with the community (outside of your own
> co-workers)
> * Understands and follows our process (being on hook, awareness of tree
> rules/state)
> bustage)
> * Has enough of a track record to indicate the above (at least a couple
> of months of active hacking)
Add:
* Actually fixes issues pointed out in review comments
to the list?
-Boris
Zac Bowling
What if someone did check something in where they shouldn't. If its
security related, could a subtitle check-in happen a not get caught by
the module owner? If they break the social rules and check in where they
shouldn't but meant no harm, is reverting such changes with a slap on
the wrist and fixing after the fact instead of preventing it before the
fact worse? I know from experience where really difficult security
policies that the community has to do deal with can effect the general
motivation of the community to help out in many cases. In many cases it
could take days to get access to another module if a source control
admin had to grant access to that other person (but then that fact can't
be minimized by distributing the admin duties).
In GNOME and Mono, after you prove yourself worthy of access in the
first place, its pretty much the social pressure and good eddicate that
stops people from making changes where they shouldn't. A few people have
been slapped for committing in modules they shouldn't and their changes
are quickly reverted. I don't recall us ever having to revoke anyone's
access though for continued by faith. This model might break down though
where you have a massive number of contributors (we have over 1000
people with commit access in Mono with about 150 people that are active
in past few months, and gnome is a ton larger but deals the same).
Zac Bowling
Zac Bowling <z...@zacbowling.com>
Matt Seitz
> Git is also a dream for local development. Once you clone the master
> you have a complete working repository on your local system. You can
> do commits, make your own tags, make branches, make clones of it,
> etc. This makes it easy to work on multiple things simultaneously.
It is for this reason that I would love to see the Mozilla source tree
made available in a distributed source control system. I would like to
be able to try making my own local changes to the SeaMonkey suite. I
would then like to be able to merge my changes with any updates in the
Mozilla source tree.
Right now, it appears there are two options:
1) Use a source tar ball, create a local CVS archive, and create a
vendor branch to track Mozilla tree changes.
Unfortunately, I need to use the 1.8 branch version of SeaMonkey. There
have been no source tar ball releases for this branch.
2) Check out the source from the Mozilla CVS archive.
This solution seems to have the following drawbacks:
-No way to track the history of my local changes
-No way to work on my changes on multiple computers
It seems that having the source available from a distributed source
control system would make it much easier for me to work on my local
modifications.
Zac Bowling
into GIT and check it back in upstream. Though running it against the
anon CVS by everyone and their sister might make it melt since ever
single check in is checked out one by one.
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
--
Zac Bowling <z...@zacbowling.com>
Christian Biesinger
> There is also GIT extentions for CVS and SVN that pull the entire repo
> into GIT and check it back in upstream. Though running it against the
> anon CVS by everyone and their sister might make it melt since ever
> single check in is checked out one by one.
You can rsync the Mozilla CVS repository. But that doesn't help you
anyway, because cvsps/git kind of fail to import the Mozilla repository
last I tried...
Matt Seitz
> There is also GIT extentions for CVS and SVN that pull the entire repo
> into GIT and check it back in upstream.
I thought about that. But from what I read on the Developer pages, I'm
not supposed to do a full CVS checkout. Instead, I read that I'm
supposed to use "client.mk". So even if I did convert the CVS repo, I'm
not sure I would be able to perform a build from the results.