About MC for managing the image
Daniel Vainsencher
daniel.vainsencher at gmail.com
Sun Sep 18 18:57:33 UTC 2005
stéphane ducasse wrote:
> So if I understand correctly this means that to arrive to version x, we
> have to load all the configs (hence the MC
> deltas to speed up the process) until we load version x.
This is important in order to be able to do changes that require
specific intermediate steps, exactly like what is planned for the entry
of Traits into 3.9a.
> I guess that
> this is the set up done at impara to manage iSqueak
> and Tweak. Bert is it correct?
>
> Now this means that this is really tedious to have to
> - define
> - validate
> - a load order for all the packages
> - publish a new cs on the update stream
> - publish a new image
>
> The implications with this setup is that we have to produce often an
> image (validate a configuration
> of changes working together) and this can be quite painful. At least
> they are a lot of try and error
> when there are a lot of dependencies between packages.
About creating the cs and new image - this should probably be automated.
Something like
"write cs describing current image, get the last published image, load
updates, save new image to web space".
I don't understand why the load order is necessary and what trial and
error comes out of that.
But maybe Avi's response solves that part of the problem.
A couple of notes and proposals of my own -
1. I think one way to make you lives easier is to try to use only MC as
much as possible. Tell people you accept only mcz/mcd files, for the
existing packages. This will take time, but it will mean that people
will think about their changes and what they affect, and its one less
thing for you to figure out. If you get a CS, do you go over it manually
and check that methods are marked as extensions where needed? if you
require package versions, people are likelier to think of that themselves.
2. Use proper repositories, not Mantis. Mantis can contain a link to an
mcz file in a repository, that is as easy for you to use as an
attachment. But it helps accountability, because then anyone can get the
original submitted version and inspect it. So tell people to put their
versions up on source.squeakfoundation.org/inbox or to create themselves
an account a personal project there, and then put up all their proposed
changes as mcz files.
3. Tell everyone that care about maintaining the image to register for
the sources.squeakfoundation.org RSS feed (I just found out about this).
That way they get notified for every version that gets put out. That way
people see what changes are proposed, and there's a better chance that
good changes will be endorsed/extended, and bad changes will be seen and
commented on. This is now the equivalent of reading the BFAV, except you
can do it from Thunderbird.
This policy direction of moving towards using MC and SqS more
exclusively for the management of the image are good because:
1. The current hybrid policy is too complex (as seen for example by the
confusion caused by looking in changesets for traceability)
2. We can improve the MC tools to improve the image maintenance process.
For example, we can make one repository inspector that shows quickly all
the new versions of everything that people suggest, and then harvesting
will become easier in that way too.
Daniel
More information about the Packages
mailing list