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

[Daniel Vainsencher]

I'm not sure which would be better, but I'm sure of this - if you update
into alpha it means you can afford to d/l a fresh image and update again
after we've fixed the mess.

I think we really should agree to some rule like 1 reviewer for fix/2
for ENH, etc, since we're not very consistent in who's available to
handle these things, so lots of coordination will hurt us. OTOH, we
should also have a veto rule - anyone can say no, and that stands until
3 agree otherwise or he changes his mind. 

We want to be able to move forward quickly, but it's important not to
become desensitized to what goes in. As an example I noticed late that
I'm not really very happy with the fix we accepted for UUID. It makes
the quality of UUIDs hard to predict, SM, AFAICT, could live without
that being in the core, and, IMO, we just can do better - just say no to
quick satisfying hacks that'll hurt us in the morning.

Daniel

Doug Way <dway@riskmetrics.com> wrote:
> 
> 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
> 
> _______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation