On Mon, 13 Mar 2006 11:59:16 -0800, Andreas Raab <andreas.raab at gmx.de>
wrote:

>Um ... I might be slow or something but can you explain to me again how 
>this makes things simpler/easier/whatever? Where is (in terms of pain 
>associated with it) the difference between having that MCC map and 
>posting it to an update stream? (unless you don't do it at all ;-)
>
Well... in the update stream, you need to take care about load order,
about conversion scripts, stuff like that. Just a map won't be enough
to upgrade X to Y. For example, loading your UI work (ToolBuilder
etcetera) was relatively easy, not in the least because it was
well-prepared and well-documented. Loading it in a way that was
perfectly reproducable in an automatic way (ie "scriptable") took
quite a bit of time, it had to be split up over multiple update stream
versions, so it was a general pain to take that extra step.

>Nice try. You know just as well as I do that this ain't gonna happen ;-) 

It depends. Personally, I don't think it is fair to burden the release
team with lots of work that maybe only others care about. That's why
I'm trying to find a process (and - remember the original mail -
implement that in 3.10) that minimizes the burden on the package and
especially release teams. If people complain that this won't satisfy
their crave for software archeology, let them step up and do something
about it (yup, exaggerating there - the points you point out are valid
but are they important enough?).

Anyway, I'm not married to the specifics of my proposal - I feel the
idea to implement the process is important, but how the technical
details turn out bothers me less, as long as the decision framework is
to err on the side of making life of the team members easy. 

As far quality - there are many ways to ensure quality, an easy
overview of changes to the image is just one of them. It is another
thing we chatted on in Brussels (I don't mention with whom - it might
give the wrong impression that they're backing any of this ;-)). We
need to be more quality-conscious (for starters, we MUST - yes, that's
the RFC "MUST" - have all-green unit tests in every released image).
However, if the process+tools eats up all the time just to get stuff
done, there's nothing left to do about quality. In that case, it's
probably better to drop some functionality and buy time in exchange.