3.4 Road map and Refactorings (was: [Squeakfoundation]Order of business ...)

Sat, 16 Nov 2002 01:11:55 +0300

Well, so far I got little response on the list to the 3.4 roadmap I
proposed. Here's what I proposed:
**********
Applications that should be made removable and maybe removed -
 - Celeste (I'll adapt to 3.4a and post the code for review in next few
weeks)
 - PWS (I've looked at Colins code, it looks fine except for some minor
issues I'll address in an email soon)
 - IRC (trivial)
 - Scamper (volunteers? warning - requires starting to refactor and
separate out some of the HTML/URL stuff in the image - not for the faint
of heart ;-)
 - Balloon3D (was made unloadable by Henrik in 3.3a - make sure it is
now, too)

Constraints on packages that should be removed -
 - Sockets should be usable in a "quiet" mode, so they bring up
exceptions instead of UI, letting the application decide what to do on
time outs/problems.
 - Make flaps pluggable, so applications can added their own prototype
without disturbing the users existing stuff.
 - PluggableListMorphs can and should be lightning quick, even for 10k
item lists, and they should allow their items to be colored - this is
usable by many, many packages (though the last might be better handled
as an SM package).
**********

Got feedback saying they want Flow (via IRC), and MichaelR appears to be
in the preemptive wish fulfillment business, depending on people helping
him to test his stuff - it's a complete rewrite of the protocol sockets,
so it'll take some serious testing. 

Anyone here know of other things that should/can enter 3.4? Probably not
all of the above are going to happen in 3.4. Doug, have you decided what
we're doing about the existing backlog? Luciano appears happy to help...

About the process for refactoring applications out of the image, we
bounced around some ideas and now have this sequence -
*********
* Code is refactored to make a complete package that requires no other
code changes to load/unload.
* Refactoring is posted for feedback (on list or SM) as needed.
* When it's acceptable the code is inserted into update stream, so that
code becomes removable using "remove category" in the simple case or DVS
if there are class extensions.
Then (Some unspecified time after the package starts living in SM...)
* Update is issued that performs the remove, asking the user if he wants
to reload from SM, or leave his version loaded (in case he has
modifications).
*********

Comments on the process or it's clarity, or whatever are welcome.

If it's ok with everybody, I'll post this on the Swiki and expand on
things. Then I'll also post Celeste subject to the same process. Tim,
IIUC you wish to remove VMMaker from the image? that's another
opportunity. I'll review the final PWS stuff, and after it's adapted to
3.4, I'll need some others to review the Celeste stuff, obviously.

Daniel 

danielv@netvision.net.il wrote: 
> 2. Start planning the next release, in terms of content. 
>  * I'll start a thread on the squeak-dev list to hear what people think.
> I'll also outline the process for posting refactorings as I sent to you
> guys on the internal "Re: Fwd: Re: Image factoring" thread, and see what
> people think.
>  * Doug, we need to know what's currently on the table of the former
> Harvesters group, so we can decide what to integrate, what to reject,
> and what to punt to the list and SM.
>  * If you guys have directions you want the image to take in the near
> term beyond what I summarized as "removing constraints", like a merge
> plan to VI4, or whatever, I think now would be a good time to mention
> it.
>  * After we get some inputs from all these sources, I suggest we hash
> out a basic release road map. As an initial sketch of it's shape (we'll
> have actual content later) -
>  3.4 - a quicky release to remove some constraints and test our process
> for refactoring and removing a few obvious applications from Squeak.
>  3.5 - a slightly longer release to optimize and continue the process,
> stabilize our work tools.
>  4.0 - New image format...