squeak releases, now and in the future

> Hi all,
>
> I think we are at the anniversary of the start of the
> six month timebox for 3dot10.
>
> I am watching a lot of interesting developments.
> Damiens efforts seem to have become squeak's flagship.
> And VPRI has found resources and interest in
> developing
> squeaklands branch of 3.8 and OPLC.
>
> As for our squeak-org branch, it seems to me the basic
> maintenence and releases of squeak are in neglect.
>  

> Jerome Peace wrote:
> > Hi all,
> >
> > I think we are at the anniversary of the start of the
> > six month timebox for 3dot10.
> >
> > I am watching a lot of interesting developments.
> > Damiens efforts seem to have become squeak's flagship.
> > And VPRI has found resources and interest in
> > developing
> > squeaklands branch of 3.8 and OPLC.
> >
> > As for our squeak-org branch, it seems to me the basic
> > maintenence and releases of squeak are in neglect.
> >  
> I do not entirely agree with this conclusion since there is work taking
> place in this arena.

> The release team has struggled for two releases, as more and
> more forks of squeak emerge and gain relevance. If any lesson
> has been learned, it is that the tools to build a single release
> image do not work the same when applied to the very forked world
> that squeak is and is becoming.
>
> On Mon, Jan 21, 2008 at 05:00:41PM +0000, Keith Hodges wrote:
> > Jerome Peace wrote:
> > > Hi all,
> > >
> > > I think we are at the anniversary of the start of the
> > > six month timebox for 3dot10.
> > >
> > > I am watching a lot of interesting developments.
> > > Damiens efforts seem to have become squeak's flagship.
> > > And VPRI has found resources and interest in
> > > developing
> > > squeaklands branch of 3.8 and OPLC.
> > >
> > > As for our squeak-org branch, it seems to me the basic
> > > maintenence and releases of squeak are in neglect.
> > >
> > I do not entirely agree with this conclusion since there is work taking
> > place in this arena.
>
> Also, don't forget that 3.10 was entirely a bug-fix/maintenance
> release.
>
> > The LevelPlayingField initiative is aiming to provide a
> > platform/framework whereby we can care for all of the squeak.org
> > releases that we use. This also provides one framework for integrating
> > portions of work towards future releases.
> >
> > Within LevelPlayingField there are spaces for several projects that will
> > contribute to a future release, and so really there is no stagnation at
> > all, and there is plenty of room for many others to contribute.
>
> I think the big goal for 3.11 should be to embrace what squeak
> is (a community of cooperating system forks, exploring many
> fronts at once), and not what other projects may be (a
> single-mission project with a well-defined audience). This
> exactly the spirit that is driving Level Playing Field and Delta
> Streams. Level Playing Field has been in development for two
> years and is ready for prime-time. Delta Streams is still is
> alpha stage.
>
> Is  Squeak a  production-ready stable platform for developing
> large services? Yes! Is Squeak a platform for children to
> experiment with? Yes! Is Squeak malleable playground for
> researchers to implement the coolest developer tools? Yes!
> Should the release team focus on one facet at the expense of the
> others? No!
>
> Forks can have drawbacks when the tools or politics stifle
> communication and trade between the forks. Unlike many projects,
> Squeak does not have political or social barriers to stifle
> trade among forks of the system, but the tools for building and
> maintaining images (Monticello and the update stream) have
> barriers that dull their edges when applied to multiple forks.
> Update streams are a wonderful tool for building and upgrading
> images, but were built back when squeak was a Monarchy (Long
> live king Dan!) and does not deal at all with either multiple
> update sources or with incompatible recipient images. Delta
> Streams address these problems and more.
>
> Monticello is great for sharing code among everybody, but has a
> sore spot when the receiver or loader is not what is expected.
> Level Playing Field addresses these system nuances so that a
> target system is much more likely able to properly load a
> package built for another system.
>
> And the newest tool, Installer, is able to apply the work that
> code developers have already done in packaging up their projects
> in easily installable forms (whether it be SqueakSource,
> SqueakMap, Universes, change sets, packages, or whatever), and
> in a single line of code make it into an installation
> script.This will take the very boring, non-productive job of
> repackaging code for a specific fork away from the release team,
> and make the job of coordinating developers with release goals
> both easier and, most importantly, more FUN.
>
> > > My druthers are that time boxes get honored. That
> > >
> > I myself am not such a stickler for timeboxes, I think you
> > could effectively time box bug-fix releases. I do believe that
> > improvements in tools will make everything a lot easier. The
> > tools that need improvement are not part of the squeak
> > kernel/core so it is not surprising that the kernel is not
> > being looked after as perhaps it might be until those tools
> > are complete.
>
> Squeak is NOT an application that you download, use, and
> upgrade. It is much more like a community portal to lots of
> people, ideas, tools, and code made available to you for your use
> and enjoyment. I think it should therefore have more of a
> service-type release process (we have many different varieties
> to suite your needs, and we have them all working and up to
> date; and there is a special  going on with this one right now),
> rather than the ill-fitting application-style release process
> used currently (This specific fork is the real deal; all those
> others are handled by someone else (who often never exists)).
>
> Once DeltaStreams is working, applicable bug-fixes and
> zero-impact changes (like all-important Code-Comments) will be
> distributed ed on a push basis with automatic background
> installation and upgrade, or at most a single-button push to
> "review and install subscribed updates". And, thanks to
> Installer, this could be run once-a-week on the images at
> ftp.squeak.org as a Cron job to ensure that the official
> images are in pristine shape on download.
>
> > I then propose that the "official" release team be comprised
> > of people who have been taking an active role in the process,
> > and who use #squeak irc communications regularly so as to
> > encourage many more contributors and to faclitate online
> > teamwork. Gjallar has used this model reasonably successfully.
>
> I definitely think that this is a much better team model than 3.10 had
> (which was mostly done behind closed doors). #squeak IRC channel
> is a pretty active place, and all manners of viewpoints are
> readily available there. Quite a few bugs get discussed and
> fixed there, since feedback is so fast.
>
> The release team has taken large steps toward modularity and a
> many-faceted Squeak world with the switch to Monticello, and has
> learned a lot in the process, and had many headaches. It is now
> time to take a hint from the lessons learned, and chase down the
> headaches that still remain, and stop them at the source:
> ill-fitting tools.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>
>

> The release team has struggled for two releases, as more and
> more forks of squeak emerge and gain relevance. If any lesson
> has been learned, it is that the tools to build a single release
> image do not work the same when applied to the very forked world
> that squeak is and is becoming.
>
> On Mon, Jan 21, 2008 at 05:00:41PM +0000, Keith Hodges wrote:
>> Jerome Peace wrote:
>>> Hi all,
>>>
>>> I think we are at the anniversary of the start of the
>>> six month timebox for 3dot10.
>>>
>>> I am watching a lot of interesting developments.
>>> Damiens efforts seem to have become squeak's flagship.
>>> And VPRI has found resources and interest in
>>> developing
>>> squeaklands branch of 3.8 and OPLC.
>>>
>>> As for our squeak-org branch, it seems to me the basic
>>> maintenence and releases of squeak are in neglect.
>>>
>> I do not entirely agree with this conclusion since there is work  
>> taking
>> place in this arena.
>
> Also, don't forget that 3.10 was entirely a bug-fix/maintenance
> release.
>
>> The LevelPlayingField initiative is aiming to provide a
>> platform/framework whereby we can care for all of the squeak.org
>> releases that we use. This also provides one framework for  
>> integrating
>> portions of work towards future releases.
>>
>> Within LevelPlayingField there are spaces for several projects that  
>> will
>> contribute to a future release, and so really there is no  
>> stagnation at
>> all, and there is plenty of room for many others to contribute.
>
> I think the big goal for 3.11 should be to embrace what squeak
> is (a community of cooperating system forks, exploring many
> fronts at once), and not what other projects may be (a
> single-mission project with a well-defined audience). This
> exactly the spirit that is driving Level Playing Field and Delta
> Streams. Level Playing Field has been in development for two
> years and is ready for prime-time. Delta Streams is still is
> alpha stage.
>
> Is  Squeak a  production-ready stable platform for developing
> large services? Yes! Is Squeak a platform for children to
> experiment with? Yes! Is Squeak malleable playground for
> researchers to implement the coolest developer tools? Yes!
> Should the release team focus on one facet at the expense of the
> others? No!
>
> Forks can have drawbacks when the tools or politics stifle
> communication and trade between the forks. Unlike many projects,
> Squeak does not have political or social barriers to stifle
> trade among forks of the system, but the tools for building and
> maintaining images (Monticello and the update stream) have
> barriers that dull their edges when applied to multiple forks.
> Update streams are a wonderful tool for building and upgrading
> images, but were built back when squeak was a Monarchy (Long
> live king Dan!) and does not deal at all with either multiple
> update sources or with incompatible recipient images. Delta
> Streams address these problems and more.
>
> Monticello is great for sharing code among everybody, but has a
> sore spot when the receiver or loader is not what is expected.
> Level Playing Field addresses these system nuances so that a
> target system is much more likely able to properly load a
> package built for another system.
>
> And the newest tool, Installer, is able to apply the work that
> code developers have already done in packaging up their projects
> in easily installable forms (whether it be SqueakSource,
> SqueakMap, Universes, change sets, packages, or whatever), and
> in a single line of code make it into an installation
> script.This will take the very boring, non-productive job of
> repackaging code for a specific fork away from the release team,
> and make the job of coordinating developers with release goals
> both easier and, most importantly, more FUN.
>
>>> My druthers are that time boxes get honored. That
>>>
>> I myself am not such a stickler for timeboxes, I think you
>> could effectively time box bug-fix releases. I do believe that
>> improvements in tools will make everything a lot easier. The
>> tools that need improvement are not part of the squeak
>> kernel/core so it is not surprising that the kernel is not
>> being looked after as perhaps it might be until those tools
>> are complete.
>
> Squeak is NOT an application that you download, use, and
> upgrade. It is much more like a community portal to lots of
> people, ideas, tools, and code made available to you for your use
> and enjoyment. I think it should therefore have more of a
> service-type release process (we have many different varieties
> to suite your needs, and we have them all working and up to
> date; and there is a special  going on with this one right now),
> rather than the ill-fitting application-style release process
> used currently (This specific fork is the real deal; all those
> others are handled by someone else (who often never exists)).
>
> Once DeltaStreams is working, applicable bug-fixes and
> zero-impact changes (like all-important Code-Comments) will be
> distributed ed on a push basis with automatic background
> installation and upgrade, or at most a single-button push to
> "review and install subscribed updates". And, thanks to
> Installer, this could be run once-a-week on the images at
> ftp.squeak.org as a Cron job to ensure that the official
> images are in pristine shape on download.
>
>> I then propose that the "official" release team be comprised
>> of people who have been taking an active role in the process,
>> and who use #squeak irc communications regularly so as to
>> encourage many more contributors and to faclitate online
>> teamwork. Gjallar has used this model reasonably successfully.
>
> I definitely think that this is a much better team model than 3.10 had
> (which was mostly done behind closed doors). #squeak IRC channel
> is a pretty active place, and all manners of viewpoints are
> readily available there. Quite a few bugs get discussed and
> fixed there, since feedback is so fast.
>
> The release team has taken large steps toward modularity and a
> many-faceted Squeak world with the switch to Monticello, and has
> learned a lot in the process, and had many headaches. It is now
> time to take a hint from the lessons learned, and chase down the
> headaches that still remain, and stop them at the source:
> ill-fitting tools.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>
>