Doug Way <dway at mailcan.com> wrote:
> On Tuesday, August 10, 2004, at 06:48 AM, danielv at tx.technion.ac.il 
> > 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:
[Some mostly automated checks that can be moved in the update tool]
[sanity checks - basic manual functional tests, maybe compensated for if
we have two streams] 
[sanity read - looking out for duplicated submissions etc]

It seems to me like the bottom line is that this work could be
distributed, with relatively simple changes to the tools, as you
describe. I think the SUnit test running should not be done by the
submitter, but by an automatic server, why waste people's time? I've
already had an automatic tests server up and running, should be pretty
easy to integrate into the process. And then I don't see any benefit in
a second stream, other than insurance against everything going 
haywire (which I'm not sure we need).

I think in social terms, the idea of giving direct access to everyone
that's Master on SqP, and removing the Guides as bottlenecks on the
integration process, is *great*. It is an experiment, it might fail, but
I don't think it will. 

In term of what the process should look like, and how to do the
transition, this is what I would propose:
1. Give everyone that's Master on SqP harvester status, with the
understanding that at the moment, the rules and process described in the
Swiki apply.
2. Integrate the ConflictChecker and update broadcasting code, and the
extra checks you mentioned into the BFAV, so the whole process happens
from one place. From that moment, approvers can decide either to approve 
a change, or to publish it directly.
3. Allow each user to decide by how many days he wants his updates to
lag compared to the update stream. Default at a week or so. I think this
is a more general solution than the "two streams" based ones, and with
less mechanisms to manage. Might require a little code changes to have
the update index include the dates.
4. Make the convention that during beta, one only sends updates if they
are seriously intended for it. Generally, any publishing should happen
only after considering the current state of the stream. For example, if
we have destabilizing changes in some area, don't conflate them with
other unrelated changes to close subsystems. 
5. After the social and tool changes quiet down, and we've settled down
some in the new state, talk about what rules need relaxing or whether to
simply replace them. I think the rules need to fit the social/technical
context, so it doesn't make sense to change them first.

Daniel