kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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

> This is how I would want to spend my time orchestrating the two
> branches, if I had time in the same quantities that you do.  It would
> start by lowering expectations with respect to the current-ness of the
> stable branch.
> 
> 
>>>
>>> 2) Also, I think it is harmful to have the internat directory tree
>>> present in stable.  It is now in the docs, repo.  Any objections if I
>>> delete it from stable?
>>>
>>> Dick
>> Currently, the internat directory in stable branch is the same as in
>> docs repo.
>> It can be deleted in the stable tree (in fact I did not noticed it was
>> still in the stable branch until now).
> 
> This deletion has been done by me this evening.
> 
> 
> Dick
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>