[Release] Proposal

[Igor Stasenko]

2009/7/8 Edgar J. De Cleene <edgardec2001 at yahoo.com.ar>:
>
>
>
> On 7/8/09 10:18 AM, "Keith Hodges" <keith_hodges at yahoo.co.uk> wrote:
>
>> Edgar J. De Cleene wrote:
>>>
>>> On 7/8/09 5:51 AM, "Keith Hodges" <keith_hodges at yahoo.co.uk> wrote:
>>>
>>>
>>>> and you can leave the unloading until later.
>>>>
>>> So we continue in the same point as two years ago.
>>> Or we cooperate,
>> Dear Edgar I have been inviting you to co-operate for over two years.
>>>  or we do each own fork.
>>>
>>> I have mine working ...
>>>
>> Which is useful to you but not to anyone else. If you were to take your
>> knowledge an put it in a place that it is useful to others too, that
>> would be great. For example I attempted to take your knowledge on how to
>> unload Nebraska and I added it to Sake/Packages.
>>
>> Sake/Packages allows us to define clearly what works where, and what is
>> needed to unload things from where.
>> If you load Sake/Packages with Installer install: 'Packages' you can
>> look for senders of #unload:
>>> What part of hitting the load updates button for any squeaker could see his
>>> number changes from nnnn to higher
>> Why would any squeaker want to push the updates button and have
>> something that they didn't want to happen happen? You cant just unload
>> packages from someone's image using the updates button. Why not let the
>> user choose what happens to their image?
>>>  and some fixes and enhancement goes to
>>> his/her image your disagree ?
>>>
>> Totally disagree. We want to write down a clear specification and design
>> of what the release is to look like and to deliver that deliverable. The
>> updates button, puts everyones image into an uncertain state, and there
>> is no going back.
>>
>> Squeak is in such a mess that we need to take parts, break them and
>> remake them. For example, removing RemoteString and replaceing changes
>> and changesets is an engineering task, that needs to be planned
>> implemented and executed. It is not possible using the updates button,
>> so please lets just retire the updates button as a non starter.
>>
>> I have never ever used the updates button before, and I don't see that
>> it has any use, apart from potentially breaking an image.
>>
>> Keith
>> _______________________________________________
>> Release mailing list
>> Release at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/release
>
> Well  you should do your own fork like me and let people use it or not.
>
>

Edgar, please, be rational. Why a release team member should start new
fork, while working on squeak 'official' release?
If Keith going to resign from release team, then he is free to do
anything he likes to, but until that, a proposals like yours makes
little sense.

Besides, i see nothing wrong with 'update' button.
I think Keith could wire any action/sake task on this button which
could do similar thing: blindly go trough all installed (or listed in
task) packages and load a newest versions of them.

Moreover, since Sake allows to define as many tasks as you want to,
which in simplified view - much the same as an update stream (tast
defines different flavor of base image), he could wire this button and
propose user a selection, on which 'update steam' he wants to
subscribe, and even choose which concrete packages he want to see up
to date.
But this would require writing some UI code.

So, as you can see, there are little needed to be more inclusive &
find compromises - just turn on your mind and think in that direction.

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



-- 
Best regards,
Igor Stasenko AKA sig.