squeak releases, now and in the future
stephane.ducasse at free.fr
Wed Jan 23 19:42:59 UTC 2008
The package mechanism was not the worse part....
the package responsibility and general state of cyclic dependencies
made the management more complex.
On Jan 21, 2008, at 11:41 PM, Matthew Fulmer wrote:
> 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
>>> 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
>> place in this arena.
> Also, don't forget that 3.10 was entirely a bug-fix/maintenance
>> 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
>> portions of work towards future releases.
>> Within LevelPlayingField there are spaces for several projects that
>> 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
More information about the Squeak-dev