Hi,
Off Topic: Looks like there is debate stirring among the Ruby community on whether to fork Ruby to experiment with parallelization, etc. Sounds awfully familiar. http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html On Topic: A Google search for "squeak roadmap 3.11" turns up no applicable results. Is there a formal roadmap? I am most curious about what will happen to 3.10 when 3.11 is released. Thanks, TimJ |
We are considering setting up a Roadmap of some sort on squeak.org, but
for now see http://installer.pbwiki.com/311 Ken On Mon, 2008-12-08 at 10:12 -0600, Tim Johnson wrote: > Hi, > > Off Topic: Looks like there is debate stirring among the Ruby > community on whether to fork Ruby to experiment with parallelization, > etc. Sounds awfully familiar. > > http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html > > On Topic: A Google search for "squeak roadmap 3.11" turns up no > applicable results. Is there a formal roadmap? I am most curious > about what will happen to 3.10 when 3.11 is released. > > Thanks, > TimJ > > > > signature.asc (196 bytes) Download Attachment |
In reply to this post by Tim Johnson
On Mon, 2008-12-08 at 10:12 -0600, Tim Johnson wrote:
> Hi, > > Off Topic: Looks like there is debate stirring among the Ruby > community on whether to fork Ruby to experiment with parallelization, > etc. Sounds awfully familiar. > > http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html > > On Topic: A Google search for "squeak roadmap 3.11" turns up no > applicable results. Is there a formal roadmap? I am most curious > about what will happen to 3.10 when 3.11 is released. replied before. What do you expect to happen to 3.10? I think there must be some sort of misunderstanding. 3.11 is a descendant of 3.10. So barring a bug addressing release of some kind 3.10 is basically done. Ken > > Thanks, > TimJ > > > > signature.asc (196 bytes) Download Attachment |
In reply to this post by Tim Johnson
> I am most curious about what will happen to 3.10 when 3.11 is released. > > Thanks, > TimJ Here is the theory! In an LPF image: Installer install: 'Tasks'. The main workflow is summarized in the following releases generated by the following classes/tasks which need to be fleshed out. Squeak 3.11 Personal Test Candidate - ReleaseAfterSqueak310Kph-#taskTESTCANDIDATE. Squeak 3.11 Unstable T.C. - ReleaseAfterSqueak310Unstable-#taskTESTCANDIDATE. Squeak 3.11 Stable T.C. - ReleaseAfterSqueak310-#taskTESTCANDIDATE. Squeak 3.11-basic Release Candidate - ReleaseSqueak311-#taskRELEASECANDIDATE. Squeak 3.11-basic Golden - ReleaseSqueak311-#taskGoGolden. Derived images Squeak-3.x-dev - Packages current load: 'Squeak-dev image'. (czar: damien, should already work in 3.9+) Squeak-3.x-web - Packages current load: 'Squeak-web image'. (ditto) Squeak-3.x-devbeta - Packages beta load: 'Squeak-dev image'. (ditto) Squeak-3.x-webbeta - Packages beta load: 'Squeak-web image'. (ditto) Squeak-3.x-fullbeta - Packages beta load: 'Squeak-full image'. (czar wanted) Squeak-3.x-full - Packages current load: 'Squeak-full image'. Squeak-3.x-max - Packages current load: 'Squeak-max image'. (czar wanted) Squeak-3.x-fun - tba (czar wanted) Squeak-3.x(-*whatever*)-test - Packages current load: 'AllTests'. (loads tests into any image Squeak-3.x-seaside - Packages current load: 'Squeak-seaside image'. Squeak 3.x-(*whatever*)-oneclick - ReleaseX-taskGenerateOneClick. Squeak 3.11-minimal - Release311-#taskMINIMAL Squeak 3.11-kernel - Release311-#taskKERNEL Squeak 3.11.1-basic - Release311-#taskUPDATE1 Squeak 3.11.2-basic - Release311-#taskUPDATE2 So by extension, those who only want a minor update of the most essentially essential fixes to 3.10 there is a set of tasks managed by class ReleaseSqueak31-#taskUPDATE3 This would be applied via: Installer install: 'Tasks'. ReleaseSqueak310 taskUPDATE3103 run. Packages current unload: 'Sake'. (to remove all vestiges of the Sake/Tasks/Packages). cheers Keith |
In reply to this post by Tim Johnson
> Hi,
> > Off Topic: Looks like there is debate stirring among the Ruby > community on whether to fork Ruby to experiment with > parallelization, etc. Sounds awfully familiar. But forking is not the end, this is the start of something. Just have a look at what we are doing no MVC, no etoy, a lot of fixes, a lot of tests, TTF,..... > http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html > > On Topic: A Google search for "squeak roadmap 3.11" turns up no > applicable results. Is there a formal roadmap? I am most curious > about what will happen to 3.10 when 3.11 is released. > > Thanks, > TimJ > > > > |
In reply to this post by Ken Causey-3
A roadmap on Squeak.org would make sense. It's also desirable for any
newcomers willing to invest considerable time on a project based on Squeak. Ian. 2008/12/8 Ken Causey <[hidden email]>: > We are considering setting up a Roadmap of some sort on squeak.org, but > for now see > > http://installer.pbwiki.com/311 > > Ken > > On Mon, 2008-12-08 at 10:12 -0600, Tim Johnson wrote: >> Hi, >> >> Off Topic: Looks like there is debate stirring among the Ruby >> community on whether to fork Ruby to experiment with parallelization, >> etc. Sounds awfully familiar. >> >> http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html >> >> On Topic: A Google search for "squeak roadmap 3.11" turns up no >> applicable results. Is there a formal roadmap? I am most curious >> about what will happen to 3.10 when 3.11 is released. >> >> Thanks, >> TimJ >> >> >> >> > > > > |
In reply to this post by keith1y
I was asked for a clearer explanation... :-) so here goes...
========= SakeTasks - The shortest summary I could come up with. A package inspired by Make and ruby's Rake. It runs tasks. Tasks consist of actions (blocks or tasks), in an order as defined by dependencies (blocks or tasks), if the "ifs" (blocks returning true/false, or tasks which succeed or fail), indicate that the task is necessary. Images can be updated, and new releases generated via TasksRelease-c-#task* methods in which bug fixes held on mantis are called up as dependencies.. ============== Here is an example: ReleaseAfterSqueak310-#taskLoadSomething ^ self define: [ :task | task dependsOn: { self fixOneDay: '0000 Some bug not included, placeholder only'. self fixUnstable: '1111 Some bug to be included in the Unstable Build of the next Release'. self fix: '2222 Some bug fix to be included in Next Release'. self fixEssential: '3333 Some bug to be included in any future Updates'. }. task action: { Packages current load: 'Something' } ] ============ In the example, a package is to be loaded: "Packages" contains every Package in Universes, every Package in SqueakMap, and it can automatically attempt to find the latest code for packages that are defined in Universes. Packages also contains sets of packages like Damien's dev image, as maintained by Damien himself. So derived images (e.g. -fun -full -max -test -seaside -dev and -web) can all be generated from package lists maintained by (insert your name here) in Universes &/ Sake/Packages. e.g. Packages current load: 'Squeak-dev image', To use the feature that hunts down the very latest code available for all the packages in Damiens image use #beta instead of #current. Packages beta load: 'Squeak-dev image', (similarly for -funbeta -fullbeta -maxbeta -testbeta -seasidebeta -devbeta and -webbeta) ============ In our example, this action has a list of tasks that it depends upon, and these call up fixes from mantis. This fix tasks will apply themselves if they feel that they are contributing to the desired image. self fixOneDay: '0000 Some bug not included, placeholder only'. In this dummy example bug fix 0000 will never be loaded. self fixUnstable: '1111 Some bug to be included in the Unstable Build of the next Release'. Here 1111 will be loaded in tasks on "Unstable" classes e.g. ReleaseAfterSqueak310Unstable-c-taskTESTCANDIDATE self fix: '2222 Some bug fix to be included in Next Release'. Here 2222 will be loaded in tasks on "Unstable" classes e.g. ReleaseAfterSqueak310-c-taskTESTCANDIDATE self fixEssential: '3333 Some bug to be included in any future Updates'. Here 3333 will be loaded in tasks "Release" classes e.g. ReleaseSqueak310-c-taskUPDATE3 or ReleaseSqueak310-c-taskUPDATE1 ==== dare I ask any questions? Keith |
In reply to this post by stephane ducasse
2008/12/8 stephane ducasse <[hidden email]>:
>> Hi, >> >> Off Topic: Looks like there is debate stirring among the Ruby community >> on whether to fork Ruby to experiment with parallelization, etc. Sounds >> awfully familiar. > > > But forking is not the end, this is the start of something. Just have a look > at what we are doing no MVC, no etoy, a lot of fixes, a lot of tests, > TTF,..... > I'd like to empasize this: - Pharo has the clearly established nearly-achievable goals (good or bad - depends on people's preferences) - does Squeak has the same clearly established nearly-achievable goals? If yes, then why they not on squeak.org, but on (http://installer.pbwiki.com/311) , and also, why there is still people, like Edgar constantly attacking them, showing that there is no consensus about future of squeak? I think, its important to define clearly, that EVERYONE should understand what is the current squeak goals, so no more discussions about them is needed. A clearly defined tasks is half of success. Only when we achive some milestone(s), harvest them and evaluate them - then we should consider about next steps. Right? But what i see, is the endless arguing about what is best for squeak with little consensus and therefore acceptance of current tasks & goals for release team. I hardly beleive that such atmosphere (constant negative pressure) helps developers, raising enthusiasm and will to contribute to squeak. >> >> http://pragdave.blogs.pragprog.com/pragdave/2008/12/forking-rubymy-rubyconf-keynote-is-now-up.html >> >> On Topic: A Google search for "squeak roadmap 3.11" turns up no >> applicable results. Is there a formal roadmap? I am most curious about >> what will happen to 3.10 when 3.11 is released. >> >> Thanks, >> TimJ >> >> >> >> > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Ken Causey-3
Ken Causey wrote:
> We are considering setting up a Roadmap of some sort on squeak.org, but > for now see > Something like this: http://www.levenez.com/unix/ would be also interesting, in terms of which fork started when and where off ... |
In reply to this post by Igor Stasenko
> I'd like to empasize this: > - Pharo has the clearly established nearly-achievable goals (good or > bad - depends on people's preferences) > - does Squeak has the same clearly established nearly-achievable goals? > > If yes, then why they not on squeak.org, but on > (http://installer.pbwiki.com/311) Hi Igor, We had a meeting with everyone that was interested perhaps 9 months ago. Having re-iterated the goal, of more modularity, and better tools. It was agreed that the tools on their way at the time, particularly "MC2" (and now Sake) were likely to change the workflow to the extent that we were not in a position to establish any further goals beyond the "more modularity" and "better tools". The rationale for this being that what is achievable with the old tools and the means to get there was likely to be entirely different with the new tools. With this task based approach, you can make your own personal ideas for goals into tasks, and get started. When you are ready we simply include your task in the build. If the "release-team" dont like your task, or it is not ready for the mainstream, it may still be distributed with the release, for people to see what you were up to, and to contribute further to it. (roll on namespaces!?!) The goals of 3.11 are mainly philosophical and social. Technical goals currently on their way for 3.11 include: * LevelPlayingField as standard (Monticello itself unload/loadable without losing essential state) * Atomic Loading * Traits as standard (but removable via unload task) * Nail the package dependencies issue provide a mechanism to get all things working for everyone. * Release a reasonably functional basic image (rather than a kernel image) but provide working unload tasks for non-essentials * Remove a few more modules (but definitely ensure they are re-loadable) * Removable tests (but definitely re-loadable) * Ship with the very latest packages (3.10 shipped with out-of-date Installer/SqueakMap etc) * Facilitate integration testing, the other side of the coin to image whittling and modularisation. i.e. be able to build and test a very full image. * Bob the Builder for testing and image building, and one-click-image building * Tidy up class organization * Auto finalize the image, e.g. Readme, Release notes etc. version controlled (in mc) + "Fixes" as per usual (but automatically documented in verbose detail) we have about 90 so far. Items marked with a + are specific to 3.11, items marked with a * are tasks which may potentially be applied to any 3.7+ image if you have been left behind or have been forced to fork. Keith |
In reply to this post by Tim Johnson
Tim Johnson wrote:
> I am most curious about what will happen to 3.10 when 3.11 is released. > > Thanks, > TimJ Typically, about a month or so after 3.11 is released people will begin asking for an essential maintenance release of 3.10.x This will be generated from the same set of fixes as used for 3.11, but only the fixEssential: fixes will be included. Keith |
On Dec 8, 2008, at 3:51 PM, Keith Hodges wrote: > Typically, about a month or so after 3.11 is released people will > begin > asking for an essential maintenance release of 3.10.x > > This will be generated from the same set of fixes as used for 3.11, > but > only the fixEssential: fixes will be included. This sounds very reasonable, logical and exciting. Thanks! - TimJ |
In reply to this post by keith1y
see below re traits...
On Mon, Dec 8, 2008 at 1:48 PM, Keith Hodges <[hidden email]> wrote:
Peter Ahe of the Newspeak team at Cadence has written a script to remove traits from 3.9. If that's useful to you let me know and I'll find the code.
* Nail the package dependencies issue provide a mechanism to get all |
In reply to this post by keith1y
On 8-Dec-2008, at 3:32 PM, Keith Hodges wrote: > I was asked for a clearer explanation... :-) so here goes... > > ========= > SakeTasks - The shortest summary I could come up with. > > A package inspired by Make and ruby's Rake. > > It runs tasks. Tasks consist of actions (blocks or tasks), in an order > as defined by dependencies (blocks or tasks), if the "ifs" (blocks > returning true/false, or tasks which succeed or fail), indicate that > the > task is necessary. ever be seen by the user (i.e. the developer who might submit change sets or projects to be reviewed for possible inclusion in an upcoming release). It might be a good foundation tool, but it's not really anything I'd want to ever use directly I don't think. What would it take to build a proper configuration management and release management tool on top of MC, SUnit, and maybe this Tasks thing? I'm thinking of something more along the lines of "Aegis" with multi- level commits and enforced unit tests, etc., etc., etc.... -- Greg A. Woods; Planix, Inc. <[hidden email]> PGP.sig (193 bytes) Download Attachment |
In reply to this post by Eliot Miranda-2
> > * Traits as standard (but removable via unload task) > > > Peter Ahe of the Newspeak team at Cadence has written a script to > remove traits from 3.9. If that's useful to you let me know and I'll > find the code. > > Matthew did the same a while back, hopefully its the same script :-) Keith |
On Mon, Dec 8, 2008 at 6:00 PM, Keith Hodges <[hidden email]> wrote:
> >> Peter Ahe of the Newspeak team at Cadence has written a script to >> remove traits from 3.9. If that's useful to you let me know and I'll >> find the code. >> >> > Matthew did the same a while back, hopefully its the same script :-) If it's called Castrait, it is. :-) --Vassili |
In reply to this post by Igor Stasenko
"Igor Stasenko" <[hidden email]> writes:
> 2008/12/8 stephane ducasse <[hidden email]>: >>> Hi, >>> >>> Off Topic: Looks like there is debate stirring among the Ruby community >>> on whether to fork Ruby to experiment with parallelization, etc. Sounds >>> awfully familiar. >> >> >> But forking is not the end, this is the start of something. Just have a look >> at what we are doing no MVC, no etoy, a lot of fixes, a lot of tests, >> TTF,..... >> > > I'd like to empasize this: > - Pharo has the clearly established nearly-achievable goals (good or > bad - depends on people's preferences) > - does Squeak has the same clearly established nearly-achievable goals? > > If yes, then why they not on squeak.org, but on > (http://installer.pbwiki.com/311) , and also, why there is still > people, like Edgar constantly attacking them, showing that there is no > consensus about future of squeak? see that anyone is "responsible" for Squeak. So everyone does what he/she likes. I for my had my share of wishes also, but I can not see that many others share those. So bad for me, but Squeak still around and growing, so enough are quite happy with Squeak as it it these days. > > I think, its important to define clearly, that EVERYONE should > understand what is the current squeak goals, so no more discussions > about them is needed. A clearly defined tasks is half of success. A sure, we don't know what future will bring but we define it. Has worked remarkable well... Regards Friedrich |
Free forum by Nabble | Edit this page |