> (the mail is a bit long, so i will comment as i read).
> So far, we established a quite a bit new repositories at source.squeak.org
> /trunk
> /test
> /inbox
>
> lets say, all core packages, which is going to include into core image
> will be located in trunk repo.
> So far , do you see any contradiction with your model?
>   
You are missing a big point here... Take a good look at Step 0, see what
it doesn't specify... it doesnt actually specify the starting image. You
see the same iterative build process could be applied to a 3.9 image or
one of my existing production images. Ok it might not work as well as
the image for which it has been designed but it would be feasible. While
you can load a small change set into a number of images, I doubt you
could load a full MC package.

Where in the coded task steps does it say collect a kernel package (a
moving target) from a trunk repo? It doesn't, in our model the MC repo
packages are the output not the input. - see step 8. So the two
approaches are opposite in methodology.

If I write a mantis fix, I need for the image to be in a vaguely known
state at step 4. If prior to step 4 I load any packages from the trunk
repo then the image will not be in a fixed state for the application of
a fix from mantis. If I apply the trunk repo changes after the fixes,
then the repo package will stamp over the fixes.

We already have a repository for 311, it is called squeaksource.com/311
if you have the good fortune to reorganise a bit of kernel code into a
standalone module, that can be treated as virtually external to the
image, then fine. This can be loaded as a completed "external package"
at step 2 and it will need no further fixes. For example I think
"Object-Tracer" has been published as an "external" package.


> I may be wrong, but i don't see anything hazardous to your vision. Its
> a simply a common place where people putting their code.
>   
Sure if it was just a place to put "your" code, then it would be a
directory with a changeset, or a DS in it. But it isnt, it is a
repository with a whole package in it. Each trunk package represents an
incrementally developed moving target for anyone who wants to contribute.

With Andreas' model when I write my code I am not coding to a fixed
starting point, I am adding my code incrementally to whatever the last
person did. So we have everyone working to a moving target, and everyone
potentially stepping on each others toes.

With my model you pick a jurastiction and you work on coding your
project, you don't have to share your repo with others working on other
tasks.
> Later, Andreas shown how to work with it using Monticello configurations. Okay.
>   
Again, I dont see where this step is in the build plan. In the planned
approach you develop your code in the context of a fully populated
image, with all the tests present, and then when the whole thing works
you export the finished MC packages. Andreas' model is the opposite.

If you want to take a discrete chunk of the core and manage it
externally as a set of MC packages then be my guest. But then propose it
as a project and add your load task to the build plan. It becomes an
externally managed project that needs an integration task. But don't
just sumarily take the whole core and start maintaining it and managing
it in a separate place.

I am not saying that the updates idea is not useful, indeed this was
once the proposed plan. i.e. once you have designed and produced the
final image, we look to make different ways of distibuting the image,
and atomically loaded MC packages is one option.
>
> Instead, i think it just make things a little bit easier:
> a group of contributors could use a single place to put core packages there.
> They don't have to remember/know each package/changeset or source in
> other forms location(s).
>   
MC doesnt manage changesets, it doesnt manage the pieces of the work in
progress it only manages the final results.
>
> Well, if we want some kind of 'official' image, we can build it using
> your tools.
> And obviously, there should be someone who oversees this process and
> choosing what is going into image and what's not.
> Again: i don't see how this contradicts with 'old new' model.
>
>   
Thats not what Andreas is saying... he is saying "right we have this new
repo, and over the weekend I will integrate the 3.11 fixes into it."

The old new model gives a person a jurastiction, lets say they are
working on a particular fix. They continue to work on that fix,  and the
build system integrates it. There is no step in which it passes over to
the release team leader who choses to update the repo with it. That
would be taking the fix out  of the hands of the person responsible for
it, and bringing back the old bottleneck model.
> I think your work is relevant, and could bring us to a new level.
> But i can't force people to go read about it, or start using it and
> none of board members can.
>   
But you can do the simple stuff, like talking, like including relevant
people in discussions, like not pissing people off. In the immortal
words of Jeremy Clarkson "How hard can it be?"

Basically ask yourself who would want to work in these inter-personal
conditions?

Keith