[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?

(I see 
but it doesn't really explain the fundamental purpose of the different 

Here are a couple of (hopefully accurate) examples taken from other 

Linux kernel:

  * 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.
    git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git (primary)

  * 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):

  * http://hg.mozilla.org/mozilla-central
    Used for general development

  * http://hg.mozilla.org/releases/mozilla-aurora
    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

  * http://hg.mozilla.org/releases/mozilla-beta
    Branched from mozilla-aurora (version X.0a2)
    Used to add fixes for issues which would prevent a final release

  * http://hg.mozilla.org/releases/mozilla-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 
my opinion.

[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...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20120213/6b3cbe3a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4558 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20120213/6b3cbe3a/attachment-0001.p7s>

More information about the Quagga-dev mailing list