(should have responded to this one earlier...)

On Tuesday, August 10, 2004, at 06:48 AM, danielv at tx.technion.ac.il 
wrote:

> ...
>
> Having multiple publishers to the regular stream is a significant
> change, in that it would remove the role Doug is playing during the
> alpha stage. Doug, what responsibilities exactly would this devolve 
> unto
> the approvers?

Early on I was doing a bit more manual work, but it now more or less 
boils down to a few things:

- Run the ConflictChecker and if there are one or two simple conflicts, 
fix them.  If there are a lot of conflicts (which is rare), don't 
incorporate it and kick it back to the original author to fix the 
conflicts.
- Check for a few other things like missing method timestamps, 
existence of linefeeds. (this is actually done by the ConflictChecker)  
Awhile ago, I would also try to add a quick preamble to the changeset 
if one was missing, but I haven't done that lately.  (This should be 
automated so that a preamble must be present for approval.)
- Just a final sanity check test after the soon-to-be-updates are 
installed in the image.  Opening a browser, opening SM and installing 
one package.  Basically makes sure an update doesn't totally break the 
image.
- An extra person taking a look at each changeset (just the preamble 
really) for several seconds to make sure e.g. something doesn't go in 
to re-fix a problem which was just fixed a few updates ago.  Only I 
would usually notice this since I look at every update. (a somewhat 
rare problem)

The first two parts could be spread to multiple updaters pretty easily 
by building the ConflictChecker into the update-broadcasting mechanism. 
  And also adding some additional automated verifications would be good 
(changeset preamble must exist, any newly defined class must have a 
class comment, etc).

The final sanity check might not be done by everyone.  But having two 
update streams might compensate for that.  Or, running unit tests would 
more than compensate.

The "extra person looking at each changest" may or may not be all that 
important.

> alternately, if we go for two streams, what do you think
> should happen between the approver publishing a fix to the unstable
> stream, and you releasing the updates to the main stream?

Good question.  Perhaps this is where SUnit tests should be run, at a 
minimum, to make sure nothing new has broken since the last release of 
updates to the main stream.  Otherwise, just a vague feeling that 
things are "stable", would be a reason to move the updates to the main 
stream..  (I agree that deciding exactly when to do this could be a bit 
of a headache sometimes.  Perhaps this task could be done by more than 
just myself.)

> Another question is what happens during beta/gamma. Until now, 
> approvers
> would simply continue their work, and Doug could implicitly ignore
> "too-alpha" approved changes until the next cycle begins. Maybe the
> approvers should have both options "approve"/"approve and publish", and
> would simply refrain from publishing non-fixes during beta/gamma.

Yes, good question.  Some publishers would probably occasionally forget 
that we're in beta and publish a too-alpha change.  Er, maybe 
publishing rights would be disabled during beta?  Er, ah, or the 
internal stream could track the next alpha, or something.

- Doug