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

[Andreas Raab]

Hi Igor -

This discussion is extremely frustrating for me because I have no idea 
what you are trying to achieve in it. It feels to me that you want to 
prove some particular point but I don't know what that point is. 
Consequently we end up discussing grotesque corner cases that won't ever 
occur in any practical situation (like your 1000 users example - do you 
really think that there wouldn't be 2 or 3 who'd work together to 
provide a unified stream?). And that's an utter waste of our time for 
both of us.

So, in short, what exactly is the point you are trying to make? And if 
you don't have any particular point, can we please move on to more 
relevant matters? This discussion has exhausted me.

Thanks,
   - Andreas


Igor Stasenko wrote:
> 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
>>
> 
> 
>