<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi David,<div><br></div><div>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.</div><div><br></div><div>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 <a href="http://Quagga.net">Quagga.net</a>) community should implement them. OSR (<a href="http://www.opensourcerouting.org/wiki">www.opensourcerouting.org/wiki</a>) can help organize and manage this.&nbsp;</div><div><br></div><div>Denis - can you help answer some of David's questions below - it would help us, and others help you pull a proper release.</div><div><br></div><div>Thanks</div><div>Bill</div><div><br></div><div><br></div><div>On Feb 13, 2012, at 9:21 AM, Ward, David - 0663 - MITLL wrote:</div><div><div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000"><p>Hi Denis, thanks for your response.</p>
    On 10/02/12 17:21, Denis Ovsienko wrote:
    <blockquote cite="mid:%3C274381328912494@web47.yandex.ru%3E" type="cite">
      <pre wrap="">09.02.2012, 22:31, "Ward, David - 0663 - MITLL" <a class="moz-txt-link-rfc2396E" href="mailto:david.ward@ll.mit.edu">&lt;david.ward@ll.mit.edu&gt;</a>:
</pre>
      <blockquote type="cite">
        <pre wrap="">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?
</pre>
      </blockquote>
      <pre wrap="">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.
</pre>
    </blockquote><p>I'm not sure that I follow what you are saying. Let me approach
      the subject a different way.</p><p>What is the fundamental purpose of each branch?</p><p>Specifically:</p>
    <ul>
      <li>What is the master branch for -- what commits belong there?
        Does it feed from/to another branch?</li>
      <li>What is the RE-testing branch for -- what commits belong
        there? Does it feed from/to another branch?<br>
      </li>
      <li>What is the RE branch for -- what commits belong there? Does
        it feed from/to another branch?</li>
    </ul><p>(I see
      <a class="moz-txt-link-freetext" href="http://sourceforge.net/apps/mediawiki/quagga/?title=ReleaseEngineering">http://sourceforge.net/apps/mediawiki/quagga/?title=ReleaseEngineering</a>
      but it doesn't really explain the fundamental purpose of the
      different branches)<br>
    </p><p><br>
    </p><p>Here are a couple of (hopefully accurate) examples taken from
      other projects.<br>
    </p><div><br class="webkit-block-placeholder"></div><p>Linux kernel:<br>
    </p>
    <ul>
      <li>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.<br>
        <a href="git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git">git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git</a>
        (primary)<br>
        <a href="git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git">git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git</a>
        (secondary)<br>
        <br>
      </li>
      <li>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).<br>
        <a href="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git">git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git</a><br>
        <br>
      </li>
      <li>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).<br>
<a href="git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git">git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git</a><br>
        <br>
      </li>
    </ul>
    Mozilla (summarized from <a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/RapidRelease/FAQ">https://wiki.mozilla.org/RapidRelease/FAQ</a>):<br>
    <ul>
      <li><a class="moz-txt-link-freetext" href="http://hg.mozilla.org/mozilla-central">http://hg.mozilla.org/mozilla-central</a><br>
        Used for general development<br>
        <br>
      </li>
      <li><a class="moz-txt-link-freetext" href="http://hg.mozilla.org/releases/mozilla-aurora">http://hg.mozilla.org/releases/mozilla-aurora</a><br>
        Branched from mozilla-central (version X.0a1)<br>
        Used in testing for a wider audience, writing non en-US
        localizations, and preffing off/backing out problematic features<br>
        <br>
      </li>
      <li><a class="moz-txt-link-freetext" href="http://hg.mozilla.org/releases/mozilla-beta">http://hg.mozilla.org/releases/mozilla-beta</a><br>
        Branched from mozilla-aurora (version X.0a2)<br>
        Used to add fixes for issues which would prevent a final release<br>
        <br>
      </li>
      <li><a class="moz-txt-link-freetext" href="http://hg.mozilla.org/releases/mozilla-release">http://hg.mozilla.org/releases/mozilla-release</a><br>
        Branched from mozilla-beta (version X.0)<br>
        Used to archive major releases; nothing is landed here<br>
        <br>
      </li>
    </ul><p>In these examples, there is a clearly defined workflow for
      experimental changes to eventually make their way into releases.&nbsp;
      The testing repositories are only for adding bugfixes, not for new
      features.&nbsp; 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.</p><p>However I don't quite grasp Quagga's workflow.&nbsp; From the outside,
      it seems that different commits are skipping around in the process
      without an obvious reason.&nbsp; 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)?&nbsp; 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)?</p><p>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.&nbsp; A lack of clarity on
      Quagga's workflow can discourage folks from trying to get outside
      changes in the baseline, in my opinion.<br>
    </p>
    [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.]<br>
    <br>
    Thanks and I would appreciate your (and others') comments.<br>
    <br>
    David<br>
  </div>

_______________________________________________<br>Quagga-dev mailing list<br><a href="mailto:Quagga-dev@lists.quagga.net">Quagga-dev@lists.quagga.net</a><br>http://lists.quagga.net/mailman/listinfo/quagga-dev<br></blockquote></div><br></div></body></html>