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

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

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

I'm not sure that I agree here, although it may come down to the
definition of scripting language. For many of the kinds of things
that I expect to be useful in scripted behaviours, I can write them
much more quickly and easily in Scheme or Python than I can in Java. 
Many people would argue that Scheme and Python are not scripting
languages. But when used as scripts, they are quite different from Java,
and a whole lot more convenient to use for quick scripts.

If I want to say "reject a change if the approvals property has less
than two signatures", I can do that in two or three lines of Python. In
Java, it becomes much messier. 

Obviously, we want to be able to write behaviors in Java. We're a Java
system, and that's a natural and important way to do it. But to me, the
important question is, is that enough? Is forcing people to use Java
going to discourage people from writing simple behaviors? Can we provide
a lighter-weight way of writing simple scripts that is more amenable
to simple tasks?

I find things like BeanShell and Jython fairly compelling, at least as
something to consider.


> 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?
> 

Eclipse plugins are kind of heavy in several ways. But basically, it
comes down to two things: the process of building and deploying a
plugin; and the fact that because they're designed to provide a 
strong heavyweight component model, plugins are ultimately *static*
entities.

If I want to add a piece of behavior to my private branch, I don't
want to have to shut down my server, install a plugin, and then
restart.  With Eclipse plugins, that's how it works:the plugin graph is
computed at startup time. 

I also don't want to have to be mucking about with plugin.xml files,
PDE plugin editors, etc., just to add a simple bit of behavior to the
system. 

	-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