[squeak-dev] Forking

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:

On Mon, 2008-12-08 at 10:12 -0600, Tim Johnson wrote: Oh, I didn't get this far down the message for some reason before I
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
>
>
>
>

>  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

> 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,.....

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]>:

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

2008/12/8 stephane ducasse <[hidden email]>:
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.



--
Best regards,
Igor Stasenko AKA sig.

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 ...

> 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

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

see below re traits...

On 8-Dec-2008, at 3:32 PM, Keith Hodges wrote:
That doesn't look to me on first glance like something that should  
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]>

 
>
>     * 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

"Igor Stasenko" <[hidden email]> writes:
So what's the point? Does anyone have to agree with another? I can not
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