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
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
On Wed, 15 Jan 2003 goran.hultgren@bluefish.se wrote:
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.
Sigh. Eventually I'll get back to working on Monticello, honest...
Most of the work on a new version of the model is done (that will support branches, distributed repositories, reversible patches...). Maybe I'll try to release just the model sometime soon, and hope someone else can help out with the infrastructure (repositories, RPC, UI)?
On Wednesday, January 15, 2003, at 03:08 AM, goran.hultgren@bluefish.se wrote:
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 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
squeakfoundation@lists.squeakfoundation.org