[quagga-dev 9041] Committing New Features to Master Branch?

Ward, David - 0663 - MITLL david.ward at ll.mit.edu
Thu Feb 9 18:31:22 GMT 2012

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? 
Having new features initially only in RE-testing limits their testing 
exposure and may keep people who run the master branch from discovering 
bugs earlier, before releases. I understand that maintainer time is 
limited, but if a patch for RE-testing also applies cleanly to master, 
can it just be committed to both branches?

Part of the reason I am asking is that I also use some extensions to 
Quagga that are developed externally:
  - OSPFv3 MDR (http://cs.itd.nrl.navy.mil/work/ospf-manet/)
  - PIM SM (http://www.nongnu.org/qpimd/)

These external branches are based off of master, not RE-testing, which 
makes sense as they are experimental in nature. As a researcher, I would 
like to be able to, for example, try out the Babel routing protocol 
alongside OSPFv3 MDR in wireless networks. However, Babel is in 
RE-testing and not master, and trying to integrate the code bases in 
order to build one copy of Quagga gets unnecessarily difficult because 
of this.

(Of course, it would be ideal if the above extensions could make their 
way into the mainline Quagga at some point... I'm not sure what the 
right timing or process would be for something like that, and I am not 
their maintainer.)

At the moment, the following patch groups have been applied to 
RE-testing-0.99 but not to master:
  - Babel routing protocol
  - fortify packet reception in ospfd
  - ospfd - redistribute maximum-prefix support
  - isisd - assorted patches

... specifically, the following 69 commits:

54bf990 03a920c d83bf5a 30a7558 dfafeae b775c38 9632e3e daa3917 5470d65 
30313b8 880e7a0 2e58f61 d30b3c8 89fe5f0 77dfc02 e97660a 6f51782 90aed99 
827fc1f 8545b9f 95f09bb 182f272 7840185 6651b90 cf117fa dad9b68 ebf2dcd 
e3a09fe acf0506 f367f14 2ba58f8 5060b88 d7d46e2 39d6c0a a883d63 fced3bd 
ebe42d2 46ed3dc f05fecd 6b3580c 10a1705 d387956 ce7edd8 baaa9a5 d50b8a7 
94a132b d113f0e c415562 e4e3f3e 72ba2f5 0dc0752 867d5d5 8bfb3d8 f3341f4 
c3d60dd 1a330df 5975c38 11f5e70 752053a 459e547 13d87f0 e057865 5dcbc04

I was able to cherry-pick all of these commits cleanly onto the master 
branch and build it without any issues. Could these go ahead and be 
committed to master?

Other thoughts?


-------------- 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/20120209/3aa14fc5/attachment-0001.p7s>

More information about the Quagga-dev mailing list