Proposing changes to granting CVS access

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposing changes to granting CVS access

Mike Connor-4
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.

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Robert O'Callahan-3
Mike Connor wrote:

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Mike Connor-4

On 24-May-06, at 8:21 PM, Robert O'Callahan wrote:

> Mike Connor wrote:
>> 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 :-).

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Darin Fisher-2
In reply to this post by Mike Connor-4
On 5/24/06, Mike Connor <[hidden email]> wrote:

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Phil Ringnalda
In reply to this post by Mike Connor-4
Mike Connor wrote:
> * 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Robert O'Callahan-3
Phil Ringnalda wrote:
> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Christian Biesinger
In reply to this post by Darin Fisher-2
Darin Fisher wrote:
> 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//?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Mark Pilgrim
In reply to this post by Phil Ringnalda
On 5/25/06, Phil Ringnalda <[hidden email]> wrote:
> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Mike Connor-3
In reply to this post by Mike Connor-4
Peter Weilbacher wrote:

> 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)
>
> Is that documented in detail somewhere? It's certainly not linked from
> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Dave Miller-2
In reply to this post by Mike Connor-4
In article
<[hidden email]>, Mike
Connor <[hidden email]> 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/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

jonsmirl@gmail.com
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.

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
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Axel Hecht-2
In reply to this post by Dave Miller-2
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.

> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Christian Biesinger
Axel Hecht wrote:
> 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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

jonsmirl@gmail.com
In reply to this post by Axel Hecht-2
On 5/28/06, Axel Hecht <[hidden email]> wrote:
> 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.

> > 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.

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
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

L. David Baron
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.

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

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

jonsmirl@gmail.com
On 5/28/06, L. David Baron <[hidden email]> wrote:

> 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
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

Christian Biesinger
Jon Smirl wrote:
> 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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

jonsmirl@gmail.com
On 5/28/06, Christian Biesinger <[hidden email]> wrote:
> Jon Smirl wrote:
> > 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.

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
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

L. David Baron
On Sunday 2006-05-28 12:09 -0400, Jon Smirl wrote:
> 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.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposing changes to granting CVS access

jonsmirl@gmail.com
On 5/28/06, L. David Baron <[hidden email]> wrote:

> On Sunday 2006-05-28 12:09 -0400, Jon Smirl wrote:
> > 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
[hidden email]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12