Giovanni Corriga wrote:
> Il giorno lun, 16/10/2006 alle 15.26 +0200, Philippe Marschall ha
>>I'm just saying Squeak is extremely limited on development resources.
>>There is a lot of great stuff that we could do if we had more
>>development resources but we have to work with what we have got.
>>Sometimes stuff just doesn't get maintained because the maintainer is
>>extremely busy.
> 
> 
> But that's my point too. We have limited resources, so we can't afford
> to have stuff in the image that we can't manage, that is, stuff without
> a mantainer but that we depend upon.

The process that was described sounds ideal, and should
be the goal. But the reality is that it has a fatal flaw
in that there just aren't people that step up to do the
work (for lots of good reasons). Dropping packages that
don't attract maintainers won't work if the stuff can't be
dropped.

So let's play to our strengths, instead of trying to shore
up weaknesses - the major weakness being not enough people
stepping up to maintain "excess" packages. The strengths
are that people are working on important features, without
any prodding. If we focus on coordinating and helping the
people working on:

- kernal/minimal image (Pavel's work, and Craig's Spoon)
- OmniBrowser
- Monticello2

then we'll have a basic development platform (4.0?) that can
be the target for the "excess" packages. I suspect it would
be a lot easier to build a team to port a package from 3.9,
than it would be to find a team willing to "maintain" that
package for 3.10. Even if we still don't find maintenance teams
for all packages, there's no work to drop the packages (because
they're already gone).

I'd like to see a 4.0 plan start immediately, starting with
Pavel's image, then adding compiler fixes/changes, changes/sources
file changes, new image format, etc. If Spoon, OmniBrowser,
Monticello2 can fit within the 4.0 timeline, then they'll be
included, but they're not showstoppers. Although, MC2 may be
crucial to the 4.1 phase where we'd attempt to re-package
important 3.9 packages. I think the timeline for a 4.0 release
should be 3 months, since Pavel's work is there already,
and we would be focusing only on a few pieces of code.