Re: [stellation-res] Proposed Changes in Bugzilla (#31581 )

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Tue, 2003-02-11 at 15:28, Jonathan Gossage wrote:
> ----- Original Message -----
> From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
> To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
> Sent: Tuesday, February 11, 2003 2:50 PM
> Subject: Re: [stellation-res] Proposed Changes in Bugzilla (#31581 )
> 
> 
> > I have one major request involving this. There are two distinct changes
> > captured in this: a rewrite of the build file, and the bugfixes. I'd
> > really like to keep distinct changes distinct. So what I'd like to see
> > for this (and for other future changes) is a separate bugzilla notice
> > for each change, and thus separate patches. It's a bit of a pain, but
> > it makes for much better tracking of the development of the system,
> > and it makes it much easier on the auditor, to know exactly what they're
> > looking at.
> >
> > -Mark
> >
> This should become a lot easier when we get to use Stellation shouldn't it?
> Incidentally, this suggests a possible enhancement to Stellation to better
> support the audit process. If we added a capability to prevent checkins to
> main without the authorization of some configurable number of committers we
> could ensure that nothing gets into the main line without approval.
> Thoughts?

It should get somewhat easier, but it will still take some discipline
from the committers. The way it will work most easily is to have a
branch for each bugzilla report. The branch contains the changes
corresponding to that bug. You'll still need to do some work to make
sure you're living in the right branch for the work you're doing.

For your idea about managing approvals... That's exactly the kind of
thing that I'd like to do, and it is related to my musings about
MOO-like facilities.

It's possible to do that, once a few gaps get filled in.

Right now, there is a facility called "Triggers" that's been programmed
into the core, but we have not yet exposed it in a useful way. What
you're proposing is a way of using triggers. A trigger is a programmed
script that runs either before or after a key repository operation. What
you want is a trigger that runs before checkin on the main branch, and
looks for approvals.

The two main gaps that need to be filled to make that work are:
- the ability to attach metadata, including mutable state, to a branch.
  (right now, the metadata facilities are only provided for artifacts.)
- the ability to register trigger scripts.

With that much, it could be done. The one awkward part is that you'd
be attaching the trigger to the checkin operation, and it would run
on *all* checkins, so you would need to explicitly check if the checkin
was to the main branch.

What would be even better is the ability to attach not just metadata
but behaviour to repository objects, including both artifacts and
branches (and projects, and ...) And then use *that*. That's where we
start getting close to the MOO again.

	-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