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

[Igor Stasenko]

2009/7/9 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>
>> 2009/7/8 Andreas Raab <andreas.raab at gmx.de>:
>>>
>>> I think that the closest we can come in practice to such behavior is
>>> merging. Since the MCM updates are merges, you get that precise behavior
>>> when using multiple repositories. In other words, if there were a
>>> conflict
>>> in the updates to 3.11 and Seaside 2.9 the update process would open a
>>> merge
>>> browser and leave it to you to decide what exactly you want to do with
>>> it.
>>
>> Yes, but at this point you are already failed. Because you turned
>> something as simple as clicking an 'update' button
>> into an engineering task for end user.
>
> Hardly. You have been driving the discussion into ever more obscure
> situations without offering any answer whatsoever yourself. Up until the
> point where you were asking about conflicting updates from different
> sources, there was no need for any user interaction. If you are claiming
> that you have some "clever tool" that can automagically merge conflicting
> code, then please put up or shut up. Because this discussion is really
> getting silly and I'm running out of patience quickly.
>
No offense :)
I just wanted to illustrate, the limits of update stream(s), mainly
for developers and maintainers.
I don't think that we need a situations, like when 1000 users by
pressing 'update'  get riddled with opening a merge tool which
proposes them to stop working on their own task(s) and bravely start
merging conflicts. This is simply ridiculous.

> As soon as you realize that you can't automagically merge conflicting
> updates, having the merge tool is the answer: Allow someone to provide a
> merged set of updates and (instead of subscribing to each stream
> individually) subscribe to the merged stream. Problem solved.
>
Right, there should be a wizard(s) , who doing hard work, so clicking
an 'update' can be kept magically simple operation.

But i am also concerned with following:
by taking an example above, when we having a three update streams:
- 3.11
- Seaside
- MyStuff

and suppose, a new version of 3.11 includes an updates A, B, C (quite
independant, so they can be loaded unordered).
But update A conflicts with Seaside, and update B conflicts with MyStuff.
So, while engineers in Seaside team working hard on merging the update
A, and other group of engineers working hard on merging the update B,
they still may want to allow end users to load update C.
That, what we call 'cherry-picking'. And i would really like it to be
enabled at some stage of our non-ideal tools/workflow evolution.

> Cheers,
>  - Andreas
> _______________________________________________
> Release mailing list
> Release at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/release
>



-- 
Best regards,
Igor Stasenko AKA sig.