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

[Igor Stasenko]

2009/7/9 Igor Stasenko <siguctua at gmail.com>:
> 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.
>

And btw, this is nearly same ridiculous for 10-20 developers who doing
the same simueltaneously.
There should be 1-2 people who needs to get work done, while rest should wait.
So, as you see, even for core-devs group (which we currently forming,
btw), an automatic updates having same flaws in this regard.

>> 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.