kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 5/10/2010 10:31 AM, Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> 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
>>   
> 
> The simplest solution is usually better.  Anything labor intensive
> concerns me.  I like to think of the stable branch as a tar file on
> steroids, complete with change notification.
> 
> 
> There really has not been any recent task completed that was not done by
> one individual, except for a few times where some fine tuning was
> applied by another person after 90 percent of the initial work was done
> by another one person.   Said differently, we are mostly working alone. 
> Bazaar supports local repos, and two or more local repos, owned by
> different persons can even be merged with a merge request.  A merge
> request can be thought of as a unit of work.
> 
> Also, when new work is added, it can be added in a conditionally
> compiled form.  We have done a lot of that in the past, using #ifdefs.

Using #ifdefs for highly experimental and compartmentalized code like
the wxGraphicsContext stuff is fine but using it for incremental changes
like the component library object refactoring I did would be painful.
If you look at this code before I started and where it is now, it is
highly unlikely that many bug fixes applied against the previous stable
version would apply to the current code.  I am planning a similar
refactoring of the schematic object code.  I expect at some point in the
future that bug fixes applied to the current stable schematic object
code will have little or no meaning in the testing branch.  Using
#ifdefs would be way too much work and require other developers to
enable the build options to help with testing.

> 
> I don't have all the answers, and as you say each case may be
> different.  But hand picking patches to throw into "stable" impresses me
> as 1) too labor intensive, and 2) too prone to error, all for relatively
> little return on investment.

Agreed.  For most bug fixes, patching the testing branch and then later
merging to stable makes sense.  The only case I can think of where it
makes sense to patch stable directly is when patch no longer applies to
testing because the offending code has been removed or changed to the
point where the patch is meaningless.

> 
> Other projects often have temporary branches that hold only a portion of
> the project, that part that is being revised.  Also, I was under the
> impression that any "branch" is really a tree with potentially different
> lines of evolution contained therein.  Am I wrong about that WRT bazaar?

I think that pretty much sums up distributed VCS's.  My concern is that
if I create a public branch to work on the refactoring described above
or the component library DSN file implementation is that no or very few
other developers will pull my work into their local branches to help
with testing.  This defeats your feedback analogy because the larger
pool of developers is not testing all of the new code in individual
branches that would have been tested in SVN head.  I'm not trying to
belabor the point here.  I want to be sure I'm not heading down one path
and everyone else is going down another.  I'm only trying to avoid
having to do things over because I misinterpreted something.

Wayne

> 
> Dick
> 
> 
> 
>