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 11:36 AM
Subject: Re: [stellation-res] Proposed Changes in Bugzilla (#31581 )


> 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
>
I strongly agree that a light-weight way of "scripting" behaviour is
desirable, however I have yet to see a scripting language that did not feel
as "heavy-weight" as writing the behaviour in a full fledged programming
language. I personally feel that the way to get "light-weight" programming
is via a really good API plus a set of, currently non-existent tools that
can automate the writing of common idioms below the method or function
level.

BTW when you talk of Eclipse plugins as "heavy-weight" are you thinking of
the writing of the plugin, the deployment or both. Is it possible that what
we need is a simpler method of injecting custom behaviour into the system?

Regards

Jonathan