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

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

On Wed, 2003-02-12 at 11:25, Jonathan Gossage wrote:
> ----- 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.

Absolutely, plugins are one of the mechanisms we should support. I'd
love to see a sort of standard library of scripted behaviors for
different purposes, each packaged up as a plugin.

I'd also like to find a way to provide a simple, lightweight scripting
mechanism to allow people to attach scripts without all of the weight
and complexity of plugins.

I know I'm droning a bit here, but this is part of why I'm working
on setting up a MOO on our server. I think the idea of scriptable
objects and behaviors that define how users interact with repository
objects is going to be a critical piece of how we make stellation do
the things that we want to do, but I don't really think that we (or
at least I) understand well enough what the possibilities, the
stumbling blocks, and limits are. I'm hoping that by creating a
scriptable space, where can play with these ideas (even if it's
awkward because of the weak connection between the interaction space
and the repository) will help us better understand what we really
want/need.

	-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