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
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
