Hi guys

For me any process the people working to make squeak better and safer 
is ok. I think that enabling experts to lose less time is important.  
After we can always set up some internal or pair coding when fixing the 
kernel (I like to have more eyes over my shoulder because I can simply 
mess up).

Now I would like to add that having a **REAL** campaign for tests is 
needed else statements such as
> - Anyone committing (broadcasting) to the update stream has to run 
> SUnit tests. (which take a couple minutes).
makes me really laugh considering the kinds of bugs we could get with 
the current tests we have.

Stef




On 12 août 04, at 08:32, Doug Way wrote:

>
> On Wednesday, August 11, 2004, at 03:08 AM, Avi Bryant wrote:
>
>> On Aug 10, 2004, at 10:10 PM, Doug Way wrote:
>>
>>> Now, having read the rest of this thread and thinking about it a bit 
>>> more, I'm not totally convinced that the separate update stream is 
>>> absolutely necessary, even if we do #2 and #3.  If we enforce (via 
>>> the broadcast mechanism) that the ConflictChecker is run, and 
>>> especially if SUnit tests must pass, before an update can be 
>>> broadcasted, we could arguably avoid "major" bugs from occurring in 
>>> a single update stream.  I think SUnit tests take a minute or two to 
>>> run right now... that's probably reasonable overhead when 
>>> broadcasting an update.  (And if several updates are broadcasted at 
>>> once, SUnit tests still only need to be run once for all of them.)
>>
>> But that's no fun.  There seems to be a lot of talk about what might 
>> and might not work, when we could just be trying it out.  What's to 
>> lose?  Say we build an "unstable" stream that ends up being a 
>> complete mess - the only people that are affected are those that were 
>> tracking that stream, and they can't have been expecting much anyway.
>>
>> I suggest we try The Simplest Possible Thing, which is probably this: 
>> set up an alternate update stream, publish a code snippet that lets 
>> anyone point their image to it, and hand out the upload password to 
>> everyone with Master certification on SqP.  Then step back and see 
>> what happens.  My guess is that, like wikis, the system will be more 
>> robust than you give it credit for: if someone publishes a bad 
>> update, someone else will quickly remove it, and life will go on.
>
> That's actually not too far from what I was originally suggesting with 
> the two update streams.  (Main difference being that I also suggested 
> that only fixes/refactorings can go directly in from the committers, 
> and I think you're saying "anything goes".  Even this might not end up 
> being too different in practice.)
>
> It sounds like we have at least two competing proposals (with some 
> parts not completely defined) that we can throw tomatoes at, or 
> suggest distinct alternatives...
>
> Proposal #1:
> - Have two update streams, "unstable" and "testing".  Serious problems 
> can be fixed in the "unstable" stream before they reach the 
> more-widely-used "testing" stream.
> - The updates from the unstable stream will be moved over to the 
> testing stream periodically, when things are stable.
>
> Proposal #2:
> - Have one update stream as we do now.
> - Anyone committing (broadcasting) to the update stream has to run 
> SUnit tests. (which take a couple minutes).
>
> Features common to both proposals, which are different than what is 
> being done now:
> - Create a group of "committers" who can post updates directly to one 
> of the update streams.  Could be a combination of harvesters & guides 
> & a few others.  Arguably including everyone with Master certification 
> on SqP is the most fair way to do this.
> - Everyone else still goes through the usual BFAV process.
> - When approving an item in the BFAV, the harvester will also post it 
> directly to the appropriate update stream.
> - There might be some restrictions (by convention) on what committers 
> can post directly to the stream, e.g. only fixes & refactorings, not 
> enhancements.  To be determined.  At least, we'd like to avoid 
> obviously contentious changes.  But it any case it will be much less 
> restrictive than self-approvals are now.
> - Anyone committing to the update stream runs the ConflictChecker.  
> (It can be built in to the broadcast mechanism.  There's no reason not 
> to run it, it takes a few seconds... it only typically flags problems 
> if you're posting an old changeset.)
> (- Possibly split the bug-reporting side of BFAV into a separate tool 
> such as Mantis... this is mostly a separate issue.)
> - There are lots of other possible improvements not really related to 
> proposal #1 vs. #2... such as maybe eventually moving to .mcz files 
> instead of changesets.  These are mostly post-3.8... remember 3.8 is a 
> relatively short release for m17n.
>
>
> Which proposal is the Simplest Thing That Could Possibly Work?  You 
> could make a case for either one.  They're really a lot closer to each 
> other than they are to the current process, anyway... either way, 
> changes will be appearing in the update stream much more quickly.  
> Proposal #2 actually has the fastest turnaround to the main update 
> stream.
>
> Any feedback from Marcus and others who haven't commented on this 
> latest thread?
>
> - Doug
>
>