"Internal" updates (was: RE: [Squeakfoundation]Possible extra text

Doug Way squeakfoundation@lists.squeakfoundation.org
Tue, 14 Jan 2003 01:15:44 -0500


On Monday, January 13, 2003, at 01:23 PM, Tim Rowledge wrote:

> goran.hultgren@bluefish.se appears to have written:
>
>> Daniel Vainsencher <danielv@netvision.net.il> wrote:
>> [SNIP]
>>> I think we should definitely convert, for the 3.5 cycle, to one update
>>> stream. We already have mechanisms to protect the wary - stop updating
>>> when you get to a "Continue updating for 3.5a" question.
> [snip lots]
> The problem I have with this approach is the high probability of needing
> to retract changes. How?
> a) take it out of the update stream and tell people to restart from the
> last release? Oh, and what about intermediate changes that relied on
> some parts of the retracted one?
> b) add another update that undoes it; with the added need to compensate 
> for any
> intermediate changes that have touched the same area?

I think it would probably have to be option b.  That's what SqC has done 
with changes that made it out to the public stream which then had to be 
reverted.

Getting rid of the internal update stream sounds okay to me, actually.  
If the number of "problem" updates (in need of reverting) doubles or 
triples relative to when SqC handled things, I don't think that would be 
be a big problem.  We would have retractions more frequently.  
Intermediate changes touching the same area would be reasonably rare.

> I posutlate that we need several holding areas: one (like the current
> sqfixes page but up to date) for offered changes, another for changes
> considered of interest by at least one guide and another for changes
> agreed on by at least two guides. This last would essentially be the
> internal update stream used for a last opportunity to check things. It
> _could_ be seen as an alpha stream and made accessible to any brave
> fools willing to put with whatever is the chosen solution to the above
> problem.

Something equivalent to this might be good for the harvesting tool being 
written.  But do we want to do this in the next month or so before the 
tool is finished, with the sqfixes pages?

For bug fixes, I tend to agree with Goran that approval by one 
harvester/guide (who is NOT the author of the fix) is probably 
sufficient.  Perhaps for enhancements, approval by two guides makes more 
sense.  With the harvesting tool, we could do some cool stuff like 
having approval of the quality of the source code be separate from the 
approval of the appropriateness of the fix/enhancement.

But in the meantime, we need to figure out what to do in the next few 
weeks, before any harvesting tool is ready.  Should we go ahead and make 
some sqfixes swiki tables just to get some important fixes/enhancements 
in over the next few weeks?

- Doug