A process proposal for 3.10
Locked
1234567
1234567
Re: Removing Etoys (was Re: A process proposal for 3.10)
 
|
This goes back to one of the opinions that Marcus expressed earlier
in the thread: "The SqueakLand people don't use 3.9, and I am quite sure they never will" This rings true to me (although it would be nice to hear directly from a squeaklander). In my understanding, it was the internationalization code in 3.8 that made it worthwhile for squeakland to undergo the difficult synchronization. I don't think that there is anything compelling enough in 3.9 (or that has been discussed for 3.10) to justify the effort again, especially with a Tweak version of EToys not too far over the horizon. Josh On Oct 18, 2006, at 8:37 AM, Bert Freudenberg wrote: > As Juan wrote, removing Etoys from Morphic while keeping it both > loadable and functioning properly is futile. > > So either you leave it in, or you consciously give up compatibility > with anyone using Etoys now, like the squeakland distribution, OLPC > distribution, Smalland, the Spanish LinEx version, the Japanese > Nihongo version etc. Already synchronizing Squeakland and 3.8 was > hard, nobody has tried yet for 3.9, but this would make it outright > impossible. > > I'm *not* saying you should not do this, but please be aware of the > possible consequences. > > - Bert - > > Am 18.10.2006 um 14:11 schrieb [hidden email]: > >> Hi Giovanni, >> >> I don't think what you say is doable. We don't have the means to >> break all >> dependencies on eToys, and at the same time keep eToys working. It >> would >> need the same kind of work as to make it unloadable and loadable >> back. >> >> When I realized how much refactoring is needed to do that, I >> stopped the >> MorphicSplitters effort and quited as the Morphic Steward. >> >> What I propose can be done. I did it for 3.7. You can download it >> from >> http://www.jvuletich.org/Squeak/EToysFreeMorphic/ >> EtoysFreeMorphic.html . I >> believe Pavel did something similar (although I haven't looked at it. >> >> Anyway, I'd like to be proven wrong. Are you volunteering? >> >> Cheers, >> Juan Vuletich >> >>> When resource is scare, the smarter come out ;) >>> >>> How is big etoys? >>> And How is deeply integrated in Squeak? >>> >>> If Etoy is not so big (as I remembered), we can simply start to >>> "cut its >>> wires" from Morphic and let it aging around. >>> We can start creating a mechanism to deprecate some methods. >>> By the way the deprecation engine seems to me very important to do. >>> >>> We can do this thing with less then 8 hours of work in my own >>> opinion, >>> I suggest to rethink our apprach and to adopt a "Panta >>> Rei" (verything >>> changes - the philosophy of Heraclitus). >>> We should start to plan the new Squeak version WITHOUT throwing >>> away the >>> bad >>> things. >>> >>> We can start taking bad thing alone in a room, putting heavy >>> doors in it, >>> and then >>> prohibing them to exit :) >>> >>> The other developers will start stopping using EToy in a smooth way. >>> >>> After a while we can think how to dismiss them... or not. >>> >>> In my own opinion frequently Squeak home change, so the problem >>> will solve >>> smootly without so much pain. >>> Let's discuss on this approach. >>> >>> >>> On 10/18/06, Juan Vuletich <[hidden email]> wrote: >>>> >>>> So, this seems a good time to remove eToys from the official >>>> release. I >>>> can team with Pavel and Stef (and any other volunteer) to do this. >>>> >>>> However, it will take some 20 or 30 hours of work, and I think >>>> we need >>>> to know if this will be adopted, otherwise I won't spend time on >>>> it. >>>> >>>> I guess the Board could lead, and make a decision, or enlight me >>>> about >>>> the decision process for issues like this one. >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> Marcus Denker wrote: >>>>> The SqueakLand people don't use 3.9, and I am quite sure they >>>>> never >>>> will. >>>>> >>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool >>>>> Etoys >>>>> image for eToys1. >>>>> >>>>> For the future, there needs to be a new eToys2 that is >>>>> maintainable. >>>>> There is a very cool demo of a next-gen eToys based on Tweak. >>>>> That seems, to me, much more the thing to take a look at for the >>>> future >>>>> eToy system. >>>>> >>>>> Marcus >>>> >>>> >>> >>> >>> -- >>> "Just Design It" -- GG >>> Software Architect >>> http://www.objectsroot.com/ > > |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Juan Vuletich (dc)
Juan,
Once eToys are removed (and as you suggested perhaps 20-30 hours work), do you think it is reasonbly possible to have them loadable again? I am not asking you to do the "reload" piece of work, rather asking about your feeling about whether reloadability is possible, and what number of hours would you estimate to make eToys loadable (if such question even makes sense :) - in very rough number, 10, 100, 1000 hours sort of thing). The reason I am asking, and perhaps there are others in this camp, is that for my personal playing with squeak I mostly play with eToys, and would have to either help the reloading effort (which I will, but my abilities cannot guarantee much :) ) or switch to squeakland image. In any case, work towards a small well-defined "squeak core" (with hopefully loadable packages) makes sense. Thanks Milan On 2006 October 18 06:10, Juan Vuletich wrote: > So, this seems a good time to remove eToys from the official release. I > can team with Pavel and Stef (and any other volunteer) to do this. > > However, it will take some 20 or 30 hours of work, and I think we need > to know if this will be adopted, otherwise I won't spend time on it. > > I guess the Board could lead, and make a decision, or enlight me about > the decision process for issues like this one. > > Cheers, > Juan Vuletich > > Marcus Denker wrote: > > The SqueakLand people don't use 3.9, and I am quite sure they never will. > > > > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys > > image for eToys1. > > > > For the future, there needs to be a new eToys2 that is maintainable. > > There is a very cool demo of a next-gen eToys based on Tweak. > > That seems, to me, much more the thing to take a look at for the future > > eToy system. > > > > Marcus |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Joshua Gargus-2
The ones I can think of right now are:
1) Squeak should not include applications. And eToys, (for a Smalltalk programmer) is an application. 2) eToys code is everywhere in the system, not only in eToys classes. 3) the impact of eToys in Morphic is terrible. Just download my image from http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html and browse a bit Morph or any core Morphic classes. Then compare with 3.9. 4) Cleaning (or refactoring or redesigning) Morphic is almost impossible with eToys around. 5) eToys is not being maintained. People who use it, actually use other Squeak distributions, like Squeakland and SmallLand. I'm sure there are others. Cheers, Juan Vuletich > This ignores the reasons that Juan wants to remove EToys in the first > place. > > Juan, I'm sure I've read these reasons elsewhere, but could you > please repeat them for the benefit of this thread? > > Thanks, > Josh > > > > On Oct 18, 2006, at 9:03 AM, Giovanni Giorgi wrote: > >> As I have understood, there is a new eToy implementation in >> progress inside Tweak. >> We can wait until this implementation is a bit stable. >> When this will be true, the other part depending from eToy1 will be >> able to migrate to eToy2. >> After that we can start to deliver an official squeak distribution >> with eToy2 and eToy1 side by side. >> Then after w ahile we can start to evict eToy1. >> >> This will save some efforts, at cost of a bit larger image (but >> avoiding some hours of work can be a good exchange ;) >> >> >> On 10/18/06, [hidden email] <[hidden email]> wrote: Of >> course. >> >> That's why I'm asking the Board to decide, or advice. >> >> Cheers, >> Juan Vuletich >> >> > As Juan wrote, removing Etoys from Morphic while keeping it both >> > loadable and functioning properly is futile. >> > >> > So either you leave it in, or you consciously give up compatibility >> > with anyone using Etoys now, like the squeakland distribution, OLPC >> > distribution, Smalland, the Spanish LinEx version, the Japanese >> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was >> > hard, nobody has tried yet for 3.9, but this would make it outright >> > impossible. >> > >> > I'm *not* saying you should not do this, but please be aware of the >> > possible consequences. >> > >> >> >> >> >> >> >> -- >> "Just Design It" -- GG >> Software Architect >> http://www.objectsroot.com/ >> > > > |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Milan Zimmermann-2
Hi Milan,
It is hard to say, but it is a huge effort. May be in the 1000 hours range. May be much more than that. I don't think it's worth doing. For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. Or the new Tweak based, when available. Cheers, Juan Vuletich > Juan, > > Once eToys are removed (and as you suggested perhaps 20-30 hours work), do > you > think it is reasonbly possible to have them loadable again? I am not > asking > you to do the "reload" piece of work, rather asking about your feeling > about > whether reloadability is possible, and what number of hours would you > estimate to make eToys loadable (if such question even makes sense :) - in > very rough number, 10, 100, 1000 hours sort of thing). The reason I am > asking, and perhaps there are others in this camp, is that for my personal > playing with squeak I mostly play with eToys, and would have to either > help > the reloading effort (which I will, but my abilities cannot guarantee > much :) ) or switch to squeakland image. In any case, work towards a small > well-defined "squeak core" (with hopefully loadable packages) makes > sense. > > Thanks Milan > > On 2006 October 18 06:10, Juan Vuletich wrote: >> So, this seems a good time to remove eToys from the official release. I >> can team with Pavel and Stef (and any other volunteer) to do this. >> >> However, it will take some 20 or 30 hours of work, and I think we need >> to know if this will be adopted, otherwise I won't spend time on it. >> >> I guess the Board could lead, and make a decision, or enlight me about >> the decision process for issues like this one. >> >> Cheers, >> Juan Vuletich >> >> Marcus Denker wrote: >> > The SqueakLand people don't use 3.9, and I am quite sure they never >> will. >> > >> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys >> > image for eToys1. >> > >> > For the future, there needs to be a new eToys2 that is maintainable. >> > There is a very cool demo of a next-gen eToys based on Tweak. >> > That seems, to me, much more the thing to take a look at for the >> future >> > eToy system. >> > >> > Marcus > > |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
As said, we must give up to a frontal attack.
There is a plan to use Tweak instead of Morphic in the next few years (1-3)? If Morphic will be obsolete in three years, it'd not be so bad to have "eToy1" around for a while. We can think of fixing only eToy critical bugs and left the others alone. On 10/18/06, [hidden email] <[hidden email]> wrote: Hi Milan, -- "Just Design It" -- GG Software Architect http://www.objectsroot.com/ |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Joshua Gargus-2
Just for clarification - the m17n code *came* from Squeakland (and
originally from the Japanese version) and was put into 3.8. Not the other way around. About the Tweak Etoys version, as far as I know, nobody is currently working on it. It is usable, several people are building stuff on top of it, but nobody works on what you could call its core. It could be developed further by the community (same as Tweak, for that matter), but "waiting for it to happen" is not a fruitful strategy. Software does not write itself magically just yet. - Bert - Am 18.10.2006 um 15:27 schrieb Josh Gargus: > This goes back to one of the opinions that Marcus expressed earlier > in the thread: > > "The SqueakLand people don't use 3.9, and I am quite sure they > never will" > > This rings true to me (although it would be nice to hear directly > from a squeaklander). In my understanding, it was the > internationalization code in 3.8 that made it worthwhile for > squeakland to undergo the difficult synchronization. I don't think > that there is anything compelling enough in 3.9 (or that has been > discussed for 3.10) to justify the effort again, especially with a > Tweak version of EToys not too far over the horizon. > > Josh > > > On Oct 18, 2006, at 8:37 AM, Bert Freudenberg wrote: > >> As Juan wrote, removing Etoys from Morphic while keeping it both >> loadable and functioning properly is futile. >> >> So either you leave it in, or you consciously give up >> compatibility with anyone using Etoys now, like the squeakland >> distribution, OLPC distribution, Smalland, the Spanish LinEx >> version, the Japanese Nihongo version etc. Already synchronizing >> Squeakland and 3.8 was hard, nobody has tried yet for 3.9, but >> this would make it outright impossible. >> >> I'm *not* saying you should not do this, but please be aware of >> the possible consequences. >> >> - Bert - >> >> Am 18.10.2006 um 14:11 schrieb [hidden email]: >> >>> Hi Giovanni, >>> >>> I don't think what you say is doable. We don't have the means to >>> break all >>> dependencies on eToys, and at the same time keep eToys working. >>> It would >>> need the same kind of work as to make it unloadable and loadable >>> back. >>> >>> When I realized how much refactoring is needed to do that, I >>> stopped the >>> MorphicSplitters effort and quited as the Morphic Steward. >>> >>> What I propose can be done. I did it for 3.7. You can download it >>> from >>> http://www.jvuletich.org/Squeak/EToysFreeMorphic/ >>> EtoysFreeMorphic.html . I >>> believe Pavel did something similar (although I haven't looked at >>> it. >>> >>> Anyway, I'd like to be proven wrong. Are you volunteering? >>> >>> Cheers, >>> Juan Vuletich >>> >>>> When resource is scare, the smarter come out ;) >>>> >>>> How is big etoys? >>>> And How is deeply integrated in Squeak? >>>> >>>> If Etoy is not so big (as I remembered), we can simply start to >>>> "cut its >>>> wires" from Morphic and let it aging around. >>>> We can start creating a mechanism to deprecate some methods. >>>> By the way the deprecation engine seems to me very important to do. >>>> >>>> We can do this thing with less then 8 hours of work in my own >>>> opinion, >>>> I suggest to rethink our apprach and to adopt a "Panta >>>> Rei" (verything >>>> changes - the philosophy of Heraclitus). >>>> We should start to plan the new Squeak version WITHOUT throwing >>>> away the >>>> bad >>>> things. >>>> >>>> We can start taking bad thing alone in a room, putting heavy >>>> doors in it, >>>> and then >>>> prohibing them to exit :) >>>> >>>> The other developers will start stopping using EToy in a smooth >>>> way. >>>> >>>> After a while we can think how to dismiss them... or not. >>>> >>>> In my own opinion frequently Squeak home change, so the problem >>>> will solve >>>> smootly without so much pain. >>>> Let's discuss on this approach. >>>> >>>> >>>> On 10/18/06, Juan Vuletich <[hidden email]> wrote: >>>>> >>>>> So, this seems a good time to remove eToys from the official >>>>> release. I >>>>> can team with Pavel and Stef (and any other volunteer) to do this. >>>>> >>>>> However, it will take some 20 or 30 hours of work, and I think >>>>> we need >>>>> to know if this will be adopted, otherwise I won't spend time >>>>> on it. >>>>> >>>>> I guess the Board could lead, and make a decision, or enlight >>>>> me about >>>>> the decision process for issues like this one. >>>>> >>>>> Cheers, >>>>> Juan Vuletich >>>>> >>>>> Marcus Denker wrote: >>>>>> The SqueakLand people don't use 3.9, and I am quite sure they >>>>>> never >>>>> will. >>>>>> >>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool >>>>>> Etoys >>>>>> image for eToys1. >>>>>> >>>>>> For the future, there needs to be a new eToys2 that is >>>>>> maintainable. >>>>>> There is a very cool demo of a next-gen eToys based on Tweak. >>>>>> That seems, to me, much more the thing to take a look at for the >>>>> future >>>>>> eToy system. >>>>>> >>>>>> Marcus >>>>> >>>>> >>>> >>>> >>>> -- >>>> "Just Design It" -- GG >>>> Software Architect >>>> http://www.objectsroot.com/ >> >> > > |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Juan Vuletich (dc)
On 2006 October 18 09:59, [hidden email] wrote:
> Hi Milan, > > It is hard to say, but it is a huge effort. May be in the 1000 hours > range. May be much more than that. I don't think it's worth doing. Thanks Juan, that's what I suspected. And I agree that 3.9 will be here for eToys guys like I, and Tweak-based eToys probably better and more fun. Milan > > For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. Or the > new Tweak based, when available. > > Cheers, > Juan Vuletich > > > Juan, > > > > Once eToys are removed (and as you suggested perhaps 20-30 hours work), > > do you > > think it is reasonbly possible to have them loadable again? I am not > > asking > > you to do the "reload" piece of work, rather asking about your feeling > > about > > whether reloadability is possible, and what number of hours would you > > estimate to make eToys loadable (if such question even makes sense :) - > > in very rough number, 10, 100, 1000 hours sort of thing). The reason I am > > asking, and perhaps there are others in this camp, is that for my > > personal playing with squeak I mostly play with eToys, and would have to > > either help > > the reloading effort (which I will, but my abilities cannot guarantee > > much :) ) or switch to squeakland image. In any case, work towards a > > small well-defined "squeak core" (with hopefully loadable packages) > > makes sense. > > > > Thanks Milan > > > > On 2006 October 18 06:10, Juan Vuletich wrote: > >> So, this seems a good time to remove eToys from the official release. I > >> can team with Pavel and Stef (and any other volunteer) to do this. > >> > >> However, it will take some 20 or 30 hours of work, and I think we need > >> to know if this will be adopted, otherwise I won't spend time on it. > >> > >> I guess the Board could lead, and make a decision, or enlight me about > >> the decision process for issues like this one. > >> > >> Cheers, > >> Juan Vuletich > >> > >> Marcus Denker wrote: > >> > The SqueakLand people don't use 3.9, and I am quite sure they never > >> > >> will. > >> > >> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys > >> > image for eToys1. > >> > > >> > For the future, there needs to be a new eToys2 that is maintainable. > >> > There is a very cool demo of a next-gen eToys based on Tweak. > >> > That seems, to me, much more the thing to take a look at for the > >> > >> future > >> > >> > eToy system. > >> > > >> > Marcus |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Bert Freudenberg
On 10/18/06, Bert Freudenberg <[hidden email]> wrote: -- [...] By the way after ten years of works on software field I *know* this very very *well* I am only trying to keep the best things and to maximize our time. Do you ever asked yourself because we have so little active developer on squeak? Do you think we are right? I start having some doubts. "Just Design It" -- GG Software Architect http://www.objectsroot.com/ |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Bert Freudenberg
On Oct 18, 2006, at 10:21 AM, Bert Freudenberg wrote: > Just for clarification - the m17n code *came* from Squeakland (and > originally from the Japanese version) and was put into 3.8. Not the > other way around. > Thanks for the correction. > About the Tweak Etoys version, as far as I know, nobody is > currently working on it. It is usable, several people are building > stuff on top of it, but nobody works on what you could call its > core. It could be developed further by the community (same as > Tweak, for that matter), but "waiting for it to happen" is not a > fruitful strategy. Software does not write itself magically just yet. I'm not advocating waiting around for Tweak Etoys. I'm speculating that removing Etoys from 3.10 will not have a large impact on the Squeakland community (leaving aside the other distros that you mentioned). Of course Tweak Etoys won't magically appear, but neither will Squeakland magically port itself to 3.10. I'm simply saying that, given my understanding of the risks and rewards, it is more likely that someone will put their energy into Tweak Etoys than into maintaining Etoys Classic in new Squeak versions. Juan has volunteered to remove Etoys from 3.10. My speculations above are intended solely to evaluate one of the potential costs of Juan's proposal, namely the cost of "consciously giving up compatability" with Squeakland. Josh > > - Bert - > > Am 18.10.2006 um 15:27 schrieb Josh Gargus: > >> This goes back to one of the opinions that Marcus expressed >> earlier in the thread: >> >> "The SqueakLand people don't use 3.9, and I am quite sure they >> never will" >> >> This rings true to me (although it would be nice to hear directly >> from a squeaklander). In my understanding, it was the >> internationalization code in 3.8 that made it worthwhile for >> squeakland to undergo the difficult synchronization. I don't >> think that there is anything compelling enough in 3.9 (or that has >> been discussed for 3.10) to justify the effort again, especially >> with a Tweak version of EToys not too far over the horizon. >> >> Josh >> >> >> On Oct 18, 2006, at 8:37 AM, Bert Freudenberg wrote: >> >>> As Juan wrote, removing Etoys from Morphic while keeping it both >>> loadable and functioning properly is futile. >>> >>> So either you leave it in, or you consciously give up >>> compatibility with anyone using Etoys now, like the squeakland >>> distribution, OLPC distribution, Smalland, the Spanish LinEx >>> version, the Japanese Nihongo version etc. Already synchronizing >>> Squeakland and 3.8 was hard, nobody has tried yet for 3.9, but >>> this would make it outright impossible. >>> >>> I'm *not* saying you should not do this, but please be aware of >>> the possible consequences. >>> >>> - Bert - >>> >>> Am 18.10.2006 um 14:11 schrieb [hidden email]: >>> >>>> Hi Giovanni, >>>> >>>> I don't think what you say is doable. We don't have the means to >>>> break all >>>> dependencies on eToys, and at the same time keep eToys working. >>>> It would >>>> need the same kind of work as to make it unloadable and loadable >>>> back. >>>> >>>> When I realized how much refactoring is needed to do that, I >>>> stopped the >>>> MorphicSplitters effort and quited as the Morphic Steward. >>>> >>>> What I propose can be done. I did it for 3.7. You can download >>>> it from >>>> http://www.jvuletich.org/Squeak/EToysFreeMorphic/ >>>> EtoysFreeMorphic.html . I >>>> believe Pavel did something similar (although I haven't looked >>>> at it. >>>> >>>> Anyway, I'd like to be proven wrong. Are you volunteering? >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>>> When resource is scare, the smarter come out ;) >>>>> >>>>> How is big etoys? >>>>> And How is deeply integrated in Squeak? >>>>> >>>>> If Etoy is not so big (as I remembered), we can simply start to >>>>> "cut its >>>>> wires" from Morphic and let it aging around. >>>>> We can start creating a mechanism to deprecate some methods. >>>>> By the way the deprecation engine seems to me very important to >>>>> do. >>>>> >>>>> We can do this thing with less then 8 hours of work in my own >>>>> opinion, >>>>> I suggest to rethink our apprach and to adopt a "Panta >>>>> Rei" (verything >>>>> changes - the philosophy of Heraclitus). >>>>> We should start to plan the new Squeak version WITHOUT throwing >>>>> away the >>>>> bad >>>>> things. >>>>> >>>>> We can start taking bad thing alone in a room, putting heavy >>>>> doors in it, >>>>> and then >>>>> prohibing them to exit :) >>>>> >>>>> The other developers will start stopping using EToy in a smooth >>>>> way. >>>>> >>>>> After a while we can think how to dismiss them... or not. >>>>> >>>>> In my own opinion frequently Squeak home change, so the problem >>>>> will solve >>>>> smootly without so much pain. >>>>> Let's discuss on this approach. >>>>> >>>>> >>>>> On 10/18/06, Juan Vuletich <[hidden email]> wrote: >>>>>> >>>>>> So, this seems a good time to remove eToys from the official >>>>>> release. I >>>>>> can team with Pavel and Stef (and any other volunteer) to do >>>>>> this. >>>>>> >>>>>> However, it will take some 20 or 30 hours of work, and I think >>>>>> we need >>>>>> to know if this will be adopted, otherwise I won't spend time >>>>>> on it. >>>>>> >>>>>> I guess the Board could lead, and make a decision, or enlight >>>>>> me about >>>>>> the decision process for issues like this one. >>>>>> >>>>>> Cheers, >>>>>> Juan Vuletich >>>>>> >>>>>> Marcus Denker wrote: >>>>>>> The SqueakLand people don't use 3.9, and I am quite sure they >>>>>>> never >>>>>> will. >>>>>>> >>>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool >>>>>>> Etoys >>>>>>> image for eToys1. >>>>>>> >>>>>>> For the future, there needs to be a new eToys2 that is >>>>>>> maintainable. >>>>>>> There is a very cool demo of a next-gen eToys based on Tweak. >>>>>>> That seems, to me, much more the thing to take a look at for the >>>>>> future >>>>>>> eToy system. >>>>>>> >>>>>>> Marcus >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> "Just Design It" -- GG >>>>> Software Architect >>>>> http://www.objectsroot.com/ >>> >>> >> >> > > |
RE: Removing Etoys (was Re: A process proposal for 3.10)
|
|
In reply to this post by Juan Vuletich (dc)
Any chance we could instead make EToys removable, but leave it in the base
image so that if, in the future, Squeakland or Tweak would like to resync with squeak that will still be possible? I don't like the idea of hard coding community fragmentation. Ron Teitelbaum > From: [hidden email] > Sent: Wednesday, October 18, 2006 9:59 AM > > Hi Milan, > > It is hard to say, but it is a huge effort. May be in the 1000 hours > range. May be much more than that. I don't think it's worth doing. > > For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. Or the > new Tweak based, when available. > > Cheers, > Juan Vuletich > > > Juan, > > > > Once eToys are removed (and as you suggested perhaps 20-30 hours work), > do > > you > > think it is reasonbly possible to have them loadable again? I am not > > asking > > you to do the "reload" piece of work, rather asking about your feeling > > about > > whether reloadability is possible, and what number of hours would you > > estimate to make eToys loadable (if such question even makes sense :) - > in > > very rough number, 10, 100, 1000 hours sort of thing). The reason I am > > asking, and perhaps there are others in this camp, is that for my > personal > > playing with squeak I mostly play with eToys, and would have to either > > help > > the reloading effort (which I will, but my abilities cannot guarantee > > much :) ) or switch to squeakland image. In any case, work towards a > small > > well-defined "squeak core" (with hopefully loadable packages) makes > > sense. > > > > Thanks Milan > > > > On 2006 October 18 06:10, Juan Vuletich wrote: > >> So, this seems a good time to remove eToys from the official release. I > >> can team with Pavel and Stef (and any other volunteer) to do this. > >> > >> However, it will take some 20 or 30 hours of work, and I think we need > >> to know if this will be adopted, otherwise I won't spend time on it. > >> > >> I guess the Board could lead, and make a decision, or enlight me about > >> the decision process for issues like this one. > >> > >> Cheers, > >> Juan Vuletich > >> > >> Marcus Denker wrote: > >> > The SqueakLand people don't use 3.9, and I am quite sure they never > >> will. > >> > > >> > Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool Etoys > >> > image for eToys1. > >> > > >> > For the future, there needs to be a new eToys2 that is maintainable. > >> > There is a very cool demo of a next-gen eToys based on Tweak. > >> > That seems, to me, much more the thing to take a look at for the > >> future > >> > eToy system. > >> > > >> > Marcus > > > > > > > |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
On Oct 18, 2006, at 7:29 PM, Ron Teitelbaum wrote: > Any chance we could instead make EToys removable, but leave it in > the base > image so that if, in the future, Squeakland or Tweak would like to > resync > with squeak that will still be possible? I don't like the idea of > hard > coding community fragmentation. > > Ron Teitelbaum +1 Markus > >> From: [hidden email] >> Sent: Wednesday, October 18, 2006 9:59 AM >> >> Hi Milan, >> >> It is hard to say, but it is a huge effort. May be in the 1000 hours >> range. May be much more than that. I don't think it's worth doing. >> >> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. >> Or the >> new Tweak based, when available. >> >> Cheers, >> Juan Vuletich >> >>> Juan, >>> >>> Once eToys are removed (and as you suggested perhaps 20-30 hours >>> work), >> do >>> you >>> think it is reasonbly possible to have them loadable again? I am not >>> asking >>> you to do the "reload" piece of work, rather asking about your >>> feeling >>> about >>> whether reloadability is possible, and what number of hours would >>> you >>> estimate to make eToys loadable (if such question even makes >>> sense :) - >> in >>> very rough number, 10, 100, 1000 hours sort of thing). The reason >>> I am >>> asking, and perhaps there are others in this camp, is that for my >> personal >>> playing with squeak I mostly play with eToys, and would have to >>> either >>> help >>> the reloading effort (which I will, but my abilities cannot >>> guarantee >>> much :) ) or switch to squeakland image. In any case, work towards a >> small >>> well-defined "squeak core" (with hopefully loadable packages) makes >>> sense. >>> >>> Thanks Milan >>> >>> On 2006 October 18 06:10, Juan Vuletich wrote: >>>> So, this seems a good time to remove eToys from the official >>>> release. I >>>> can team with Pavel and Stef (and any other volunteer) to do this. >>>> >>>> However, it will take some 20 or 30 hours of work, and I think >>>> we need >>>> to know if this will be adopted, otherwise I won't spend time on >>>> it. >>>> >>>> I guess the Board could lead, and make a decision, or enlight me >>>> about >>>> the decision process for issues like this one. >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> Marcus Denker wrote: >>>>> The SqueakLand people don't use 3.9, and I am quite sure they >>>>> never >>>> will. >>>>> >>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool >>>>> Etoys >>>>> image for eToys1. >>>>> >>>>> For the future, there needs to be a new eToys2 that is >>>>> maintainable. >>>>> There is a very cool demo of a next-gen eToys based on Tweak. >>>>> That seems, to me, much more the thing to take a look at for the >>>> future >>>>> eToy system. >>>>> >>>>> Marcus >>> >>> >> >> >> > > > |
Re: Removing Etoys (was Re: A process proposal for 3.10)
|
|
Ron, Marcus,
I guess you're volunteering for this to happen? Cheers, Juan Vuletich > > On Oct 18, 2006, at 7:29 PM, Ron Teitelbaum wrote: > >> Any chance we could instead make EToys removable, but leave it in >> the base >> image so that if, in the future, Squeakland or Tweak would like to >> resync >> with squeak that will still be possible? I don't like the idea of >> hard >> coding community fragmentation. >> >> Ron Teitelbaum > > +1 > > Markus > >> >>> From: [hidden email] >>> Sent: Wednesday, October 18, 2006 9:59 AM >>> >>> Hi Milan, >>> >>> It is hard to say, but it is a huge effort. May be in the 1000 hours >>> range. May be much more than that. I don't think it's worth doing. >>> >>> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. >>> Or the >>> new Tweak based, when available. >>> >>> Cheers, >>> Juan Vuletich >>> >>>> Juan, >>>> >>>> Once eToys are removed (and as you suggested perhaps 20-30 hours >>>> work), >>> do >>>> you >>>> think it is reasonbly possible to have them loadable again? I am not >>>> asking >>>> you to do the "reload" piece of work, rather asking about your >>>> feeling >>>> about >>>> whether reloadability is possible, and what number of hours would >>>> you >>>> estimate to make eToys loadable (if such question even makes >>>> sense :) - >>> in >>>> very rough number, 10, 100, 1000 hours sort of thing). The reason >>>> I am >>>> asking, and perhaps there are others in this camp, is that for my >>> personal >>>> playing with squeak I mostly play with eToys, and would have to >>>> either >>>> help >>>> the reloading effort (which I will, but my abilities cannot >>>> guarantee >>>> much :) ) or switch to squeakland image. In any case, work towards a >>> small >>>> well-defined "squeak core" (with hopefully loadable packages) makes >>>> sense. >>>> >>>> Thanks Milan >>>> >>>> On 2006 October 18 06:10, Juan Vuletich wrote: >>>>> So, this seems a good time to remove eToys from the official >>>>> release. I >>>>> can team with Pavel and Stef (and any other volunteer) to do this. >>>>> >>>>> However, it will take some 20 or 30 hours of work, and I think >>>>> we need >>>>> to know if this will be adopted, otherwise I won't spend time on >>>>> it. >>>>> >>>>> I guess the Board could lead, and make a decision, or enlight me >>>>> about >>>>> the decision process for issues like this one. >>>>> >>>>> Cheers, >>>>> Juan Vuletich >>>>> >>>>> Marcus Denker wrote: >>>>>> The SqueakLand people don't use 3.9, and I am quite sure they >>>>>> never >>>>> will. >>>>>> >>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool >>>>>> Etoys >>>>>> image for eToys1. >>>>>> >>>>>> For the future, there needs to be a new eToys2 that is >>>>>> maintainable. >>>>>> There is a very cool demo of a next-gen eToys based on Tweak. >>>>>> That seems, to me, much more the thing to take a look at for the >>>>> future >>>>>> eToy system. >>>>>> >>>>>> Marcus >>>> >>>> >>> >>> >>> >> >> >> > > > |
RE: Removing Etoys (was Re: A process proposal for 3.10)
|
|
Juan,
No, specifically I am not volunteering, I am voicing my opinion against removing EToys at all if the result is further fragmentation of our communities. My opinion concerns the politics that is currently Squeak and not a technical assessment. If a good case can be made for removing Etoys besides let the SqueakLand image move along the road by itself since they will never upgrade, then I would be interested in hearing that argument. Otherwise I would prefer to leave it in. I see a benefit in leaving a bridge, however tenuous, between the communities. I see a benefit in having Etoys even if it is an older version in squeak to help facilitate learning and experimentation. I would love to see a Squeak that can run Croquet, Tweak, Etoys, Sophie, and Seaside and I will do anything I can right now to keep these communities together. Ron Teitelbaum > -----Original Message----- > From: [hidden email] > Sent: Wednesday, October 18, 2006 2:46 PM > > Ron, Marcus, > > I guess you're volunteering for this to happen? > > Cheers, > Juan Vuletich > > > > On Oct 18, 2006, at 7:29 PM, Ron Teitelbaum wrote: > > > >> Any chance we could instead make EToys removable, but leave it in > >> the base > >> image so that if, in the future, Squeakland or Tweak would like to > >> resync > >> with squeak that will still be possible? I don't like the idea of > >> hard > >> coding community fragmentation. > >> > >> Ron Teitelbaum > > > > +1 > > > > Markus > > > >> > >>> From: [hidden email] > >>> Sent: Wednesday, October 18, 2006 9:59 AM > >>> > >>> Hi Milan, > >>> > >>> It is hard to say, but it is a huge effort. May be in the 1000 hours > >>> range. May be much more than that. I don't think it's worth doing. > >>> > >>> For eToying, I'd use the Squeakland release, or may be 3.8 or 3.9. > >>> Or the > >>> new Tweak based, when available. > >>> > >>> Cheers, > >>> Juan Vuletich > >>> > >>>> Juan, > >>>> > >>>> Once eToys are removed (and as you suggested perhaps 20-30 hours > >>>> work), > >>> do > >>>> you > >>>> think it is reasonbly possible to have them loadable again? I am not > >>>> asking > >>>> you to do the "reload" piece of work, rather asking about your > >>>> feeling > >>>> about > >>>> whether reloadability is possible, and what number of hours would > >>>> you > >>>> estimate to make eToys loadable (if such question even makes > >>>> sense :) - > >>> in > >>>> very rough number, 10, 100, 1000 hours sort of thing). The reason > >>>> I am > >>>> asking, and perhaps there are others in this camp, is that for my > >>> personal > >>>> playing with squeak I mostly play with eToys, and would have to > >>>> either > >>>> help > >>>> the reloading effort (which I will, but my abilities cannot > >>>> guarantee > >>>> much :) ) or switch to squeakland image. In any case, work towards a > >>> small > >>>> well-defined "squeak core" (with hopefully loadable packages) makes > >>>> sense. > >>>> > >>>> Thanks Milan > >>>> > >>>> On 2006 October 18 06:10, Juan Vuletich wrote: > >>>>> So, this seems a good time to remove eToys from the official > >>>>> release. I > >>>>> can team with Pavel and Stef (and any other volunteer) to do this. > >>>>> > >>>>> However, it will take some 20 or 30 hours of work, and I think > >>>>> we need > >>>>> to know if this will be adopted, otherwise I won't spend time on > >>>>> it. > >>>>> > >>>>> I guess the Board could lead, and make a decision, or enlight me > >>>>> about > >>>>> the decision process for issues like this one. > >>>>> > >>>>> Cheers, > >>>>> Juan Vuletich > >>>>> > >>>>> Marcus Denker wrote: > >>>>>> The SqueakLand people don't use 3.9, and I am quite sure they > >>>>>> never > >>>>> will. > >>>>>> > >>>>>> Etoys 1 is past live-cycle. There is 3.8/OLPC which is a cool > >>>>>> Etoys > >>>>>> image for eToys1. > >>>>>> > >>>>>> For the future, there needs to be a new eToys2 that is > >>>>>> maintainable. > >>>>>> There is a very cool demo of a next-gen eToys based on Tweak. > >>>>>> That seems, to me, much more the thing to take a look at for the > >>>>> future > >>>>>> eToy system. > >>>>>> > >>>>>> Marcus > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > |
Removing Morphic (was: Removing Etoys (was Re: A process proposal for 3.10))
|
|
In reply to this post by Juan Vuletich (dc)
These are good reasons to remove eToys, if the removal of the application
lends to nominal improvements in Morphic. If the goal is to clean up and re-factor without a goal to improve Morphic, I would still vote against it. I disagree with Squeak should not include applications, but I won't argue the point. What is the community's feeling about removing Morphic and replacing it with Tweak so that squeak can run both Tweak, Croquet, and can be a platform for new versions hopefully better packaged eToys? We need to be thinking about folding in and adopting both the private and research functionality that is currently being developed. How difficult would it be to modify current toolBuilder tools to use Tweak instead? Would Andreas even agree that this is a good idea and agree to maintain Tweak in Squeak? What is the possibility that if we adopt Tweak that current Croquet development could also be folded in? (Putting on my flame proof suit) Ron Teitelbaum > From: [hidden email] > Sent: Wednesday, October 18, 2006 9:56 AM > > The ones I can think of right now are: > > 1) Squeak should not include applications. And eToys, (for a Smalltalk > programmer) is an application. > > 2) eToys code is everywhere in the system, not only in eToys classes. > > 3) the impact of eToys in Morphic is terrible. Just download my image from > http://www.jvuletich.org/Squeak/EToysFreeMorphic/EtoysFreeMorphic.html and > browse a bit Morph or any core Morphic classes. Then compare with 3.9. > > 4) Cleaning (or refactoring or redesigning) Morphic is almost impossible > with eToys around. > > 5) eToys is not being maintained. People who use it, actually use other > Squeak distributions, like Squeakland and SmallLand. > > I'm sure there are others. > Cheers, > Juan Vuletich > > > This ignores the reasons that Juan wants to remove EToys in the first > > place. > > > > Juan, I'm sure I've read these reasons elsewhere, but could you > > please repeat them for the benefit of this thread? > > > > Thanks, > > Josh > > > > > > > > On Oct 18, 2006, at 9:03 AM, Giovanni Giorgi wrote: > > > >> As I have understood, there is a new eToy implementation in > >> progress inside Tweak. > >> We can wait until this implementation is a bit stable. > >> When this will be true, the other part depending from eToy1 will be > >> able to migrate to eToy2. > >> After that we can start to deliver an official squeak distribution > >> with eToy2 and eToy1 side by side. > >> Then after w ahile we can start to evict eToy1. > >> > >> This will save some efforts, at cost of a bit larger image (but > >> avoiding some hours of work can be a good exchange ;) > >> > >> > >> On 10/18/06, [hidden email] <[hidden email]> wrote: Of > >> course. > >> > >> That's why I'm asking the Board to decide, or advice. > >> > >> Cheers, > >> Juan Vuletich > >> > >> > As Juan wrote, removing Etoys from Morphic while keeping it both > >> > loadable and functioning properly is futile. > >> > > >> > So either you leave it in, or you consciously give up compatibility > >> > with anyone using Etoys now, like the squeakland distribution, OLPC > >> > distribution, Smalland, the Spanish LinEx version, the Japanese > >> > Nihongo version etc. Already synchronizing Squeakland and 3.8 was > >> > hard, nobody has tried yet for 3.9, but this would make it outright > >> > impossible. > >> > > >> > I'm *not* saying you should not do this, but please be aware of the > >> > possible consequences. > >> > > >> > >> > >> > >> > >> > >> > >> -- > >> "Just Design It" -- GG > >> Software Architect > >> http://www.objectsroot.com/ > >> > > > > > > > > |
|
|
I would go for adopting tweak.
Personally I have never got on with morphic and would much rather see something elegant in its place like Model-View-Presenter as used superlatively in Dolphin. When I last asked for an update on how tweak was progressing this was the reply. > * we are 3.8-based by now > * we use Monticello packages in an MCConfiguration for most updates, still have > an update stream for complex changes > * Islands are used now for projects, we might switch soon to the Croquet island model > * the new graphics interface is still in development > * etoys work pretty well > * not much has happened regarding a scripting syntax AFAIK > - Bert - This sounds pretty good, and etoys lives. Surely a UI framework could benefit significantly from traits and so it would be in their interest to move to 3.9? Keith Send instant messages to your online friends http://uk.messenger.yahoo.com |
Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)
|
|
Keith Hodges wrote:
> Personally I have never got on with morphic and would much rather see > something elegant in its place like Model-View-Presenter as used > superlatively in Dolphin. [... snip ...] > Surely a UI framework could benefit significantly from traits and so it > would be in their interest to move to 3.9? It's kinda funny to see the two statements in the same message and I just can't withstand a little rant. Hope you don't mind ;-) To me, Morphic is to MVC as traits are to classes. What I mean by this is that in MVC you have factored the roles into individual entities with well-defined individual responsibilities. They can be plugged together to enable a variety of interesting dynamic behavior. In Morphic, you have many roles in the same object which means overlapping responsibilities, less clarity and pluggability. With traits, you use a similar approach to Morphic only on the meta-level, e.g., instead of composing concrete ui behavior in a single entity (Morph) you compose abstract trait behavior into a single entity (Class). From what I've seen so far, the results seem shockingly similar. Less clarity than when you have individually factored entities (classes), more unforeseen interaction inside the entity where you combine the different roles into, conflicting meanings which require renames and introduce more complexity (and confusion and conflicted meaning). Another way to look at it is this: If you like MVC then think about what it would mean if you would create Morphic by combining models and views using traits. Would you think that the result is superior to MVC? Personally, I don't think so which is why there is a clear separation between the two in Tweak (in MVC terms only between model and view but this seems to be the more relevant distinction). There are of course some situations where due to technical limitations it is not feasible to use individual entities (objects) to model a problem. In these situations a formal mechanism like traits is of course vastly advantageous to an ad-hoc mechanism like copying all the code manually between two places. But that doesn't mean it's the superior solution in general. Here is another example: Most of the graphical attributes in Tweak are grouped into so-called "costume aspects". Those are individual objects that simply interact with a Tweak costume to model a certain role (like the costume's fill, its border, its text etc). These could have been modeled as traits by simply flattening the classes into the costume's namespace but making them individual entities makes it a lot simpler to deal with the interactions (besides, it saves space, allows controlled exposure of properties etc). For example, I can send the message #bounds to the costume and get the composite bounds for the entire costume or I can send the message #bounds to the text aspect and get only the text bounds. It is always clear what I mean since I have to specify either "costume bounds" or "costume text bounds" and it never changes, neither in the aspect nor the costume. Compare this to a traits solution where I'd have to rename one of the two. Which one is clearer? The one where I say "bounds" when I implement a trait and "textBounds" when I use it? Where "show me the senders of #textBounds" finds the senders in the composition but not in the trait? Or where "senders of bounds" also lists all the senders of #textBounds since they were once called #bounds? I think the answer is clear. [BTW, I just deleted a whole paragraph with another rant about things I think we'll see as a result of applying traits on scale but since nobody has used traits yet for anything real that rant just seemed a little bit too presumptuous. I think I'll just wait with this rant up until someone does something real so that I can point to the issues in context. And I'd *love* to see someone built a UI framework based on traits to illustrate some of these -in my opinion unavoidable- issues] Bottom line: There are reasons to use traits in lack of alternatives, but if I can avoid it by using self-contained entities (objects) I'd rather not. Cheers, - Andreas |
|
|
So you dont like traits much?
I agree there is no reason to apply a paradigm where it doesnt fit. But then I dont know enough about tweak to know whether it would fit or not. (see below) a small question though... How come I get a longer and quicker reply in a rant as a result of one sentence in an email to squeak-dev, than I got from two specific requests on Tweak mailing list which was dead for months. The first dated (26 May) asking for a current update and strategic direction progress information, and the second asking what I could do that would be of assistance in porting morphic tools to tweak which received no replies. best regards Keith > > > > Bottom line: There are reasons to use traits in lack of alternatives, > but if I can avoid it by using self-contained entities (objects) I'd > rather not. > > Cheers, > - Andreas > > ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html |
Re: Morphic is to MVC as Traits are to Classes (was: Re: Removing Morphic)
|
|
Keith Hodges wrote:
> So you dont like traits much? Well, I don't know really. I had much hopes for it but the results do not seem to match my expectations. BTW, just in case you didn't know: this project started as a discussion between Nathanael and myself, and to me, although Nathanael solved the harder problem he also solved the less interesting problem. I'm still looking for more real world examples but to me it seems as if the biggest problem with traits is that they're the logical equivalent of C's #include statement. This may sound harsh but when you think about it, it is very, very similar. And of course that has some uses for sure, but it often creates more problems than it solves. In *particular* when it is applied just because it seems like a good idea in general without having specific reasons for using it. That's mostly why I reacted to your email, because my instant reaction was hell, no, you wouldn't want to use traits instead of delegation in such a situation unless you have to (same goes for subclassing btw). > a small question though... > > How come I get a longer and quicker reply in a rant as a result of one > sentence in an email to squeak-dev, than I got from two specific > requests on Tweak mailing list which was dead for months. The first > dated (26 May) asking for a current update and strategic direction > progress information, and the second asking what I could do that would > be of assistance in porting morphic tools to tweak which received no > replies. There was a period earlier this year (and I think it was the period you are describing) where I didn't get email from the Tweak list. Not sure why this happened but when I sent a test email (let me check ... yeah that was on June 26th) everything seemed to work (again?). Before the last message I have is from february. So there were probably some emails inbetween that I didn't see. Cheers, - Andreas |
|
|
Thank you for the explanation.
I am afraid that this led to my losing interest in tweak for the time being, because the list did indeed seem pretty dead. Keith > from february. So there were probably some emails inbetween that I > didn't see. > > Cheers, > - Andreas > > Send instant messages to your online friends http://uk.messenger.yahoo.com |
|
|
In reply to this post by Andreas.Raab
I would like to know how the test server idea would work in practice?
What would it do. Would it be possible to have a one paragraph spec of such a server. This is my own idea as to how to informally collect fixes and image enhancements in a decentralized manner, while the release team take on bigger things in parallel. The aim is to attempt to obtain potentially the same end result as the 'update stream' but with the possibility of full community participation. One would also hope that we can lighten the burden of the release team so as to free them up to do more radical improvements. Rather than a test server, this idea gives everyone the ability to test a known configuration against their hardware and their own favourite packages. 1. Begin with a known starting image, be it a Kernal image or an RC2. 2. Present a wiki page consisting of an install script This wiki needs the following features - full support for "history of page" and authors of edits. - diffs between page versions (if possible) - wiki links within preformatted text for the script to be annotated. example script (e.g. http://smallwiki.unibe.ch/smallwiki/pier/installationofseasidemagmaandpier/ ) 3. Allow updates to be monticello, sm, or change set based, or some other alternative. i.e. anything that may be found on mantis. Allow/Prefer the install script to directly download source from the mantis file repository (possible?) 4. A user can register with the wiki, adding their proposed submission to 3.9.? to the script page. 4. Testers can then Start with the prescribed image, select the whole script from the wiki page, and update their local image. - Run the tests which (hopefully) come with the updates - Test their own packages/projects with the proposed image. 5. Improve SUnit slightly to enable publishing more than a single test suite. This allows a TestCase class to publish multiple suites of tests. Then you can run all the #tests and the #testsFor39Only but not the #testsFor38Only. 6. Each item in the script wiki page may be marked as a link for feedback, or perhaps to the appropriate mantis page. 7. Have some criteria that we would like submissions to meet, and be willing to allow our submissions to be commented out and marked as not ready yet by benevolent testers. - insufficient test coverage - breaks something - tests fail etc. 8. Be nice to each other --- If this process can informally chug along while the 3.10 team is forming. I propose that they then be freer to take on these "big dont fit monticello tasks on". The release team begins with the same starting point as this informal process. When their change is done. They can test it against the informal process script. They can then post the new image and users can see how the fix install script and the tests handle the new image. Then the process of integrating the fixes to the new image can if necessary be a shared responsibility. Alternatively the release team can review the current status of the informal process, declare that a new release, and begin their "big task" from there, at the same time beginning a new wiki page install script to harvest more fixes in parallel. For loadable packages, package universes seem like a viable option. Again the idea is to raise the visibility of the process and the ability to involve as many people as want to get involved at whatever level of commitment they can offer, as and when. I am not sure how package universes would handle variants. For example, there is Pier, Pier with Unix Security, Pier with ACL Security, Pier with 4 different Persistency schemes, and My own snazzy-pier. Those would have to be marked as mutually exclusive within the universe. does this idea sound like it has practical potential or am I musing far too idealistically? Keith Send instant messages to your online friends http://uk.messenger.yahoo.com |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |