RE: [stellation-res] Proposal: audited checkins

["Jonathan Gossage" <jgossage@xxxxxxxx>]

If you are going to implement this you should publish a list of primary and
secondary auditors for each functional area. The primary auditor should be
the person that has overall responsibility for the area and the secondary
auditor should have enough knowledge of the area to be able to evaluate the
patches submitted, including those prepared by the primary auditor.

Perhaps a section should be added to the Coding Guidelenes document to cover
this.

Regards

Jonathan

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: January 22, 2003 1:41 PM
> >To: Stellation-res
> >Subject: [stellation-res] Proposal: audited checkins
> >
> >
> >
> >
> >Since we're getting very close to the point where we start self-hosting,
> >it's getting increasingly important to be really careful about
> >handling changes, and making sure that the system is stable.
> >
> >I did some chatting with an IBMer who's a serious contributor to
> >Mozilla about how they handle changes, as well as looking at
> >a lot of literature and talking to various development folks. One
> >of the things that seems to come up again and again as a quality
> >management technique is audited checkins.
> >
> >What this means is that each change to the system must be seen
> >by *two* people before it gets checked in: the person who make the
> >change, and a second person who looked over the change before allowing
> >it to be checked in.
> >
> >The Mozilla process for this is based on Bugzilla. They require *all*
> >work to be entered into bugzilla tasks. When the work is completed, the
> >person who did it puts a patch containing the change into the bugzilla
> >task, and transfers the task to another developer. The other developer
> >applies the patch to a clean space, and checks it. If they approve it,
> >they check in the change; otherwise, they throw the bugzilla task back
> >to the developer with a description of the problem.
> >
> >It's somewhat cumbersome, but not too bad, since Eclipse has patch
> >generation and patch processing support.
> >
> >When we start self-hosting, a more stellation-appropriate version of
> >this emerges: you check changes in to your own branch; then have another
> >developer verify those changes, and do the actual checkin to the
> >main branch. In fact, we can even set up the privileges so that anyone
> >who wants to can create a personal branch where they can check in; but
> >only the official committers have permission to check those changes into
> >the main branch.
> >
> >I'd like to propose adopting this process, at least for a short
> >time. I think it will help us get better stability as we start
> >self-hosting and prepping for the release. If it works well, we can
> >adopt the Stellation-specific variant of it it as a longer term
> >process; if not, we can just abandon it.
> >
> >Opinions? Comments? Rotten tomatoes thrown at my head?
> >
> >	-Mark
> >
> >--
> >Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center
> >*** The Stellation project: Advanced SCM for Collaboration
> >***		http://www.eclipse.org/stellation
> >*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx
> >
> >
> >_______________________________________________
> >stellation-res mailing list
> >stellation-res@xxxxxxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/stellation-res