[quagga-dev 15348] Re: Patch Submittal Process Going Forward Discussion.
On 20 May 2016, at 2:38, Paul Jakma wrote: […] - "resolve issues at a faster rate", by which you really mean "Ignore having to address the former". On unanimity, I disagree with you. If we regularly have patches being pushed through by the vote of the 51+% of contributors over objections of others, we're going to run into really deep problems working togehter. We'd be much better working hard at engaging and trying to keep each other happy, than trying to come up with simple majority voting structures. Also, there can be some issues I simply am not prepared to devolve to simple majority votes. There are some things that are red-lines for me. I can well accept that others have red-lines too, and in general try to respect that (do you know how many patches I never got in? :) ). Unanimous agreement on inclusion (or rollback to a last 'good' state in some edge cases) is the only way to accommodate that. Can you clarify? Is the “simple majority” the issue for these “some issues” and it could be solved for these issues with a super majority (i.e. 67%) or do you need/want unanimous agreement on these? If you think it needs a “unanimous agreement”, then could you come up with an example of an issue where you see the need for? - Martin ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15347] Re: OSPF SPF config knob
STP has detected a loop in discussion :) On Fri, May 20, 2016 at 04:03:32PM +0100, Paul Jakma wrote: > If the driving concern is the risk of routing loops for users, then we > should avoid exposing ones not exposed currently with any change, as > much as possible. I still believe the set size of Quagga monoculture users impacted by moving to RFC behaviour is sufficiently close to zero, while at the other hand the to-be-fixed current impact on mixed-implementation installations is at least existent; which brings me back around to => On Fri, May 20, 2016 at 04:03:32PM +0100, Paul Jakma wrote: > On Fri, 20 May 2016, David Lamparter wrote: > > The event most likely to change my opinion on this is being presented > > with an actual real-world setup that sees breakage from this. From > > the way this bug works, I guess it'd need to be a Quagga-only > > production network. -David ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15346] Re: OSPF SPF config knob
On Fri, 20 May 2016, David Lamparter wrote: The event most likely to change my opinion on this is being presented with an actual real-world setup that sees breakage from this. From the way this bug works, I guess it'd need to be a Quagga-only production network. The concern was with mixed behaviour networks. By just flipping the default, we may then create mixed behaviour networks which otherwise wouldn't have been. If the driving concern is the risk of routing loops for users, then we should avoid exposing ones not exposed currently with any change, as much as possible. I.e., in fixing the issue for those affected, it would be good not to impose it on those not affected currently. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Confession is good for the soul, but bad for the career. ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15345] Re: OSPF SPF config knob
The bug was reported to us by a customer ~4 years ago when they were doing some rfc compliance testing across a mixed vendor environment. We fixed it for them. We have not heard anything since then. donald On Fri, May 20, 2016 at 10:40 AM, David Lamparter wrote: > Btw: Donald -- this patch is very early in the Cumulus tree; I assume > it's been part of previous stable releases that are in active use at > customer installations? Have you received any reports of breakage? > > -David > > On Fri, May 20, 2016 at 04:37:37PM +0200, David Lamparter wrote: > > On Fri, May 20, 2016 at 02:12:51PM +0100, Paul Jakma wrote: > > > Could we agree that at a minimum there needs to be a config knob, so > > > admins can at least manage rolling out updates without introducing > > > mixed-environments? > > > > I haven't seen any technical argument that led me to change my opinion > > on migration, i.e. I still strongly believe this needs to be fixed ASAP, > > getting RFC-compliant behaviour without user interaction. That means > > I'm continuing to oppose patches that don't make RFC behaviour the > > default. > > > > The event most likely to change my opinion on this is being presented > > with an actual real-world setup that sees breakage from this. From the > > way this bug works, I guess it'd need to be a Quagga-only production > > network. > > > > If there is an additional default-off "ospf spf-maxcost-quagga" switch, > > I don't see a problem with that. > > > > > I think more transparent migration that avoids exposing Quagga networks > > > (currently fine) to any loop risk, ought to be possible, e.g. with RIs > > > (which we'd have to support at some stage even for H-bit), but that can > > > be another discussion. > > > > Funnily enough, the prefixes for which traffic could loop in a mixed > > setup are the prefixes which would default to a less specific route if > > the router to be maintenance'd is fully removed; i.e. it's the prefixes > > for which service is likely degraded anyway... > > > > > > -David > > > > > > > From 8142989d465d6dd2e41b0bb7a17069b5c0c3a8bb Mon Sep 17 00:00:00 2001 > > > From: Paul Jakma > > > Date: Fri, 20 May 2016 09:54:34 +0100 > > > Subject: ospfd: Add compatibility setting for max-cost link SPF > behaviour > > > > > > * Quagga OSPF has long treated max-cost links as not suitable for > > >inclusion into the transit SPF tree (doesn't affect reachability of > > >the node itself). Other implementations treat it as just another > > >cost. > > > > > >In mixed environments there is therefore a risk of routing loops. > > >It may be a rare risk, though when hit it could be quite > > >troublesome. > > > > > >Just flipping the default would not address that risk. It need not > > >fix the risk on networks currently exposed, while exposing other > > >networks to the risk that would otherwise not be affected. Which > > >administrators of the latter networks might find less than ideal. > > > > > >TBD: A good transition strategy, that avoids bothering currently > > >unaffected networks with this problem. E.g. RIs could be used to > > >transparently do the right thing for a greater number of networks > > >and minise the risks. > > > > > >Also, the OSPF WG are standardising a method to signal Quagga's > > >current behaviour conformantly. So it might also be good to > > >minimise churn in behaviour, but that depends on when that comes > > >along. > > > > > >Regardless, it would be good to at least give administrators who > > >are exposed a configuration setting. > > > > > > * ospfd.h: Add a OSPF_MAX_METRIC_LINK_FOLLOW flag to (struct ospf). > > > * lib/libospf.h: Add OSPF_OUTPUT_COST_MAX, and a > > >OSPF_OUTPUT_COST_DISCOURAGE - latter metric works universally to > > >signal 'discourage but still allow transit'. > > > > > > * ospf_lsa.c: (ospf_link_cost) Use the DISCOURAGE cost to signal > > >stub-router, if SPF is set to 'follow'. These are somewhat > > >separate, and with ways to signal the transit/no-transit intent of > > >the local router this might be done differently, but for this patch > > >probably best done together. > > > > > > * ospf_spf.c: (ospf_spf_next) make the behaviour on max-cost links > > >configurable. > > > > > > * ospf_vty.c: (show_ip_ospf) Print the status of the SPF max-cost > > >behaviour in 'show ip ospf'. > > > > > >(ospf_compatible_max_metric) Add "compatible max-metric > > >(infinite|follow)" to control the SPF behaviour. > > > > > >(no_ospf_compatible_max_metric) clear back to default, which will > > >still be written out explicitly, as below. > > > > > >(config_write_stub_router) Write out the config for the "compatible > > >max-metric (infinite|follow)" flag. In this version, the flag > > >state is always written out explicitly - the default state is not > > >suppressed. There's pros and cons to this of course. > > >
[quagga-dev 15344] Re: OSPF SPF config knob
Btw: Donald -- this patch is very early in the Cumulus tree; I assume
it's been part of previous stable releases that are in active use at
customer installations? Have you received any reports of breakage?
-David
On Fri, May 20, 2016 at 04:37:37PM +0200, David Lamparter wrote:
> On Fri, May 20, 2016 at 02:12:51PM +0100, Paul Jakma wrote:
> > Could we agree that at a minimum there needs to be a config knob, so
> > admins can at least manage rolling out updates without introducing
> > mixed-environments?
>
> I haven't seen any technical argument that led me to change my opinion
> on migration, i.e. I still strongly believe this needs to be fixed ASAP,
> getting RFC-compliant behaviour without user interaction. That means
> I'm continuing to oppose patches that don't make RFC behaviour the
> default.
>
> The event most likely to change my opinion on this is being presented
> with an actual real-world setup that sees breakage from this. From the
> way this bug works, I guess it'd need to be a Quagga-only production
> network.
>
> If there is an additional default-off "ospf spf-maxcost-quagga" switch,
> I don't see a problem with that.
>
> > I think more transparent migration that avoids exposing Quagga networks
> > (currently fine) to any loop risk, ought to be possible, e.g. with RIs
> > (which we'd have to support at some stage even for H-bit), but that can
> > be another discussion.
>
> Funnily enough, the prefixes for which traffic could loop in a mixed
> setup are the prefixes which would default to a less specific route if
> the router to be maintenance'd is fully removed; i.e. it's the prefixes
> for which service is likely degraded anyway...
>
>
> -David
>
>
> > From 8142989d465d6dd2e41b0bb7a17069b5c0c3a8bb Mon Sep 17 00:00:00 2001
> > From: Paul Jakma
> > Date: Fri, 20 May 2016 09:54:34 +0100
> > Subject: ospfd: Add compatibility setting for max-cost link SPF behaviour
> >
> > * Quagga OSPF has long treated max-cost links as not suitable for
> >inclusion into the transit SPF tree (doesn't affect reachability of
> >the node itself). Other implementations treat it as just another
> >cost.
> >
> >In mixed environments there is therefore a risk of routing loops.
> >It may be a rare risk, though when hit it could be quite
> >troublesome.
> >
> >Just flipping the default would not address that risk. It need not
> >fix the risk on networks currently exposed, while exposing other
> >networks to the risk that would otherwise not be affected. Which
> >administrators of the latter networks might find less than ideal.
> >
> >TBD: A good transition strategy, that avoids bothering currently
> >unaffected networks with this problem. E.g. RIs could be used to
> >transparently do the right thing for a greater number of networks
> >and minise the risks.
> >
> >Also, the OSPF WG are standardising a method to signal Quagga's
> >current behaviour conformantly. So it might also be good to
> >minimise churn in behaviour, but that depends on when that comes
> >along.
> >
> >Regardless, it would be good to at least give administrators who
> >are exposed a configuration setting.
> >
> > * ospfd.h: Add a OSPF_MAX_METRIC_LINK_FOLLOW flag to (struct ospf).
> > * lib/libospf.h: Add OSPF_OUTPUT_COST_MAX, and a
> >OSPF_OUTPUT_COST_DISCOURAGE - latter metric works universally to
> >signal 'discourage but still allow transit'.
> >
> > * ospf_lsa.c: (ospf_link_cost) Use the DISCOURAGE cost to signal
> >stub-router, if SPF is set to 'follow'. These are somewhat
> >separate, and with ways to signal the transit/no-transit intent of
> >the local router this might be done differently, but for this patch
> >probably best done together.
> >
> > * ospf_spf.c: (ospf_spf_next) make the behaviour on max-cost links
> >configurable.
> >
> > * ospf_vty.c: (show_ip_ospf) Print the status of the SPF max-cost
> >behaviour in 'show ip ospf'.
> >
> >(ospf_compatible_max_metric) Add "compatible max-metric
> >(infinite|follow)" to control the SPF behaviour.
> >
> >(no_ospf_compatible_max_metric) clear back to default, which will
> >still be written out explicitly, as below.
> >
> >(config_write_stub_router) Write out the config for the "compatible
> >max-metric (infinite|follow)" flag. In this version, the flag
> >state is always written out explicitly - the default state is not
> >suppressed. There's pros and cons to this of course.
> >
> >(ospf_vty_init) add prev.
> >
> > * docs/ospfd.texi: docs on the "compatible max-metric
> >(infinite|follow)" command.
> >
> > diff --git a/doc/ospfd.texi b/doc/ospfd.texi
> > index 86cabe4..da6608f 100644
> > --- a/doc/ospfd.texi
> > +++ b/doc/ospfd.texi
> > @@ -172,6 +172,8 @@ releases.
> > @deffn {OSPF Command} {max-metric router-lsa [on-startup|on-shutdown]
> > <5-86400>} {}
> > @deffnx {OSPF Command} {max-metric r
[quagga-dev 15343] Re: OSPF SPF config knob
On Fri, May 20, 2016 at 02:12:51PM +0100, Paul Jakma wrote:
> Could we agree that at a minimum there needs to be a config knob, so
> admins can at least manage rolling out updates without introducing
> mixed-environments?
I haven't seen any technical argument that led me to change my opinion
on migration, i.e. I still strongly believe this needs to be fixed ASAP,
getting RFC-compliant behaviour without user interaction. That means
I'm continuing to oppose patches that don't make RFC behaviour the
default.
The event most likely to change my opinion on this is being presented
with an actual real-world setup that sees breakage from this. From the
way this bug works, I guess it'd need to be a Quagga-only production
network.
If there is an additional default-off "ospf spf-maxcost-quagga" switch,
I don't see a problem with that.
> I think more transparent migration that avoids exposing Quagga networks
> (currently fine) to any loop risk, ought to be possible, e.g. with RIs
> (which we'd have to support at some stage even for H-bit), but that can
> be another discussion.
Funnily enough, the prefixes for which traffic could loop in a mixed
setup are the prefixes which would default to a less specific route if
the router to be maintenance'd is fully removed; i.e. it's the prefixes
for which service is likely degraded anyway...
-David
> From 8142989d465d6dd2e41b0bb7a17069b5c0c3a8bb Mon Sep 17 00:00:00 2001
> From: Paul Jakma
> Date: Fri, 20 May 2016 09:54:34 +0100
> Subject: ospfd: Add compatibility setting for max-cost link SPF behaviour
>
> * Quagga OSPF has long treated max-cost links as not suitable for
>inclusion into the transit SPF tree (doesn't affect reachability of
>the node itself). Other implementations treat it as just another
>cost.
>
>In mixed environments there is therefore a risk of routing loops.
>It may be a rare risk, though when hit it could be quite
>troublesome.
>
>Just flipping the default would not address that risk. It need not
>fix the risk on networks currently exposed, while exposing other
>networks to the risk that would otherwise not be affected. Which
>administrators of the latter networks might find less than ideal.
>
>TBD: A good transition strategy, that avoids bothering currently
>unaffected networks with this problem. E.g. RIs could be used to
>transparently do the right thing for a greater number of networks
>and minise the risks.
>
>Also, the OSPF WG are standardising a method to signal Quagga's
>current behaviour conformantly. So it might also be good to
>minimise churn in behaviour, but that depends on when that comes
>along.
>
>Regardless, it would be good to at least give administrators who
>are exposed a configuration setting.
>
> * ospfd.h: Add a OSPF_MAX_METRIC_LINK_FOLLOW flag to (struct ospf).
> * lib/libospf.h: Add OSPF_OUTPUT_COST_MAX, and a
>OSPF_OUTPUT_COST_DISCOURAGE - latter metric works universally to
>signal 'discourage but still allow transit'.
>
> * ospf_lsa.c: (ospf_link_cost) Use the DISCOURAGE cost to signal
>stub-router, if SPF is set to 'follow'. These are somewhat
>separate, and with ways to signal the transit/no-transit intent of
>the local router this might be done differently, but for this patch
>probably best done together.
>
> * ospf_spf.c: (ospf_spf_next) make the behaviour on max-cost links
>configurable.
>
> * ospf_vty.c: (show_ip_ospf) Print the status of the SPF max-cost
>behaviour in 'show ip ospf'.
>
>(ospf_compatible_max_metric) Add "compatible max-metric
>(infinite|follow)" to control the SPF behaviour.
>
>(no_ospf_compatible_max_metric) clear back to default, which will
>still be written out explicitly, as below.
>
>(config_write_stub_router) Write out the config for the "compatible
>max-metric (infinite|follow)" flag. In this version, the flag
>state is always written out explicitly - the default state is not
>suppressed. There's pros and cons to this of course.
>
>(ospf_vty_init) add prev.
>
> * docs/ospfd.texi: docs on the "compatible max-metric
>(infinite|follow)" command.
>
> diff --git a/doc/ospfd.texi b/doc/ospfd.texi
> index 86cabe4..da6608f 100644
> --- a/doc/ospfd.texi
> +++ b/doc/ospfd.texi
> @@ -172,6 +172,8 @@ releases.
> @deffn {OSPF Command} {max-metric router-lsa [on-startup|on-shutdown]
> <5-86400>} {}
> @deffnx {OSPF Command} {max-metric router-lsa administrative} {}
> @deffnx {OSPF Command} {no max-metric router-lsa
> [on-startup|on-shutdown|administrative]} {}
> +@anchor{OSPF stub-router}
> +@anchor{max-metric router-lsa}
> This enables @cite{RFC3137, OSPF Stub Router Advertisement} support,
> where the OSPF process describes its transit links in its router-LSA as
> having infinite distance so that other routers will avoid calculating
> @@ -202,6 +204,51 @@ number of second remaining till on-startup or
> on-shutd
[quagga-dev 15342] OSPF SPF config knob
Hi,
Could we agree that at a minimum there needs to be a config knob, so
admins can at least manage rolling out updates without introducing
mixed-environments?
I think more transparent migration that avoids exposing Quagga networks
(currently fine) to any loop risk, ought to be possible, e.g. with RIs
(which we'd have to support at some stage even for H-bit), but that can
be another discussion.
Tested locally for the vty, but not in a network:
From 8142989d465d6dd2e41b0bb7a17069b5c0c3a8bb Mon Sep 17 00:00:00 2001
From: Paul Jakma
Date: Fri, 20 May 2016 09:54:34 +0100
Subject: ospfd: Add compatibility setting for max-cost link SPF behaviour
* Quagga OSPF has long treated max-cost links as not suitable for
inclusion into the transit SPF tree (doesn't affect reachability of
the node itself). Other implementations treat it as just another
cost.
In mixed environments there is therefore a risk of routing loops.
It may be a rare risk, though when hit it could be quite
troublesome.
Just flipping the default would not address that risk. It need not
fix the risk on networks currently exposed, while exposing other
networks to the risk that would otherwise not be affected. Which
administrators of the latter networks might find less than ideal.
TBD: A good transition strategy, that avoids bothering currently
unaffected networks with this problem. E.g. RIs could be used to
transparently do the right thing for a greater number of networks
and minise the risks.
Also, the OSPF WG are standardising a method to signal Quagga's
current behaviour conformantly. So it might also be good to
minimise churn in behaviour, but that depends on when that comes
along.
Regardless, it would be good to at least give administrators who
are exposed a configuration setting.
* ospfd.h: Add a OSPF_MAX_METRIC_LINK_FOLLOW flag to (struct ospf).
* lib/libospf.h: Add OSPF_OUTPUT_COST_MAX, and a
OSPF_OUTPUT_COST_DISCOURAGE - latter metric works universally to
signal 'discourage but still allow transit'.
* ospf_lsa.c: (ospf_link_cost) Use the DISCOURAGE cost to signal
stub-router, if SPF is set to 'follow'. These are somewhat
separate, and with ways to signal the transit/no-transit intent of
the local router this might be done differently, but for this patch
probably best done together.
* ospf_spf.c: (ospf_spf_next) make the behaviour on max-cost links
configurable.
* ospf_vty.c: (show_ip_ospf) Print the status of the SPF max-cost
behaviour in 'show ip ospf'.
(ospf_compatible_max_metric) Add "compatible max-metric
(infinite|follow)" to control the SPF behaviour.
(no_ospf_compatible_max_metric) clear back to default, which will
still be written out explicitly, as below.
(config_write_stub_router) Write out the config for the "compatible
max-metric (infinite|follow)" flag. In this version, the flag
state is always written out explicitly - the default state is not
suppressed. There's pros and cons to this of course.
(ospf_vty_init) add prev.
* docs/ospfd.texi: docs on the "compatible max-metric
(infinite|follow)" command.
diff --git a/doc/ospfd.texi b/doc/ospfd.texi
index 86cabe4..da6608f 100644
--- a/doc/ospfd.texi
+++ b/doc/ospfd.texi
@@ -172,6 +172,8 @@ releases.
@deffn {OSPF Command} {max-metric router-lsa [on-startup|on-shutdown]
<5-86400>} {}
@deffnx {OSPF Command} {max-metric router-lsa administrative} {}
@deffnx {OSPF Command} {no max-metric router-lsa
[on-startup|on-shutdown|administrative]} {}
+@anchor{OSPF stub-router}
+@anchor{max-metric router-lsa}
This enables @cite{RFC3137, OSPF Stub Router Advertisement} support,
where the OSPF process describes its transit links in its router-LSA as
having infinite distance so that other routers will avoid calculating
@@ -202,6 +204,51 @@ number of second remaining till on-startup or on-shutdown
ends, can be
viewed with the @ref{show ip ospf} command.
@end deffn
+
+@deffn {OSPF Command} {compatible max-metric (infinite|follow)} {}
+@deffnx {OSPF Command} {no compatible max-metric} {}
+
+This flag controls the behaviour of SPF, and how it treats links in
+Router-LSAs with the maximum possible metric value. It toggles between the
+@cite{RFC2328} specified behaviour, and a Quagga variation.
+
+When this flag is set to @var{follow}, then the standard RFC2328
+behaviour applies. The SPF calculation will still take links with
+the maximum value metric of 0x into consideration when
+calculating transit paths out of remote routers.
+
+When this flag is set to @var{infinite}, then Quagga deviates from
+RFC2328. The SPF transit tree calculation will treat the maximum
+link metric of 0x as an infinite cost. Such links will not be
+considered for the transit tree. This only affects whether links
+@emph{out} of a remote router will be used for transit - it does not
+affect the reachability to the router itself, or to its stub
+addresses and networks.
+
+The @var{infinite} be
[quagga-dev 15341] Re: Patch Submittal Process Going Forward Discussion.
Actually. .. On May 20, 2016 6:16:02 AM Lou Berger wrote: Paul On May 20, 2016 5:41:10 AM Paul Jakma wrote: ... Unanimous agreement on inclusion (or rollback to a last 'good' state in some edge cases) is the only way to accommodate that. What do you think about the idea of trying out the proposed process in a new branch tree? Perhaps what we're / you're really getting at is closer to the Ubuntu release model, with a cutting edge and "more stable" version. I think something like the following is something that would be great to see in place for Quagga: https://wiki.ubuntu.com/TimeBasedReleases (Although I was hoping for 3 major releases a year, but even 2 on a known schedule would be a huge win.) Lou ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15339] Re: Patch Submittal Process Going Forward Discussion.
Paul On May 20, 2016 5:41:10 AM Paul Jakma wrote: ... Unanimous agreement on inclusion (or rollback to a last 'good' state in some edge cases) is the only way to accommodate that. What do you think about the idea of trying out the proposed process in a new branch tree? Lou ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15340] Re: Patch Submittal Process Going Forward Discussion.
On Fri, 20 May 2016, Donald Sharp wrote: Please stop putting words in my mouth. I've never said that and I really don't appreciate this continued insinuation that I'm actively ignoring comments. You didn't say it, and I'm not insinuating you are actively ignoring comments. Nor am I saying there is anything but good intent on your or Cumulus' side. I know you/Cumulus are frustrated about the backlog. You have to try understand my frustrations too. Also, some part of this issue is due to historical reasons, which maybe we've fixed. However, we need to give it a fair go to find out. Also, if it hasn't quite fixed things, we can still optimise that process. And some parts of that optimisations may be that contributors need to do more work. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Beggars should be no choosers. -- John Heywood ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15338] Re: Patch Submittal Process Going Forward Discussion.
Paul - On Fri, May 20, 2016 at 5:38 AM, Paul Jakma wrote: > > - "resolve issues at a faster rate", by which you really mean "Ignore > having to address the former". > > Please stop putting words in my mouth. I've never said that and I really don't appreciate this continued insinuation that I'm actively ignoring comments. donald ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15337] Re: Patch Submittal Process Going Forward Discussion.
On Thu, 19 May 2016, Donald Sharp wrote: The point of all of this wasn't about Cumulus or not. We've had multiple people state that the process takes too long multiple times recently. The point was that patches are piling up across the *community* at a rate greater than they are even being looked at. I see no way that we can reach unanimity for every patch. Nor do I see any advantage to 2 month long arguments about issues. I would like a process where we can resolve issues at a faster rate. Note, there's a few different things being conflated. - Review resources - Integration resources and processes - Willingness of contributors to engage with reviews and address issues - "resolve issues at a faster rate", by which you really mean "Ignore having to address the former". On unanimity, I disagree with you. If we regularly have patches being pushed through by the vote of the 51+% of contributors over objections of others, we're going to run into really deep problems working togehter. We'd be much better working hard at engaging and trying to keep each other happy, than trying to come up with simple majority voting structures. Also, there can be some issues I simply am not prepared to devolve to simple majority votes. There are some things that are red-lines for me. I can well accept that others have red-lines too, and in general try to respect that (do you know how many patches I never got in? :) ). Unanimous agreement on inclusion (or rollback to a last 'good' state in some edge cases) is the only way to accommodate that. regards, -- Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A Fortune: The scene is dull. Tell him to put more life into his dying. -Samuel Goldwyn ___ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
[quagga-dev 15336] Re: Patch Submittal Process Going Forward Discussion.
Hello Martin, Some answers below. Regards Olivier Le 20/05/2016 02:35, Martin Winter a écrit : > > > On 19 May 2016, at 8:51, Olivier Dugeon wrote: > >> Hello Donald, all >> >> I globally agree on the proposal, but have some questions. See Below. >> >> BTW, I will attend next quagga meeting >> >> Regards, >> >> Olivier >> >> Le 19/05/2016 13:47, Donald Sharp a écrit : >>> >>> Adjusted proposal based upon feedback. >>> >>> - >>> >>> Golden Rule applies to everything we do. >>> >>> A person who Submit’s code cannot be the person who commits it into quagga. >>> Assume that this can be worked out amongst the maintainers. >>> >>> Anyone can ACK/NACK code by sending mail to the submitter and the >>> quagga-dev alias substantiating the basis for dissent. >>> >>> Proposal for going forward: >>> >>> 1. Patch Submitted >>> 1. Automatic testing is being applied to incoming patches on >>> quagga-dev. If testing indicates a failure then the patch must be fixed >>> and resubmitted. >>> >> Does this automatic testing include protocol conformity or just applying >> patch and try to compile ? In case it includes conformity, what's happen >> with future / innovative .. features ? I means implementing extensions that >> are not yet RFC e.g. Segment Routing. How to be sure that the testing will >> not report false failures just because the code is freshen regarding the >> testing tool. > > In my earlier response (which I believe was the base for this), I’ve added an > exception rule for cases when it’s believed that the test itself is > broken/bad or something changes on purpose. But it would have to be a clearly > stated intent. I think for the case of simplicity, Donald left this out and > just assumed a common sense by maintainer to overrule this rule if needed. > > However, specially for new features which may not even be covered by existing > tests, I would expect submitter to give some description on > his own testing - or find someone else who is able to test it before it goes > in. But again, I think common sense and doesn’t need to be > spelled out. Agree. For example, adds some text about interoperability test with commercial router (even virtual firmware like IOX-XRv or Junos vMX) will be of great help. > >>> 1. If Acked goes in immediately to a development branch, by current >>> maintainer. >>> >> Is the submitter got write access on this development branch to rebase / >> update /modify / ... its code easily before it will be merge into the master >> ? > > Can you explain a bit more? > My understanding is that it should be done/ready reviewed and agreed when it > gets accepted into the development branch. Update/Modify later would be a new > patch started at step 1. Well, taken my TE patches as example, Paul create a dedicated lls-te branch on which it apply my patches. Then, exchange with Paul started to modify my original patches. Unfortunately, I can't modify directly the code on the lls-te branch as I have no write access on it. So, I publish a patch of patch of patch ... that was for come of them not applied on the lls-te branch. Then 1.0-xx was release and I spent many effort to completely rebase my original path plus the subsequent modification on this new release. Having a write access should help me to update my patch according to Paul suggestion's as well as save my time when I rebase them. So, even if the patch was reviewed and agreed before going into a development branch, it could take time (several months in my case) before it will be merge into the master. So, update and modification could occur during this period. Working directly into the development branch will save time and reduce effort. > >>> 1. If no-one says anything after 2 weeks, code get’s put into a >>> development branch by one of the current maintainers. >>> 2. If Nacked, dissenter and submitter must publicly work the issue out on >>> the quagga-dev alias, and going back to step 1 after working issue out. >>> 3. If after 2 weeks, from Submittal, dissenter and submitter cannot figure >>> the problem out either Dissenter or Submitter can ask for agenda item to be >>> added to next monthly meeting. If disagreement is large enough a special >>> meeting can be asked for as well. >>> >> Same question as Lou. When, who and how we decide that the development >> branch is merge into the master ? > > I’ve asked for this as well. Donald decided to leave this open to give > maintainers a flexible way. > Personally, I don’t see a clear timeline required in the rules, but a quick > rule if a single maintainer > (the one working on this branch) can make this decision on it’s own or if it > would require more > maintainer/community involvement to make this decision. Here, the risk, like mention previously, is that a patch remains in a development branch for a too long period without a resync of the development branch (it is what's happen with the lls-te branch for me) wi
