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

[Igor Stasenko]

2009/7/9 Andreas Raab <andreas.raab at gmx.de>:
> 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.
>

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.

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



-- 
Best regards,
Igor Stasenko AKA sig.