Hmm. What keith is saying is something I wrote, with his help, 9
months ago: http://installer.pbworks.com/Squeak311Proposal

I have to decide if I still agree with that proposal we came up
with. My arguments below seem to indicate that I find serious
flaws in it now. 

On Sat, Jul 04, 2009 at 07:15:57PM -0400, Matthew Fulmer wrote:
> On Sat, Jul 04, 2009 at 11:42:31PM +0100, Keith Hodges wrote:
> > Before:
> > 
> > The procedure for 3.10 was - upload your fix to mantis and it will be
> > integrated by the build server whose name used to be Edgar, but is now
> > Bob. i.e. there were 2 inputs.
> > 
> > 1. the design of the image (which for 3.10 included the removal of a
> > couple of packages)
> > 2. the fixes from mantis integrated manually.
> > 
> > After Bob:
> > 
> > 1. the design of the image, a task which loads the latest packages,
> > reorganises the whole image into a DIFFERENT package structure. (how are
> > you going to support that with mcms?)
> > 2. the fixes from mantis integrated automatically.
> > 
> > Your scheme:
> > 
> > 1. People can contribute to trunk...
> > 2. there is no image design because bob is not building images anymore.
> 
> Bob does not "design images". neither do you
> 
> > 3. People can contribute to mantis and those fixes get integrated into
> > trunk as you go along. So in your scheme the mantis fixes are now being
> > applied to a moving target. Which means that other people who want to
> > see what good a fix is for to see if it might be useful to them, have no
> > idea what state 3.11 trunk was in when the fix was added to it.
> 
> You want every contribution to have to flow thru the bottleneck
> of mantis? So, instead of
> 
> 1. fix a bug
> 2. merge in any changes that may have happened since I started
> 3. press save in Monticello
> 
> You want us to
> 
> 1. fix a bug
> 2. file out a changeset
> 3. Grab the latest image from Bob
> 4. Reaply the changeset to that image, making sure it works
> 5. upload that changeset to mantis5.
> 
> We have a great tool already for keeping track of code that has
> changed. It's called Monticello. You use it all the time. Bob
> can load .mcm or .mcz packages into an image just as easily as
> it can load changesets from mantis.
> 
> Bob is not a taskmaster who controls the image, demeaning our
> jobs to just submitting changesets for his approval. We, the
> community, build the image, and bob relieves us of the drudgery
> of making sure the packages load order is reproducable, and from
> waiting 5 hours for the unit tests to finish.
> 
> > So basically the whole commit to trunk idea is not tenable.. for the
> > following reasons.
> > 
> > 1. There is no design of the final image published and coded in advance.
> > It is now a free for all for the committers that have been let loose on
> > trunk
> 
> if there was a final image published and coded in advance, there
> would be no reason to be bothering about a release, since it had
> already happened. This makes no sense.
> 
> > 2. The packages are going to be reorganised in the process of the image
> > design.
> 
> they are? first I've heard about it.
> 
> > a) "System" needs to be broken up
> > b) The Implementation and Tests need to be logically and tidily
> > organsied for once.
> 
> Bob is not going to do that. We are.
> 
> -- 
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> 

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/