[quagga-dev 9067] Re: Committing New Features to Master Branch?

Bahubali Shetti bshetti at isc.org
Tue Feb 14 04:01:32 GMT 2012

Hi David,

Thanks for the detail below. Your questions are well taken. I think the suggestions are appropriate and we (OSR) are just coming out of our "shell". We've only been in existence for about 5 months, and just finished the first battery of tests on the Quagga 99.20 code base, the google ISISd and google BGP patches. This helps us baseline the quality of the initial code base.

Our next step is to start fixing some critical bugs and then start analyzing the appropriate patches/features which should help Denis and others pull a proper release. I think your suggestions are valid, and we (the Quagga.net) community should implement them. OSR (www.opensourcerouting.org/wiki) can help organize and manage this. 

Denis - can you help answer some of David's questions below - it would help us, and others help you pull a proper release.


On Feb 13, 2012, at 9:21 AM, Ward, David - 0663 - MITLL wrote:

> 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?
> Specifically:
> 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 http://sourceforge.net/apps/mediawiki/quagga/?title=ReleaseEngineering but it doesn't really explain the fundamental purpose of the different branches)
> Here are a couple of (hopefully accurate) examples taken from other projects.
> 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)
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git (secondary)
> 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).
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 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).
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> 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.
> David
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20120213/5b74c9b1/attachment-0001.html>

More information about the Quagga-dev mailing list