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