Going for the Full Monti (Re: How to improve Squeak)

danielv at tx.technion.ac.il danielv at tx.technion.ac.il
Mon Jul 12 09:28:18 UTC 2004


I think to replace the BFAV-centric process, MC needs to deal with some
of the same, and some new concepts:
1. Instead of global "approvers", MC should let each user have a list of
"repos I monitor". Dougs list is the list of  "approvers".
2. In addition to existing concepts, we need "patch" or "change", which
aggregates some of the stuff an update does -
a. Set of specific changes to a package (or a few?)
b. Documentation of the change (as a change, besides code comments and
so forth)
People should be able to look at the list of patches in someones
repository, not just the code diffs compared to his version. People
should be able to take/reject/remove specific patches.
3. Bring attention to patches that deserve it. In the BFAV, this looks
like an item with reviews/testing comments. I don't know how this should
happen in the new scheme.

Ideas?

Daniel


Doug Way <dway at mailcan.com> wrote:
> Date: Mon, 12 Jul 2004 01:08:58 -0400
> From: Doug Way <dway at mailcan.com>
> Subject: Re: Going for the Full Monti (Re: How to improve Squeak)
> To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
> envelope-to: danielv at localhost
> delivery-date: Mon, 12 Jul 2004 11:19:05 +0300
> reply-to: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
> 
> 
> Off the top of my head this sounds like a good amount of work, and I 
> don't want to get stuck doing most or even half of it. ;)  But it may 
> be the right thing to do.
> 
> I guess we should brainstorm a bit on how this might work before making 
> a decision, of course.  Erm, would the "image" be a giant single 
> package in Monticello?  Or at least the part of the basic image which 
> is not already split into other packages... which would still be a 
> pretty giant package at this point.
> 
> And then how would the update stream fit into this, if at all.  It 
> would appear that the core committers would not need an update stream, 
> at least.  Maybe there would still be an update stream for the "public" 
> alpha image somehow.
> 
> - Doug
> 
> 
> On Sunday, July 11, 2004, at 07:25 PM, goran.krampe at bluefish.se wrote:
> 
> > Hi people!
> >
> > Marcus Denker <denker at iam.unibe.ch> wrote:
> >> To come back to the example: Don't forget that we strike for a "fast
> >> moving agile" process.
> >
> > Yes, and I think we should really sit down and try to set up Monticello
> > for managing the image. Avi has already done some experiments. Then we
> > should of course have limited "commit" access to that.
> >
> > This way we can have BFAV for the contributions coming in (like patches
> > in other open source projects) and we can go straight to Monticello for
> > other stuff.
> >
> > Such a model would help A LOT I think but it will demand two things of
> > developers with such commit access:
> >
> > 1. Test it locally first. Don't commit stuff that is half baked. This 
> > is
> > basic stuff for working in an open source project of course. In the
> > Mozilla project they say that the "tree is on fire" when someone does
> > that.
> >
> > 2. Write proper commit notes (= commit comment in CVS). Those will be
> > critical in knowing what has been done and for us to be able to produce
> > ChangeLogs.
> >
> > I think perhaps if we do this step first - then we can more easily pick
> > up the TFNR goals again. It will be easier to perform those things when
> > we have a "full Monticello" working.
> >
> > Avi? Comments? Is Monticello up to the task? :)
> >
> > regards, Gsran
> >



More information about the Squeak-dev mailing list