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

[goran.hultgren@bluefish.se]

Daniel Vainsencher <danielv@netvision.net.il> wrote:
> 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 I agree. Unless someone is actually working in alpha land of
course - I assume none is?!

Sidenote: Whenever Monticello starts working sufficiently enough I
really think that should be used instead of a stream for alpha/beta
work. Gamma and release "branches" (like 3.2.1) would still use the
update stream mechanism.


> 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. 

These rules sounds fine to me - can you jot them down on the "Harvesting
tool" page or something? Or Doug can jot them down wherever he thinks is
the appropriate place currently. (I know where the Guides hang out (our
swiki pages) but the Harvesting effort is a bit in several places...)


> 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.

In SM 1.0x I don't rely on uniqueness of UUIDs currently - I check each
new one!

But in upcoming "decentralized" SM it will start to become interesting.
And it would be a shame if I should need to choose another method - like
handing out id intervals etc. In short - UUID should either work or not
be there at all IMHO. :-)

regards, Göran