On Sun, Jul 05, 2009 at 01:58:24AM +0100, Keith Hodges wrote:
> 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?

I have made the code available. Any other fork can quickly and
easily see and load just my changes by pressing the MERGE
button, if Monticello were being used properly, which it isn't.

> Who knows what your starting point was?

It's called ancestors in MC

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

anybody who presses the merge botton

> Who has any opportunity to comment and provide feedback on what you have
> done in the context of what you have done.

anybody on the mantis page related to the code I just added to
monticello

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

Peer review happens after the code exists, not before. I would
then announce my change on mantis and ask for comments, say if
the bug is fixed, and note any problems I anticipate.

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

Which fixes. Why should I care? I want all the fixes. I want
everything to work right. Thats why I upgraded from Squeak 1.1. 

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

Of course. SqueakSource is not the image. the image is not
squeaksource. The image is built from the best working subset of
the code in squeaksource, by loading a known-working version
that has passed some review standards and been nicely released
and packaged and published somewhere other than squeaksource,
such as squeakmap, universes, or Packages, or .mcm.

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

Of course not.

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

yes.

> MC is a tool for managing code, but it doesnt have any means for
> providing feedback, 

nor should it.

> it is not a tool for managing fixes. 

nor should it be.

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

Wrong. the discussion continues. I announce that the fix is
ready in monticello, ask people to load and test it, and they
review it.

> It also possibly breaks another fix that someone submitted ages
> ago.

Hopefully that comes up in testing, and it will be noted in
mantis.

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

This is bogus. if it worked last time and it doesn't this time,
the problem is obvious. One of the small set of new changes that
got added in the few hours since bob tried last. Bob knows what
those changes are, and so does everybody else, because bob
watches the repository and lists what's new in his report.

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

The image is far too course an entity to patch against. I don't
want to fix squeak or pharo. I want to make Rio-1.2.29 better
than Rio 1.2.28. 

Any project should be able to understand which versions of
packages it can afford to upgrade and which it can't. Changing
the core from underneath a project is never a great idea.
upgrading it's support libraries thru Universes or Packages
often is.

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

I don't want to take Mantis out of the equation. If I did, that
just means I don't care about the community.

> > We have a great tool already for keeping track of code that has
> > changed. 
> Yes changed in one image.

One package

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

of course it's not a bug tracker.

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

everything is a package, whether it is unloadable or not. There
will be one big one called the kernel. This should be versioned
like any other package. Linux has Linux 2.6, glibc 2.8, gcc 4.4,
and X.org 7.2. Thinking in terms of the image is just plain
wrong.

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