On 5/9/2010 11:32 PM, Dick Hollenbeck wrote:
jp.charras@xxxxxxxxxx wrote:
Dick Hollenbeck a écrit :
Alain Portal wrote:
<<< snipped >>>
My opinion:
Agreed, bugs should be immediately fixed, but they do NOT have to be
immediately put into stable. If stable was updated once per month, that
would be good enough for the project. Developers need to use the
testing branch, otherwise they are not really developers, they are users
lurking as developers. *We should never accept a patch against the
stable branch*.
Here is how I think of the the two branches, using a metaphor for the
two branches:
Think of an analog feedback loop with a setpoint, and the feedback loop
is subject to disturbances (other than the setpoint, i.e. non-setpoint
disturbances). The disturbances are analogous in the metaphor to new
code, bringing in bugs with each piece of new code. The output of the
loop is the "product", and is the measured variable. We need to think
of the testing branch as the feedback loop, and the stable branch as a
bucket or tank of (chemical?) product. We should only capture product
when the output is near the setpoint. That is if the feedback loop is
still oscillating, we don't capture product. Wait a month, who cares,
for the bugs to be found and wrung out, reaching setpoint again.
A great analogy that only an analog designer could truly appreciate:)
Again developers should ALL be using the testing branch, this tightens
up the feedback loop's responsiveness. When that loop is responsive,
then this means we stay nearer to setpoint more often. Again, in this
metaphor, the testing branch is a feedback loop, and the stable branch
is simply a tank of product which is captured only when we think we are
near setpoint (bug free).
The metaphor is not an exact match. In particular we will not run out
of product, meaning anybody can build the stable branch at any time.
But we have to lower expectations about it being "current". How can it
be both current and stable?
If you want to hand pick individual patches that go into stable, this is
your choice. It would not be my choice, because it is too labor
intensive. Instead I would simply delay snapshotting testing until I
suspect that most bugs have been wrung out of testing, even if this
means waiting a month between snapshots. If developers think testing is
more current, this will also incentivize them to USE testing on a daily
basis. The more folks that use testing, the more feedback we get, and
the faster bugs can be wrung out and the loop becomes more responsive
(higher gain in the metaphor). You can always choose to stabilize the
testing feedback loop by slowing down the rate at which you add
disturbances. This is possible by queuing up patches in the developer's
local repo copy, delaying submission, etc. We could make it a practice
to issue a monthly "stable" snapshot, and proclaim that testing patch
submission in week four of every month will be delayed for a week except
for bug fix patches only. Only bug fixes in week 4, then at the end of
the month another full snapshot is made.
This approach seems reasonable if the testing branch only has the minor
changes and bug fixes that have recently been committed. What is your
thinking when really disruptive changes like the DSN component library
file lexer start getting committed to testing? Do we cherry pick bug
fixes from the testing branch and merge them into stable or do we create
a new development branch to work on the disruptive changes and merge
them into testing when they are ready? The problem with cherry picking
is that once testing diverges too far from stable merging the bug fixes
from testing may become more problematic than applying a patch directly
to stable. The problem with creating special developer branches for
disruptive changes is that fewer people will use them and it will take
longer to get them into shape for the next stable release. I could
argue both sides of this problem. My preference is to use the testing
branch for all new development even if it means having to apply a minor
patch here and there against stable because it may be less work than
trying to merge bug fixes from testing. This may be one of those cases
where you have to use your best judgment and/or create some simple
guidelines (policy?) for everyone (all three of us) to follow to help
keep things consistent. The important thing is to make sure we don't
forget to apply any patch against stable that applies to testing and
reintroduce the bug in the next stable version.
Wayne
