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

[Andreas Raab]

Keith Hodges wrote:
> 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.

Great idea, I think you should have that beer. While you're having it 
the rest of us can solve the update puzzle. Obviously you have no 
interest in the problem, so why don't you leave it to people who'd like 
to solve it? Your non-constructive role in this discussion is not 
appreciated.

Thanks,
   - Andreas
> 
> 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
> 
> _______________________________________________
> Release mailing list
> Release at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/release
>