"Internal" updates (was: RE: [Squeakfoundation]Possible extra text
Tue, 14 Jan 2003 01:15:44 -0500
On Monday, January 13, 2003, at 01:23 PM, Tim Rowledge wrote:
> email@example.com appears to have written:
>> Daniel Vainsencher <firstname.lastname@example.org> wrote:
>>> 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
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
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?