[Release] Philosophical Discussion - The updates button is useless - discuss

Keith Hodges keith_hodges at yahoo.co.uk
Fri Jul 10 04:02:19 UTC 2009


Andreas Raab wrote:
> Igor Stasenko wrote:
>> I tried to show how Sake/Tasks could be used as in an 'update stream'
>> fashion. Mainly: a group of developers
>> providing a number of contributions in various set of
>> packages/changesets/other forms, and then package Czar makes them
>> available for a 'single-click' update through (re)writing a loader
>> configuration. So, all what MC does for us is (re)loads this
>> configuration and then running it. The rest is determined by this
>> config - written by Czar: what you need to load, in what order, what
>> need remove or what to add etc.
>> This is much more flexible, i think, than using MCM configurations.
>> But if i'm wrong - please correct me.
>
> My main issue with this discussion is that you're discussing it as if
> our main problem were lack of flexibility in the update process. But
> that's not the problem we're having - the problem we're having is that
> we had no functioning update process whatsoever!
I once attended an undergraduate workshop in which teams were each given
a pile of jigsaw pieces. However the adjudicator did say that we
determined what the rules of the exercise were. After a lot of time, we
realised that this meant that we got to decide what was relevant or not
in the exercise. We could decide not to bother with the jigsaw pieces
and we could all go for a beer.

So, not having a functioning updates mechanism is not a problem at all,
that is a solution, that is a big step forward.

One of the identified problems with the current development process is
that the "updates" mechanism gives rise to incremental development, an
ever increasing image, a moving target for really useful developments, a
bottleneck in the guru approving process, and a limited ability to go
back and fix something after the fact. So we made a philosophical choice
to ditch the updates mechanism.

Now your mcm updates mechanism may be better than the older changesets
updates mechanism, and it looks like it might be useful for image
syncing between a development image and a server.

So I am sorry to say that this means we need to move the image forward
the hard way. That being to recuit volunteers to actually work on a
subsystem as a substancial project whose integration can be roadmapped,
rather than inviting all and sundry to commit to my image.

Keith



More information about the Release mailing list