[quagga-dev 12602] Re: [PATCH v3 00/22] VRF support in quagga

Vincent JARDIN vincent.jardin at 6wind.com
Mon Jun 1 23:04:12 BST 2015


Paul,

 >> That's fine.
 >>
 >> Then I NACK and it doesn't go in.

 > If that happens, then you cause a retroactive fork.

It is all about moving forward without creating show stoppers since 
forks must be avoided.

Two logics:
   - many ack't of the patch vs your NACK,
   - and it does not break any next steps.

The patch does not break any logics you are arguing, it'll still be 
possible to add further capabilities. Should we do a fork or create a 
quagga-next to include all these features? And then, what's happened if 
we end up with N forks of everyone without any consensus... Sharing the 
same repo allows everyone to contribute step by step.

Zserv -> arguable, but ok TO BE DONE, current patch is not a show stopper
UI -> arguable, but ok TO BE DONE, current patch is not a show stopper
Multi daemon -> arguable, but ok TO BE DONE, current patch is not a show 
stopper
BGP VPN, Multi intance OSPF, etc. -> arguable, ok TO BE DONE, current 
patch is not a show stopper.

So, where is the problem? Why NACK? It needs arguments based on the 
proposed patches.

Best regards,
   Vincent

On 01/06/2015 23:27, Alexis Rosen wrote:
> I don't use VRFs with Quagga. While I think it would be healthy for the platform to have support, I don't need it myself, so I have no vested interest in any particular outcome here.
>
[...]

>
> If that happens, then you cause a retroactive fork. That is, there are users of this code, and many more who have expressed strong interest. It will be out there, and it will be used, because nobody has a plausible alternative. And Quagga is not Linux- those "out-of-tree patches" will likely wind up with more maintainers and coders than vanilla. That's not a healthy outcome in the short term (though in the long term might lead to a reasonably healthy Quagga++ or whatever).
>
> I have tried to follow your argument. ISTM that one of your acceptable options is getting lost in the noise - that people acknowledge that taking this patchset may be problematic later. If nobody's willing to even go that far, then maybe the right thing to do is make a new branch, take the patches, make an alpha (not beta) release, and see what other patches come along in a few months. By then, the merits of the argument might well be a lot clearer, and if not, well, I think the writing is on the wall in that case anyway.
>
> /a





More information about the Quagga-dev mailing list