AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080418145216.2fd46af0@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<tim.gardner@onstor.com>,<jonathan.goldick@onstor.com>,<larry.scheer@onstor.com>,<paul.hammer@onstor.com>,<brian.stark@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E097CC466@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 18 Apr 2008 14:52:47 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Tim Gardner" <tim.gardner@onstor.com>
Cc: "Jonathan Goldick" <jonathan.goldick@onstor.com>, "Larry Scheer"
 <larry.scheer@onstor.com>, "Paul Hammer" <paul.hammer@onstor.com>, "Brian
 Stark" <brian.stark@onstor.com>
Subject: Re: Branch policies
Message-ID: <20080418145247.222f51f0@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E097CC466@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E097CC466@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 17 Apr 2008 15:54:39 -0700 "Tim Gardner"
<tim.gardner@onstor.com> wrote:

> 
> I propose to send the following email to the software team.
> Please provide your input before I do so.
> 
> Tim
> 
> 
> 
> 
> 
> 
> Over the past few weeks we have been working hard to develop a branch
> strategy that will
> enable us to deliver a quality cougar product, have a successful
> cougar beta program, and
> continue to support non-cougar work such as escalation fixes. I thank
> you all for the
> valuable input that you have provided during this process.
> 
> As of now I would like to institute the following policies:

As of now I would like to remind and reinforce the existing policies
and processes, which folks will be expected to adhere to perhaps a
bit more than in the past, and explain how the cougar branch will work.

> dev branch
> *	Unrestricted for any fixes for cougar defects. As always,
> the p4 change description must contain the defect number.

and a description of the bug.

> *	Unrestricted for any fixes done by the escalation team. 
> I do ask that the escalation team communicate to me any significant
> changes or changes that pose high
> risk for regression.

No change, regardless of source, is acceptable for checking in to the
dev branch unless it has undergone the proper amount of unit testing.
Therefore this item is not necessary in so far as it must always be the
case for any checkin, bug fix, developement of new code/features, etc.
The review process must include an explanation of the testing
undertaken in the case of changes that could have far reaching effects,
like changes to the scsi layer, changes to rmc, the filesystem, and so
on. And this only because the testing for such changes is not
necessarily obvious or trivial.  This is all the process that is
necessary to keep unnecessarily risky changes out of the dev branch.

> *	Unrestricted for unit tests and automated test code
> (nfx-tree/test).
> *	For any other changes I ask that you first talk to me so
> that I can understand the potential impact the change
> presents. You may be asked to hold the change in your workspace or
> utilize a feature branch until after
> cougar beta or cougar GA.

No holding in workspaces, that doesn't really work.  The dev branch is
not the cougar branch. That said, the dev branch is not a
complete free-for-all either: if there is a software engineer not
working on Cougar, then something is already broken.  I'm 100% serious
about that last statement.  If they are already working on Cougar then
there is nothing more to say as you almost certainly already know at
least a small amount about it.  Escalations are in effect also about
Cougar as they are about bugs that likely affect the current branch as
well.  If they do not, then obviously they don't go into dev.

I've already seen too much hand waving and silence on this matter of
resources working on non-Cougar and non-escalations. I hear that we have
resources working on non-cougar development. This would seem to fly
directly into the face of the message that was beaten to death at the
all hands meeting.  I've already sent a note out about putting a stop
to the coverity work, but that's not the full extent of it.  There
can't be any reasonable justification for resources not working on
Cougar (working on Kegg) until Cougar ships, given the behavior of the
executives at the last all hands meeting.  The walk has to match the
talk.

> *	All changes must be tested and code reviewed. The code review
> must involve a discussion about how the change was tested.

Yes.

> beta_cg
> *	The cougar beta branch is restricted to fixes for cougar
> beta MF defects.

I wouldn't go that far.  Or perhaps I would go farther.  I would say:
only fixes approved by you (or some equivalent authority).  The end.  No
need to specify it any further than that.  The whole beta MF thing is
somewhat flawed anyway.  But that's a discussion for another day.

> This branch is currently the same as submittal 18.
> *	After fixing a beta MF defect a developer must:
> *	test the change
> *	complete a code review
> *	check the change into the dev branch
> *	integrate the change to a beta_cg branch workspace
> *	test the change
> *	notify me of the change. I will act as the reviewer for all
> checkins to the beta branch.

This is somewhat patronizing, and slightly out of order:

A developer must follow the usual process, which has not been followed
enough in the past, including checking the change into the dev branch if
it belongs there. Then, that developer has to get approval from you (or
some equivalent authority) to integrate it into the cougar branch, or
check it in there if it isn't going into the dev branch.  In essence,
no checkin should go into the cougar branch before you know all about
it and have approved that action.  Simple.

You are capable of reviewing any checkin at any time, so the part about
you being a reviewer is not necessary given the fact that the change
can't go into the branch w/o a go-ahead from you.
