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
>   
I write a task which specifies in code what the design of the output
image is to be. What packages are loaded what packages are unloaded and
what classes are in which package. After that it is merely a process of
filling in the steps of the design, of which "apply fixes" is one step
which tends to appear in every iteration, just as deprecateAPI and
update version number.

Building the image is the bit that needs automating, because most of it
is the same every time. If we want to release early and often, then we
automate the building of the image. The only things that change are the
selection of which packages are included and the selection of which bugs
fixes to apply.

Bob relentlessly and ignorantly applies this task until it happens to
work, if all tests pass then in theory you can ding the extreme release
bell.
>> 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?
Abso-bloody-lutely.

Unless it is an externally managed package.

Or it is a specific project (e.g. migrate image to use closures) whose
result is specified as a task (changesets/DS/scripts or MC packages to
merge) that bob can reliably apply.
>  So, instead of
>
> 1. fix a bug
> 2. merge in any changes that may have happened since I started
> 3. press save in Monticello
>   
And you have helped anyone but yourself or your own fork how?

Who knows what your starting point was?
Who knows or records what exactly you did?  (ok mc does, but I mean in a
way that other people can use in their images)
Who has any opportunity to comment and provide feedback on what you have
done in the context of what you have done.
You are a law unto yourself, and there is no pier review taking place.
Your actions are not repeatable, nor are they undoable, because by the
time you want to undo them, someone else will have merged in your change
to their latest.
Your result cannot be used by anyone else until the release is
published. But we want projects to be able to happen in parralel, these
projects need to be able to pick up the fixes that they need. When a
project is published as a task, it specifies the fixes it needs as
prerequisites.

Your steps are describing the sort of process that you are used to when
you are hacking away at your own code. When we build an image we are not
hacking, we are carefully constructing pre-specified result out of
(hopefully) carefully crafted and documented pieces.

Making trunk open to all committers is saying come on in lets have a
hack fest, this is nothing to do with building a release image.

You can do your hacking in your own time, hack away all you like at the
image, use monticello to manage your code, but when you have the result
you desire you need to find a way to publish it as one of those "well
crafted and documented pieces" I just mentioned. If changesets dont
float your boat then you might have to wait for DS. But MC is no good at
publishing a specific change for someone to load into a 3.8 image, and
it does nothing to document of capture the knowledge or design intent of
what exactly transpired.
> You want us to
>
> 1. fix a bug
> 2. file out a changeset
> 3. Grab the latest image from Bob
>   
No need, use your own starting image, you are working to a known fixed
point remember. 3.10.2 or more sensibly 3.10.2-build (since that is what
bob is starting with on every run)
> 4. Reaply the changeset to that image, making sure it works
>   
Bob will apply the fix to bob's images, and hopefully testing will
reveal if there are any conflicts when the fix is integrated with other
fixes.
> 5. upload that changeset to mantis5.
>   
Yes, because mantis is a tool for discussing fixes and having that
dialog. That's what it is designed for.
MC is a tool for managing code, but it doesnt have any means for
providing feedback, it is not a tool for managing fixes. Once you commit
a fix from mantis to MC it is out of mantis' hands discussion is over,
the code then slips under the radar, it merges into the blur of the
package. It also possibly breaks another fix that someone submitted ages
ago.

Fixes that are on the table for integration into a release should remain
on the table until the release is tested and out of the door.
If a test fails, bob could automatically apply the fixes one by one to
find out what caused the problem, he could reorder the application of
the fixes, or try different combinations, or a binary search to find the
problem.

It is also tied to the image you are using. When you use mantis to
publish a fix you are also publishing your fix for ALL forks of squeak
to adopt. A fix could be tagged as "Applies to Squeak 3.8" "Applies to
Gjallar0.1" so that people can pick it up for their own projects that
are unfortunately not able to track the latest image (i.e. most projects
out there of any size)

If you take mantis out of the equation you are not performing bug fixing
you are doing coding, and if you are doing coding you might as well go
off and spend a month rewriting the whole pacakge properly in order to
give the community something really cool to integerate and use when you
are done.
> We have a great tool already for keeping track of code that has
> changed. 
Yes changed in one image.
> 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.
>   
Sure you can, but Monticello is not a bug tracker. In this case we are
applying bug fixes and discussing them.

If you have decided that a package is to be managed externally, e.g.
Network, then you might want to perform a radical refactoring or a
redesign. Then you are coding and for coding a code management tool is a
good move. We are not interested in what you do to Network until you
have finished, in which case being an externally managed package we
simply load the latest Network as the second step in the release that is
due to adopt it. The first step would be to load any fixes needed in
order to load it, but hopefully you thought about backwards
compatability when you published and that shouldn't be a problem.

to be contd.

Keith