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

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: "Stellation-res" <stellation-res@xxxxxxxxxxxxxxx>
Sent: Wednesday, February 12, 2003 10:07 AM
Subject: Re: [stellation-res] Proposed Changes in Bugzilla (#31581 )


> 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

If we go this route (which I like), would you consider the behaviour, which
could be encapsulated in behaviourable objects) as Stellation plugins. It
would be very powerful to be able to attach arbitrary but type-safe
behaviour to individual objects  within Stellation. It would mean though
that we would need a very well thought-out mechanism to prevent either
inadvertent or malicious damage to the repository or to the running instance
of the repository server.

Regards

Jonathan