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.
