[Squeakfoundation]Handling fixes/enhancements (was Re: Possible extra text for Welcome window in 3.4)

[Doug Way]

Tim Rowledge wrote:
> 
> goran.hultgren@bluefish.se is claimed by the authorities to have written:
> 
> > > What isn't good is that I can't quite work out what we've decided will
> > > be in the gamma release, nor _how_ we've decided it. Perhaps it's just
> >
> > I think we decided it on this list and that it includes exactly what is
> > in the beta! :-) Doug has taken quite some time/effort to post on the
> > updates we wanted to include before going into beta/gamma of 3.4 and the
> > basic intention behind it all was (also discussed on the list) to simply
> > get 3.4 out he door since it includes all the 3.3 alpha stuff (without
> > Modules of course) and more and we wanted to get a "quick release" so
> > that we can take a breath and start the real work in 3.5.
> Yes but there has been quite a number of 'last minute important fixes'
> traffic, not least a few fixes I consider important. I can't find
> anything that lets me know if those fixes are queued up anywhere - not
> even with the magical 'look at internal server' patch. Without the
> sqfixes page and its brethren I'm stuck. Terribly vexing.

As Göran said, we more or less agreed to handle the 3.4 fixes on an "ad-hoc" basis, meaning they would just be discussed on this list.  (At least, there were no strenuous objections. :-) )  See http://lists.squeakfoundation.org/pipermail/squeakfoundation/2002-November/000547.html (hm, there was more discussion about this somewhere...)

This was assuming 3.4 would be wrapped up relatively soon, then with 3.5alpha, we'd work on a better process/tools.

I posted some thoughts on possibilities for better tools here a little while ago:

http://swiki.squeakfoundation.org/squeakfoundation/86

I suppose what we're talking about here is not just a "harvesting" process, but a process for figuring out what goes into Squeak, including larger contributions from the Guides, SqC, etc.  I guess we could still use the term "harvesting" to cover all base-Squeak development?  And we also have to consider package-level harvesting as the image gets split up into packages.

> I'd suggest we need to caucus on the issue of some tools to help us
> handle fixes and changes more effectively in preparation for the
> onslaught of brilliant ideas that is likely to hit us like a tsunami for
> 3.5

True, we run the risk of being overwhelmed here if we're not careful. :)

> First suggestion I'd like to make is that the sqfixes page be changed to
> make use of more targetted editing capabilities of swiki; rather than
> having to edit the entire chunk of code, it is actually possible to have
> an edit dooberry for each individual item.
> 
> Second nice thing would be some interface so that
> a) 'ordinary' people can comment on a proposed change
> b) guides and other vouched people can comment and 'vote'
> c) the area-guide can signify yea/nay and have the change automatically
> moved to an appropriate holding area
> d) an accepted change gets the update number attached for tracking
> Probably possible with swiki or seaside?

This interface sounds similar to what I had in mind.

Göran mentioned at one point that he and Luciano N. were looking at using a modified SqueakMap as the infrastructure for this, which I think might work.  There are other ways it could be done.  I'm not sure we want to stick with the Swiki method; it may be too limiting.

In any case, we should get working on this, since 3.5alpha will be opening soon.  Perhaps Luciano could get started with something based on SqueakMap 1.05, if we want to use SqueakMap as a base for this tool.  (We definitely don't need to wait around for SM 1.1 for this.)  If we have a basic submitting/annotating/voting tool working, we can use that as a starting point for refinement of the process, which can be discussed on this list...

If others want to actively help out with getting the basic tool going, feel free to volunteer here.

- Doug