[quagga-dev 9061] Re: Committing New Features to Master Branch?
Ward, David - 0663 - MITLL
david.ward at ll.mit.edu
Mon Feb 13 17:21:59 GMT 2012
Hi Denis, thanks for your response.
On 10/02/12 17:21, Denis Ovsienko wrote:
> 09.02.2012, 22:31, "Ward, David - 0663 - MITLL"<david.ward at ll.mit.edu>:
>> Quagga maintainers,
>> Would it be possible to commit new features to the master branch at the same time as (or before) committing them to the RE-testing branch?
> Hello, David.
> Well, this is technically possible, of course. But this effectively means further drop of quality for the master branch. I cannot currently afford dealing with the consequences of that. The problem exists, but RE-testing-0.99 is slowly converging with the master branch, that is, master commits go into RE-testing-0.99, which mitigates the problem to some extent. If you have a better vision of this, please share.
I'm not sure that I follow what you are saying. Let me approach the
subject a different way.
What is the fundamental purpose of each branch?
* What is the master branch for -- what commits belong there? Does it
feed from/to another branch?
* What is the RE-testing branch for -- what commits belong there? Does
it feed from/to another branch?
* What is the RE branch for -- what commits belong there? Does it feed
from/to another branch?
but it doesn't really explain the fundamental purpose of the different
Here are a couple of (hopefully accurate) examples taken from other
* New code lands into a subsystem tree (whenever applicable; for
example, the networking subsystem). There may be secondary trees for
staging changes targeted for later releases; these are eventually
fed back into the primary tree.
* The primary subsystem trees are periodically merged into the main
tree, and all the subsystem changes are tested together. Tags on
this tree become major releases (2.6.x or 3.x).
* Major releases become branches in the stable tree. Important
security/bug fixes are selectively backported onto these branches.
Tags on this tree become minor releases (2.6.x.y or 3.x.y).
Mozilla (summarized from https://wiki.mozilla.org/RapidRelease/FAQ):
Used for general development
Branched from mozilla-central (version X.0a1)
Used in testing for a wider audience, writing non en-US
localizations, and preffing off/backing out problematic features
Branched from mozilla-aurora (version X.0a2)
Used to add fixes for issues which would prevent a final release
Branched from mozilla-beta (version X.0)
Used to archive major releases; nothing is landed here
In these examples, there is a clearly defined workflow for experimental
changes to eventually make their way into releases. The testing
repositories are only for adding bugfixes, not for new features. You do
not see changes added to Linux kernel 3.1.y that are not already part of
(or superseded in) Linux kernel 3.2.
However I don't quite grasp Quagga's workflow. From the outside, it
seems that different commits are skipping around in the process without
an obvious reason. I'm concerned that this is perhaps to avoid a larger
underlying issue (what are the "difficulties experienced in the master
branch" that are referred to on the wiki)? Is there code in some Quagga
tree that doesn't belong there yet and is prohibiting development/QA,
and should be moved back into a less mature tree (possibly an
individual's own git repo)?
Again, please understand that a large part of my motivation for asking
these questions is that I would like to see that there is a path for
externally-developed features (such as OSPFv3 MDR, PIM SM, and others)
to make their way into releases of Quagga, as well as for Quagga to
stabilize at the same time. A lack of clarity on Quagga's workflow can
discourage folks from trying to get outside changes in the baseline, in
[Disclaimer: I primarily use Quagga to carry out networking research,
and my contributions have been limited to submitting minor patches when
things don't work as expected. I do not follow everything that goes
across the mailing lists, but I try to skim the archives once in a while
to maintain some awareness. I do not consider myself a software engineer
and am not well versed on the effectiveness of differing workflows in
software development teams.]
Thanks and I would appreciate your (and others') comments.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4558 bytes
Desc: S/MIME Cryptographic Signature
More information about the Quagga-dev