The package mechanism was not the worse part....
the package responsibility and general state of cyclic dependencies  
between package
made the management more complex.

Stef


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