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

Denis Ovsienko infrastation at yandex.ru
Fri Feb 10 22:21:34 GMT 2012


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.

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

These convergence concerns are fully understood. A working way is to reduce the big problem in measured steps, that is, to act case by case. Please see below.

> 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.
>

Tom Goff seems to be the most experienced person in MANET-MDR in this project, if he could map the required changes in a way, that would help a lot. In particular, it is important to understand, which changes require special attention and which are relatively safe, at least as long as the functionality remains unactivated.

> (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

It's still too hot, at least today. The commit log says it all. Once a preview-grade implementation is ready, it won't be delayed.

>   - fortify packet reception in ospfd

This work is only partly finished, the progress is tracked in bug #705.

>   - ospfd - redistribute maximum-prefix support

This patchset seems to be complete. However, I must note, that the ecosystem behind redistributed prefixes in ospfd is far more complicated, than it may seem. I found it appropriate to put this code under some meaningful pressure. This has already taken several months, and I hope to see this story ended in a few weeks.

>   - isisd - assorted patches

I hope, Google IS-IS experts can help here.

-- 
    Denis Ovsienko



More information about the Quagga-dev mailing list