"Internal" updates (was: RE: [Squeakfoundation]Possible extra text
Thu, 16 Jan 2003 01:07:57 -0500
On Wednesday, January 15, 2003, at 03:08 AM, email@example.com
> Daniel Vainsencher <firstname.lastname@example.org> wrote:
>> I'm not sure which would be better, but I'm sure of this - if you
>> into alpha it means you can afford to d/l a fresh image and update
>> 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
>> 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