Re: "Internal" updates (was: RE: Possible extra text

On Wednesday, January 15, 2003, at 03:08 AM, [email protected] 
wrote:

> Daniel Vainsencher <[email protected]> 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 generally agree.

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

Er, yes.  I think I will jot down any new harvesting-related stuff on 
the SqF/Guides pages and not the old SuperSwiki pages or anywhere else, 
so they're mostly organized in one place.

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

I agree with Daniel about the UUID fix, the new stuff in 
UUIDGenerator>>makeUnixSeed and madeSeedFromSound was too experimental 
to go in 3.4.  I didn't realize until more recently that Goran really 
just needed the flushing-on-startup part of the fix.  I'd be tempted to 
revert the makeSeed part of it, but I suppose we might as well leave it 
for now.   (Generating a UUID from the millisecond clock & date/time 
seems generally adequate to me.  I assume this wasn't the source of 
duplicates.)

- Doug