[squeak-dev] Re: [Release] The role of Bob, Installer & Co.

[Matthew Fulmer]

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/