Keith Hodges wrote:
You really dont get it do you...
I think that's pretty obvious by now, isn't it. What I'm trying to do is to enable developers to work together. I can't possibly imagine why anyone would be so violently against that, so clearly I'm not getting the point.
I think our main practical difference is that you "abso-bloody-lutely" want people to go through Mantis. Which is okay, you can use Mantis for anything you'd like. But I myself, and other developers who understand the MC workflow, would rather collaborate that way. If Bob can't support workflows that use collaboration through shared MC repositories then it's not suited for the task of image building. And if it does support these workflows, then I don't understand why we're even having this discussion.
Cheers, - Andreas
Andreas Raab wrote:
Keith Hodges wrote:
You really dont get it do you...
I think that's pretty obvious by now, isn't it. What I'm trying to do is to enable developers to work together. I can't possibly imagine why anyone would be so violently against that, so clearly I'm not getting the point. I think our main practical difference is that you "abso-bloody-lutely" want people to go through Mantis. Which is okay, you can use Mantis for anything you'd like. But I myself, and other developers who understand the MC workflow, would rather collaborate that way. If Bob can't support workflows that use collaboration through shared MC repositories then it's not suited for the task of image building. And if it does support these workflows, then I don't understand why we're even having this discussion.
Cheers,
- Andreas
You can do the workflows any where you like. Specify a project, make a repo for that project and get on with it. For example a project to replace changes/sources with something better/cleaner. But you dont want the person doing that project to be working in the same repo as someone else whose project is to integrate rio. These are separate initiatives, done external to the release effort, and integrated as external packages + integration patches.
You have to decide what it is you are going to do, and specify a project to do it. Specify the deliverables the documentation and the outputs in such a way as they can be picked up by the automatic builder.
You are not capturing the knowledge of what you are doing to achieve what end. Simply because you aren't specifying any goals, nor any deliverables. Sure you can work in your repositories, but please ensure that every innovation you make is packaged, documented, and available individually in a manner that can be peer reviewed, automatically tested in all squeak forks and derived images.
The purpose of 3.11 is to develop a tool chain that promotes interchange and commonality between forks.
i.e. someone using a 3.8 etoys image can ask the question... "I see someone over there working on Rio integration, what would happen if I applied their rio integration task to my 3.8 based etoys image."
As soon as you have two innovations contained in the one repository you have a difficulty testing just one of them or offering that innovation to someone else in another image.
am I making any sense?
Keith
I take the Squeak3.10-7159-basic.image, do the first pass to rip
* Tests- * SMLoader * SMBase * Sunit * SUnitGUI * ScriptLoader * Universes * Installer * XML-Parser * MorphicExtras-Demo * Morphic-CandidatesForGo * Nebraska
All this could be loaded again with new versions from SqueakSource.
* EToys
I do my line between Morphic and Etoys, have success reloading and have partial success loading old Etoys .pr as some of you could read in dev list.
If VPRI people and others help me, we could have a OLPC Etoys .pr loading. Maybe is rough and not the best way, but we can't continue forever as we are now.
See the http://ftp.squeak.org/various_images/SqueakLight/Squeak3.11alpha.7160.zip
I do not put any wild coming from SqueakLight, give to all a new point to all contribute, disagree, complaint but please...
Fellows Squeaker, no more OnlyTalk, do Smalltalk.
Edgar
Edgar -
You're my hero! ;-) Please go for it. If I can help you, in particular with those frustrating MC loading issues please let me know and I will. I completely agree that we need to move forward on these issues.
Cheers, - Andreas
Edgar J. De Cleene wrote:
I take the Squeak3.10-7159-basic.image, do the first pass to rip
* Tests- * SMLoader * SMBase * Sunit * SUnitGUI * ScriptLoader * Universes * Installer * XML-Parser * MorphicExtras-Demo * Morphic-CandidatesForGo * Nebraska
All this could be loaded again with new versions from SqueakSource.
- EToys
I do my line between Morphic and Etoys, have success reloading and have partial success loading old Etoys .pr as some of you could read in dev list.
If VPRI people and others help me, we could have a OLPC Etoys .pr loading. Maybe is rough and not the best way, but we can't continue forever as we are now.
See the http://ftp.squeak.org/various_images/SqueakLight/Squeak3.11alpha.7160.zip
I do not put any wild coming from SqueakLight, give to all a new point to all contribute, disagree, complaint but please...
Fellows Squeaker, no more OnlyTalk, do Smalltalk.
Edgar
Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
On 7/7/09 10:35 PM, "Andreas Raab" andreas.raab@gmx.de wrote:
Edgar -
You're my hero! ;-) Please go for it. If I can help you, in particular with those frustrating MC loading issues please let me know and I will. I completely agree that we need to move forward on these issues.
Cheers,
- Andreas
Ok, move the image to 3.11 folder ( I see if I have right to do or send notice to Ken) As I see, you proposal was doing some similar to Ralph and me do, but better. If Bob works , we could try tested fixes and enh go to updates folder in fake .cs for people could see his number moves from 7160 to higher ones,
This is a important psychological issue. Next step , for Morphic easy updates and refactoring is move all Morphic I have in http://www.squeaksource.com/Ladrillos to trunk
Like
Morphic-Components-edc.1.mcz Morphic-Demo-edc.1.mcz Morphic-Events-edc.1.mcz Morphic-Explorer-edc.1.mcz Morphic-FileList-edc.1.mcz Morphic-Kernel-edc.1.mcz Morphic-Layouts-edc.1.mcz Morphic-Menus-edc.1.mcz Morphic-Pluggable Widgets-edc.1.mcz Morphic-Refactoring Candidates-edc.1.mcz Morphic-Scripting-edc.1.mcz Morphic-Support-edc.1.mcz Morphic-Text Support-edc.1.mcz Morphic-TrueType-edc.1.mcz Morphic-Widgets-edc.1.mcz Morphic-Windows-edc.1.mcz Morphic-Worlds-edc.1.mcz
Etc.
See the dates, coming from 3.10 beta , maybe same image you point as starting. Doing the MCM from this could be easier.
Divide and conquer the Morphic Monster :=)
Edgar
Andreas Raab wrote:
Edgar -
You're my hero! ;-) Please go for it. If I can help you, in particular with those frustrating MC loading issues please let me know and I will. I completely agree that we need to move forward on these issues.
Cheers,
- Andreas
Edgar J. De Cleene wrote:
I take the Squeak3.10-7159-basic.image, do the first pass to rip
* Tests- * SMLoader * SMBase * Sunit * SUnitGUI * ScriptLoader * Universes * Installer * XML-Parser * MorphicExtras-Demo * Morphic-CandidatesForGo * Nebraska
To acheive this all you need to do is to load the new versions from squeaksource.com then, if the packages are correctly defined they are unloadable, and you can leave the unloading until later.
This work has mostly been done, you are duplicating effort.
Any word on your response to my compromise Andreas.
Keith
On 7/8/09 5:51 AM, "Keith Hodges" keith_hodges@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, or we do each own fork.
I have mine working ...
What part of hitting the load updates button for any squeaker could see his number changes from nnnn to higher and some fixes and enhancement goes to his/her image your disagree ?
Edgar
Edgar J. De Cleene wrote:
On 7/8/09 5:51 AM, "Keith Hodges" keith_hodges@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
On 7/8/09 10:18 AM, "Keith Hodges" keith_hodges@yahoo.co.uk wrote:
Edgar J. De Cleene wrote:
On 7/8/09 5:51 AM, "Keith Hodges" keith_hodges@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@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.
2009/7/8 Edgar J. De Cleene edgardec2001@yahoo.com.ar:
On 7/8/09 10:18 AM, "Keith Hodges" keith_hodges@yahoo.co.uk wrote:
Edgar J. De Cleene wrote:
On 7/8/09 5:51 AM, "Keith Hodges" keith_hodges@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@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Starter for 10,
pros and cons?
Keith
On 7/8/09 10:19 AM, "Keith Hodges" keith_hodges@yahoo.co.uk wrote:
Starter for 10,
pros and cons?
Keith
See all others Squeak forks. Any could see his number grows and any kid who knows how to hit a button could have his/her image up to day.
Maybe NASA was interested in Bob taking Sake for cross some Mars Rio
Edgar
The 'load updates' button is far from useless. The function of the 'load updates' button is to take an image that is reasonably current and synchronize it so it is up to the up to date with the in development state so that we are all working in the same playing field.
Ken
On Wed, 2009-07-08 at 14:19 +0100, Keith Hodges wrote:
Starter for 10,
pros and cons?
Keith _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
2009/7/8 Ken Causey ken@kencausey.com:
The 'load updates' button is far from useless. The function of the 'load updates' button is to take an image that is reasonably current and synchronize it so it is up to the up to date with the in development state so that we are all working in the same playing field.
Except that it could have different sense for core developers vs endusers(stable image users). Core devs, obviously, would want to load a most up to date & bleeding edge stuff, while stable image users may want to update packages , which already well tested & error proof.
Which gives us just another reason to think how we could use Keith's framework in this regard :)
Ken
On Wed, 2009-07-08 at 14:19 +0100, Keith Hodges wrote:
Starter for 10,
pros and cons?
Keith _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Igor Stasenko wrote:
Except that it could have different sense for core developers vs endusers(stable image users).
In practice it always comes down to two uses: For active development there is a main code base that you sync against (trunk development). For a released version you want to get certain fixes that have been blessed for your version (release maintenance).
Cheers, - Andreas
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Except that it could have different sense for core developers vs endusers(stable image users).
In practice it always comes down to two uses: For active development there is a main code base that you sync against (trunk development). For a released version you want to get certain fixes that have been blessed for your version (release maintenance).
Right, and in case if we have multiple releases, say 3.11, 3.12, 3.13 and so on, and in parallel, we could have, say 3.11-withClosures , 3.12-withClosures ... and fix is blessed only for images with closure support - we need a clever tool which can deliver this fix only to those images and ignore it for the rest.
Cheers, - Andreas _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Except that it could have different sense for core developers vs endusers(stable image users).
In practice it always comes down to two uses: For active development there is a main code base that you sync against (trunk development). For a released version you want to get certain fixes that have been blessed for your version (release maintenance).
Right, and in case if we have multiple releases, say 3.11, 3.12, 3.13 and so on, and in parallel, we could have, say 3.11-withClosures , 3.12-withClosures ... and fix is blessed only for images with closure support - we need a clever tool which can deliver this fix only to those images and ignore it for the rest.
I'm not sure what you're saying here. We don't need a clever tool since what you are describing is the very nature of incremental updates. The update stream for example, had sections for each version. What I've been proposing was a series of update.mcms in each repository. So if you're on 3.11 (release) you update from http://source.squeak.org/Squeak311 if you're on 3.12 (release) you update from http://source.squeak.org/Squeak312 and if you're a developer you update from http://source.squeak.org/trunk. There neither is nor should there be any cleverness in the process, only predictability.
Cheers, - Andreas
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Except that it could have different sense for core developers vs endusers(stable image users).
In practice it always comes down to two uses: For active development there is a main code base that you sync against (trunk development). For a released version you want to get certain fixes that have been blessed for your version (release maintenance).
Right, and in case if we have multiple releases, say 3.11, 3.12, 3.13 and so on, and in parallel, we could have, say 3.11-withClosures , 3.12-withClosures ... and fix is blessed only for images with closure support - we need a clever tool which can deliver this fix only to those images and ignore it for the rest.
I'm not sure what you're saying here. We don't need a clever tool since what you are describing is the very nature of incremental updates. The update stream for example, had sections for each version. What I've been proposing was a series of update.mcms in each repository. So if you're on 3.11 (release) you update from http://source.squeak.org/Squeak311 if you're on 3.12 (release) you update from http://source.squeak.org/Squeak312 and if you're a developer you update from http://source.squeak.org/trunk. There neither is nor should there be any cleverness in the process, only predictability.
Good. Now think, a third party maintains own set of mutated stuff, based on 3.12 + extra stuff. Obviously a user of such image , by pressing an 'update' button wants to get an update in 3.12 branch + extra stuff updates. What you think, is such approach makes sense? Because if not, then answer is: hey pal, use own fork. But if it is, then answer: hey pal, no need to fork , you can keep going with an 'official' release + own stuff.
Cheers, - Andreas _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Igor Stasenko wrote:
Now think, a third party maintains own set of mutated stuff, based on 3.12 + extra stuff. Obviously a user of such image , by pressing an 'update' button wants to get an update in 3.12 branch + extra stuff updates. What you think, is such approach makes sense?
To be honest, I think it doesn't make too much sense, but it is very easy to support. Currently the update button in trunk is hooked up via:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/trunk' ).
There are two trivial ways to extend this. First is provide a list of repositories that you'd like to update from:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
Second, we could mark repositories directly in MC (i.e., "include in updates") and/or offer a menu option that just says "update from repository".
Cheers, - Andreas
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Now think, a third party maintains own set of mutated stuff, based on 3.12 + extra stuff. Obviously a user of such image , by pressing an 'update' button wants to get an update in 3.12 branch + extra stuff updates. What you think, is such approach makes sense?
To be honest, I think it doesn't make too much sense, but it is very easy to support. Currently the update button in trunk is hooked up via:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/trunk' ).
There are two trivial ways to extend this. First is provide a list of repositories that you'd like to update from:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
This is good & simple up to the point, when the upstream updates (say 3.11) going into conflict either with Seaside29 or MyStuff and breaking everything, while most/rest of them is not.
So, by mentioning 'clever tools' i meant a more clever update process, which can be expressed in a form:
UpdatesFrom: 'http://source.squeak.org/Squeak311' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/Seaside29' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/MyStuff' )) install
Second, we could mark repositories directly in MC (i.e., "include in updates") and/or offer a menu option that just says "update from repository".
Cheers, - Andreas _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
2009/7/8 Igor Stasenko siguctua@gmail.com:
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
Now think, a third party maintains own set of mutated stuff, based on 3.12 + extra stuff. Obviously a user of such image , by pressing an 'update' button wants to get an update in 3.12 branch + extra stuff updates. What you think, is such approach makes sense?
To be honest, I think it doesn't make too much sense, but it is very easy to support. Currently the update button in trunk is hooked up via:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/trunk' ).
There are two trivial ways to extend this. First is provide a list of repositories that you'd like to update from:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
This is good & simple up to the point, when the upstream updates (say 3.11) going into conflict either with Seaside29 or MyStuff and breaking everything, while most/rest of them is not.
So, by mentioning 'clever tools' i meant a more clever update process, which can be expressed in a form:
(
UpdatesFrom: 'http://source.squeak.org/Squeak311' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/Seaside29' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/MyStuff' ))
) install
sorry, missed the extra braces. But i guess you got my point :)
Second, we could mark repositories directly in MC (i.e., "include in updates") and/or offer a menu option that just says "update from repository".
Cheers, - Andreas _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
-- Best regards, Igor Stasenko AKA sig.
I wish we weren't having this conversation on the Release list but instead on the Squeak-dev list. I think this issue is relevant to all.
Ken
On 7/8/09 5:08 PM, "Ken Causey" ken@kencausey.com wrote:
I wish we weren't having this conversation on the Release list but instead on the Squeak-dev list. I think this issue is relevant to all.
Ken
Yes, Ok And I was in IRC and could have a Release meeting in Skype Edgar
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@gmx.de:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
This is good & simple up to the point, when the upstream updates (say 3.11) going into conflict either with Seaside29 or MyStuff and breaking everything, while most/rest of them is not.
So, by mentioning 'clever tools' i meant a more clever update process, which can be expressed in a form:
UpdatesFrom: 'http://source.squeak.org/Squeak311' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/Seaside29' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/MyStuff' )) install
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.
Cheers, - Andreas
2009/7/8 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@gmx.de:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
This is good & simple up to the point, when the upstream updates (say 3.11) going into conflict either with Seaside29 or MyStuff and breaking everything, while most/rest of them is not.
So, by mentioning 'clever tools' i meant a more clever update process, which can be expressed in a form:
UpdatesFrom: 'http://source.squeak.org/Squeak311' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/Seaside29' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/MyStuff' )) install
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.
Cheers :)
Cheers, - Andreas _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@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.
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.
Cheers, - Andreas
2009/7/9 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
2009/7/9 Igor Stasenko siguctua@gmail.com:
2009/7/9 Andreas Raab andreas.raab@gmx.de:
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
-- Best regards, Igor Stasenko AKA sig.
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@gmx.de:
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
2009/7/9 Andreas Raab andreas.raab@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@gmx.de:
Igor Stasenko wrote:
2009/7/8 Andreas Raab andreas.raab@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Igor Stasenko wrote:
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.
My main issue with this discussion is that you're discussing it as if our main problem were lack of flexibility in the update process. But that's not the problem we're having - the problem we're having is that we had no functioning update process whatsoever!
I'll be the first to admit that there are situations that can be painful with MCMs. And we'll have these. And once we see what they are and what we need to do to address the problems we can see how to improve the process. But unless you provide a practical alternative, discussing the theoretical shortcomings of MCMs doesn't bring us forward. If all you want to say is that MCMs indeed have shortcomings, I'll concede that point right away. But now what? Go back to have no solution again?
If you want to propose a solution, let's look at it in practice. Write an update script that *actually* loads everything from trunk. Then let's compare the two approaches and discuss the differences and similarities in context.
Cheers, - Andreas
Andreas Raab wrote:
Igor Stasenko wrote:
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.
My main issue with this discussion is that you're discussing it as if our main problem were lack of flexibility in the update process. But that's not the problem we're having - the problem we're having is that we had no functioning update process whatsoever!
I once attended an undergraduate workshop in which teams were each given a pile of jigsaw pieces. However the adjudicator did say that we determined what the rules of the exercise were. After a lot of time, we realised that this meant that we got to decide what was relevant or not in the exercise. We could decide not to bother with the jigsaw pieces and we could all go for a beer.
So, not having a functioning updates mechanism is not a problem at all, that is a solution, that is a big step forward.
One of the identified problems with the current development process is that the "updates" mechanism gives rise to incremental development, an ever increasing image, a moving target for really useful developments, a bottleneck in the guru approving process, and a limited ability to go back and fix something after the fact. So we made a philosophical choice to ditch the updates mechanism.
Now your mcm updates mechanism may be better than the older changesets updates mechanism, and it looks like it might be useful for image syncing between a development image and a server.
So I am sorry to say that this means we need to move the image forward the hard way. That being to recuit volunteers to actually work on a subsystem as a substancial project whose integration can be roadmapped, rather than inviting all and sundry to commit to my image.
Keith
Keith Hodges wrote:
Andreas Raab wrote:
Igor Stasenko wrote:
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.
My main issue with this discussion is that you're discussing it as if our main problem were lack of flexibility in the update process. But that's not the problem we're having - the problem we're having is that we had no functioning update process whatsoever!
I once attended an undergraduate workshop in which teams were each given a pile of jigsaw pieces. However the adjudicator did say that we determined what the rules of the exercise were. After a lot of time, we realised that this meant that we got to decide what was relevant or not in the exercise. We could decide not to bother with the jigsaw pieces and we could all go for a beer.
Great idea, I think you should have that beer. While you're having it the rest of us can solve the update puzzle. Obviously you have no interest in the problem, so why don't you leave it to people who'd like to solve it? Your non-constructive role in this discussion is not appreciated.
Thanks, - Andreas
So, not having a functioning updates mechanism is not a problem at all, that is a solution, that is a big step forward.
One of the identified problems with the current development process is that the "updates" mechanism gives rise to incremental development, an ever increasing image, a moving target for really useful developments, a bottleneck in the guru approving process, and a limited ability to go back and fix something after the fact. So we made a philosophical choice to ditch the updates mechanism.
Now your mcm updates mechanism may be better than the older changesets updates mechanism, and it looks like it might be useful for image syncing between a development image and a server.
So I am sorry to say that this means we need to move the image forward the hard way. That being to recuit volunteers to actually work on a subsystem as a substancial project whose integration can be roadmapped, rather than inviting all and sundry to commit to my image.
Keith
Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
Andreas Raab wrote:
Keith Hodges wrote:
Andreas Raab wrote:
Igor Stasenko wrote:
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.
My main issue with this discussion is that you're discussing it as if our main problem were lack of flexibility in the update process. But that's not the problem we're having - the problem we're having is that we had no functioning update process whatsoever!
I once attended an undergraduate workshop in which teams were each given a pile of jigsaw pieces. However the adjudicator did say that we determined what the rules of the exercise were. After a lot of time, we realised that this meant that we got to decide what was relevant or not in the exercise. We could decide not to bother with the jigsaw pieces and we could all go for a beer.
Great idea, I think you should have that beer. While you're having it the rest of us can solve the update puzzle. Obviously you have no interest in the problem, so why don't you leave it to people who'd like to solve it? Your non-constructive role in this discussion is not appreciated.
Thanks,
- Andreas
I am just asking the relevant question, why do you need an update in the firstplace? Who needs it and what for?
I am not being non-constructive, I am letting you know that we have already had this conversation, and the solution proposed was not to use the updates mechanism, or at least not until you have a finished product to deliver.
Keith
Keith Hodges wrote:
I am just asking the relevant question, why do you need an update in the firstplace? Who needs it and what for?
I have asked this question in the past, I'll ask it again: Have you ever worked in an environment where multiple people have worked together on the same project/product? If you have, how have you synchronized the changes between the developers?
There's your answer. When developers work together they need a way of syncing their code base quickly. Updating from a set of packages does just that. It is common practice in every software project that I am aware of, regardless whether you use MC or SVN. In SVN every day begins with an "svn update" to ensure you see what's changed. In MC every day begins with a "MCPackageBrowser updateAllLoadedPackages" (as it's called at Qwaq).
Cheers, - Andreas
Andreas Raab wrote:
Keith Hodges wrote:
I am just asking the relevant question, why do you need an update in the firstplace? Who needs it and what for?
I have asked this question in the past, I'll ask it again: Have you ever worked in an environment where multiple people have worked together on the same project/product? If you have, how have you synchronized the changes between the developers?
For the parts of projects in Smalltalk that I was in charge of I had 3 developers, we used a bit more of a heavy weight product than squeak, ST/X, ans ST/X has CVS integrated. We also had 2000 tests on that project which made things really smooth. The tests were directly coded from a spec which represented how equipment had to operate, so we had a pretty good quality gate in my team.
For the rest the project components in C++, and perl the team was much much larger, 50+, for development we run from daily builds and we had things like a quality-gate team, customer acceptance testing the works.
As far as my experience goes I have been coding for 33 years, 16 of them in Smalltalk, that should be enough.
There's your answer. When developers work together they need a way of syncing their code base quickly.
When they are developing yes.
Updating from a set of packages does just that. It is common practice in every software project that I am aware of, regardless whether you use MC or SVN. In SVN every day begins with an "svn update" to ensure you see what's changed. In MC every day begins with a "MCPackageBrowser updateAllLoadedPackages" (as it's called at Qwaq).
And I build my images from scratch.
I have to load seaside, load my extensions to seaside, then load some basic components that test if everything works so far, because the seaside crew may have broken something.
Then I have to load pier, and my extensions to pier, and test if those work, because Lukas is always changing things catastrophically.
The difference between us plebs, and you a qwaq is that you have forked, you have control over everything, you can keep all the balls in the air at once. Pharo is the same, they have control of everything. Same for lukas, he only tends to use code he has written himself.
In the real world we have to use what other people give us, and we have to monkey patch it and get it to work. BUT the problem is that they never tell us what they are doing, what they are planning, or what is coming next.
For example, having planned a 4 month project on "using SmaCC to give pier parsers pluggable/swtichable syntaxes", lukas removed the SmaCC parser from pier without any warning or planning, and scuppered the whole project.
I have no qualms with keeping a group of developers in sync for specific projects, but in smalltalk things can be fragile. Pull out something at the bottom and the whole house of cards falls.
When I build an image, I am building something which integrates the work of 7 different developers or teams, and only some of these are actively co-operating. So on any one morning up to 7 people could have broken my image, and they will not necessarily co-operate if I feedback to them.
Every single change you put into trunk, actually makes the problem worse, more uncontrolled unplanned stuff, that is pretty undocumented, its not discussable, its certainly not optional. Then I have to build on top of it.
Keith
Keith Hodges wrote:
Andreas Raab wrote:
There's your answer. When developers work together they need a way of syncing their code base quickly.
When they are developing yes.
Thank you.
Updating from a set of packages does just that. It is common practice in every software project that I am aware of, regardless whether you use MC or SVN. In SVN every day begins with an "svn update" to ensure you see what's changed. In MC every day begins with a "MCPackageBrowser updateAllLoadedPackages" (as it's called at Qwaq).
And I build my images from scratch.
And you are free to do so. But the question was what the update button is good for. The update button is good for syncing quickly during development. In the above you specifically agree to that. Q.E.D.
Cheers, - Andreas
UpdatesFrom: 'http://source.squeak.org/Squeak311' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/Seaside29' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/MyStuff' )) install
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.
Cheers :)
But adding a menu item to MC, in order to offer updates on a per package or per repository basis would not be out of the question.
Sake/Packages does this.
"load latest code from sake/packages"
Keith
2009/7/9 Keith Hodges keith_hodges@yahoo.co.uk:
UpdatesFrom: 'http://source.squeak.org/Squeak311' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/Seaside29' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/MyStuff' )) install
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.
Cheers :)
But adding a menu item to MC, in order to offer updates on a per package or per repository basis would not be out of the question.
Sake/Packages does this.
"load latest code from sake/packages"
Keith, in Sake you can define a more complex tasks, which could provide a sort of an update stream in easily manageable fashion.
For instance, you could have a class TaskForLoadingPackageSetX, which holding a meta-information how to load and/or upgrade from current image version to an image with up-to-date collection of packages A, B, C. Each time a TaskForLoadingPackageSetX author/maintainer updates this class , and enables new versions of basic packages A,B,C to be integrated into latest version - he simply changing the meta-record, or , what i think is more appropriate, adding a new method(s) so they appear in historical record, like:
TaskForLoadingPackageSetX >> loadVersion123 then he adds TaskForLoadingPackageSetX >> loadVersion124 then TaskForLoadingPackageSetX >> loadVersion125 and so on..
Does this makes sense to anyone than me?
Keith _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
2009/7/9 Igor Stasenko siguctua@gmail.com:
2009/7/9 Keith Hodges keith_hodges@yahoo.co.uk:
UpdatesFrom: 'http://source.squeak.org/Squeak311' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/Seaside29' revisedUnder: ( UpdatesFrom: 'http://squeaksource.com/MyStuff' )) install
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.
Cheers :)
But adding a menu item to MC, in order to offer updates on a per package or per repository basis would not be out of the question.
Sake/Packages does this.
"load latest code from sake/packages"
Keith, in Sake you can define a more complex tasks, which could provide a sort of an update stream in easily manageable fashion.
For instance, you could have a class TaskForLoadingPackageSetX, which holding a meta-information how to load and/or upgrade from current image version to an image with up-to-date collection of packages A, B, C. Each time a TaskForLoadingPackageSetX author/maintainer updates this class , and enables new versions of basic packages A,B,C to be integrated into latest version - he simply changing the meta-record, or , what i think is more appropriate, adding a new method(s) so they appear in historical record, like:
TaskForLoadingPackageSetX >> loadVersion123 then he adds TaskForLoadingPackageSetX >> loadVersion124 then TaskForLoadingPackageSetX >> loadVersion125 and so on..
So, then a magical 'update' process for user can be split on two stages:
1. The latest version of TaskForLoadingPackageSetX loaded 2. TaskForLoadingPackageSetX>>update get run
Does this makes sense to anyone than me?
Keith _______________________________________________ Release mailing list Release@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/release
-- Best regards, Igor Stasenko AKA sig.
Keith, in Sake you can define a more complex tasks, which could provide a sort of an update stream in easily manageable fashion.
For instance, you could have a class TaskForLoadingPackageSetX, which holding a meta-information how to load and/or upgrade from current image version to an image with up-to-date collection of packages A, B, C. Each time a TaskForLoadingPackageSetX author/maintainer updates this class , and enables new versions of basic packages A,B,C to be integrated into latest version - he simply changing the meta-record, or , what i think is more appropriate, adding a new method(s) so they appear in historical record, like:
TaskForLoadingPackageSetX >> loadVersion123 then he adds TaskForLoadingPackageSetX >> loadVersion124 then TaskForLoadingPackageSetX >> loadVersion125 and so on..
Does this makes sense to anyone than me?
Definitely some sense,
SakeTasks fundamentally support concepts like, dependsOn: , and isNeeded:
SakeClassTasks allow things like create a class if it doesn't already exist, which you can put in as a dependent of a task that needs a particular class. Much like "make" creates files or directories when they are needed. Or check if the class/package/method exists before performing the action. Of course this is minor overkill, since you could just use code like Smalltalk at: #Bob ifAbsent: [ do stuff ], but if 50 tasks want to ensure that a class exists then the test will only be carried out once.
For Sake/Packages the packages you define are version controlled using MC, so we are basically taking a snapshot of the state of all packages in time and if you want to go back to a historical snapshot then you can load an older version of Packages-Library
However I think we can simplify the whole issue if we clarify who our users are.
The architects develop a process and tools for the programmers to develop a base release image, the builders in the community build and configure derived images from pre-defined components for their audiences the smalltalk authors and users.
Our target audience is not the end users, or even the individual programmer, it is the builder of interesting customised images, so they would be capable of using a less than single click solution.
If this is the case then the builder of the customised image will have detailed knowledge of how he configured the image he published, and the update stream might be useful to him for passing on emergency fixes to his own users.
Keith
Keith
On 7/8/09 4:42 PM, "Andreas Raab" andreas.raab@gmx.de wrote:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
Second, we could mark repositories directly in MC (i.e., "include in updates") and/or offer a menu option that just says "update from repository".
Cheers,
- Andreas
This could be nice. And we could have updates coming from Pharo ?
Edgar
Edgar J. De Cleene wrote:
On 7/8/09 4:42 PM, "Andreas Raab" andreas.raab@gmx.de wrote:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
Second, we could mark repositories directly in MC (i.e., "include in updates") and/or offer a menu option that just says "update from repository".
Cheers,
- Andreas
This could be nice. And we could have updates coming from Pharo ?
We could, but it requires that the people running the show provide a set of update.mcms. Without that it's not really feasible.
Cheers, - Andreas
Igor Stasenko wrote:
2009/7/8 Ken Causey ken@kencausey.com:
The 'load updates' button is far from useless. The function of the 'load updates' button is to take an image that is reasonably current and synchronize it so it is up to the up to date with the in development state so that we are all working in the same playing field.
Bearing in mind that we are/were aiming to produce a process in which a new minor release could be released daily/weekly 3.10.3 , .4 .5 , and a major release monthly/quarterly I think that this may alter the dynamic somewhat.
Except that it could have different sense for core developers vs endusers(stable image users). Core devs, obviously, would want to load a most up to date & bleeding edge stuff,
Defining first what is a core dev. That would be for me someone who is willing to take on a significant project, or what was referred to as a "grand refactoring".
So when I am operating with my core-dev hat on I will be working on a project which is by definition half completed, I really do not want to have loaded into my environment someone elses half completed projects.
while stable image users may want to update packages , which already well tested & error proof.
I really don't think that this is a common use case. How many serious users keep one image going and push update. I have about 40 current images in my working directory. I frequently download a new image for whatever takes my fancy, on average once a week. I value the fact that when I download 3.10 I know pretty much what its foibles are even if I don't like them.
Also the things that I want fixed in an image rarely do get fixed, for example I waited 2 years for a fix to the annoying browser pane list box bug, that Andreas had fixed ages ago. However now that that fix is available on mantis I can load it, I am not behove to the guardians of the update stream.
I can see Andreas' scheme of a whole repo for updates working much better for updates than the current linear stream, however for pulling apart and assembling a release I am not so sure.
By the way, a not well known feature of Sake/Packages is an #upgrade which loads the latest of all currently loaded packages. One goal I have been working towards is to have only one master list of Packages in the image.
Monticello1 used to maintain its own list, MC1.5 now uses the PackageInfo/PackageOrganiser as the master list. Sake/Packages maintains its own list, but I plan to improve that to use PackagesOrganiser too.
Andreas wrote:
There are two trivial ways to extend this. First is provide a list of
repositories that you'd like to update from:
MCMCMUpdater updateFromRepositories: #( 'http://source.squeak.org/Squeak311' "fixes released for 3.11" 'http://squeaksource.com/Seaside29' "current Seaside 2.9 updates" 'http://squeaksource.com/MyStuff' "and whatever else" ).
Igor replied:
This is good & simple up to the point, when the upstream updates (say 3.11) going into conflict either with Seaside29
And currently the standard practice is for seaside to be developed for deployment into an image which is a well known quantity, i.e. a major release. The same is true for all external packages, so adding the possibility of updates is a potential source of fragility.
Edgar wrote:
This could be nice. And we could have updates coming from Pharo ?
Andreas Replied:
We could, but it requires that the people running the show provide a set of update.mcms. Without that it's not really feasible.
Building an image in which a couple of packages are directly loaded from pharo's trunk would be easy for bob to do, and is anticipated. My only regret here is that it may be quite difficult to agree on common package boundaries.
Keith
Andreas Raab wrote:
Edgar -
You're my hero! ;-) Please go for it. If I can help you, in particular with those frustrating MC loading issues please let me know and I will. I completely agree that we need to move forward on these issues.
Cheers,
- Andreas
Edgar J. De Cleene wrote:
I take the Squeak3.10-7159-basic.image, do the first pass to rip
* Tests- * SMLoader * SMBase * Sunit * SUnitGUI * ScriptLoader * Universes * Installer * XML-Parser * MorphicExtras-Demo * Morphic-CandidatesForGo * Nebraska
All this could be loaded again with new versions from SqueakSource.
And for removing SUnit, there is a stub/dummy placeholder to replace it with in order to avoid obsolete classes. This is available in ss/Testing
Keith
release@lists.squeakfoundation.org