Mailing List Archive

Hi Martin,

On Sun, 2 Oct 2016, Martin Winter wrote:

> I did a full test run of our RFC compliance testbed against
> volatile/patch-tracking/8/proposed/ff-2016093002 (Commit e4adc26)
>
> Results are at
> https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing
>
> The biggest issues seem to be several new failures on OSPFv2

Thanks for this.

My inclination is to release as is. Document regressions. Try fix them
later.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Also, the Scots are said to have invented golf. Then they had
to invent Scotch whiskey to take away the pain and frustration.

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Le 03/10/2016 à 15:08, Paul Jakma a écrit :
>
> My inclination is to release as is. Document regressions. Try fix them
> later.
+1

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On Oct 3, 2016, at 11:21 AM, Vincent JARDIN <vincent.jardin@6wind.com> wrote:
> Le 03/10/2016 à 15:08, Paul Jakma a écrit :
>>
>> My inclination is to release as is. Document regressions. Try fix them
>> later.
> +1

ISTM the large majority of quagga users will not see any such documentation. They'll build/install using their distro's package manager.

Then when things break, they'll come here looking for support, or else decide that quagga sucks and try something else.

/a
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On 3 Oct 2016, at 6:08, Paul Jakma wrote:

> Hi Martin,
>
> On Sun, 2 Oct 2016, Martin Winter wrote:
>
>> I did a full test run of our RFC compliance testbed against
>> volatile/patch-tracking/8/proposed/ff-2016093002 (Commit e4adc26)
>>
>> Results are at
>> https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing
>>
>> The biggest issues seem to be several new failures on OSPFv2
>
> Thanks for this.
>
> My inclination is to release as is. Document regressions. Try fix them
> later.

Ouch. OSPFv2 seems to be seriously broken.
If you mean release as “an official release”, then I would vote
against.
If you think just merge to master, then maybe. Still don’t like it (at
least without
some attempt to fix it)

- Martin

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Le 4 octobre 2016 3:58:59 AM Alexis Rosen
<quagga-users@alexis.users.panix.com> a écrit :

> On Oct 3, 2016, at 11:21 AM, Vincent JARDIN <vincent.jardin@6wind.com> wrote:
>> Le 03/10/2016 à 15:08, Paul Jakma a écrit :
>>>
>>> My inclination is to release as is. Document regressions. Try fix them
>>> later.
>> +1
>
> ISTM the large majority of quagga users will not see any such
> documentation. They'll build/install using their distro's package manager.
>
> Then when things break, they'll come here looking for support, or else
> decide that quagga sucks and try something else.
>

Agree. I do not think the intents were to announce a new stable tag/release
but more to move forward so shared work and major OSPF fixing can happen on
the head.

Paul? Martin?





_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On Mon, 3 Oct 2016, Martin Winter wrote:

> Ouch. OSPFv2 seems to be seriously broken.

> If you mean release as “an official release”, then I would vote
> against. If you think just merge to master, then maybe. Still don’t
> like it (at least without some attempt to fix it)

Merge to master at a minimum.

Unless we have a quick way to bisect the OSPF related commits against
these and find the errant commits?

If I was manually doing bisection testing, I'd start with these as my
pivot points (not to say these are suspect! just that these are useful
milestones in between significant changes):

481986950290323e2f5d1e774a666d4b7ed510d6
'ospfd: Add support Router Capabilities support to OSPF'

a6d400c9158b10207cde40a428ebf2c27f105c0a
'zebra: Set link-detect on by default'

45af55a70379da6e1534185ffa20238aa6026d52
'ospfd: Make destination of p2p to multicast for LS-ACKS'

7a6f93f6316e1d0f530b68f75678582be09009fa
'ospfd: Don't wait for state change to Exchange to start LSReq'

8741c4cc2d76717616c4d396f531daf7e3bd6085
osfd: Make OSPF compliant to the last sentence of this section in RFC 2328

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You may worry about your hair-do today, but tomorrow much peanut butter will
be sold.

On Tue, 4 Oct 2016, Paul Jakma wrote:

> Unless we have a quick way to bisect the OSPF related commits against
> these and find the errant commits?

Ah, never mind. stupid mis-merge, managed to drop one little but
important hunk on the "ospfd: Don't wait for state change to Exchange to
start LSReq" patch.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Waste not, get your budget cut next year.

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On Tue, 4 Oct 2016, Paul Jakma wrote:

> Ah, never mind. stupid mis-merge, managed to drop one little but
> important hunk on the "ospfd: Don't wait for state change to Exchange
> to start LSReq" patch.

Passes CI. Fingers crossed we really are done on this now. :)

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Young men think old men are fools; but old men know young men are fools.
-- George Chapman

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On 4 Oct 2016, at 6:42, Paul Jakma wrote:

> On Tue, 4 Oct 2016, Paul Jakma wrote:
>
>> Ah, never mind. stupid mis-merge, managed to drop one little but
>> important hunk on the "ospfd: Don't wait for state change to Exchange
>> to start LSReq" patch.
>
> Passes CI. Fingers crossed we really are done on this now. :)

I assume this is now ft-2016100401 (git sha 743dd42) ?

Queuing for the full run next… (Will know in 1..2 days)

- Martin Winter


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Hello Martin,

As only OSPF is concern, is it possible to restrict the tests conformity to only OSPF to speed up the process and get result sooner ?

Regards

Olivier


Le 05/10/2016 à 11:40, Martin Winter a écrit :
> On 4 Oct 2016, at 6:42, Paul Jakma wrote:
>
>> On Tue, 4 Oct 2016, Paul Jakma wrote:
>>
>>> Ah, never mind. stupid mis-merge, managed to drop one little but important hunk on the "ospfd: Don't wait for state change to Exchange to start LSReq" patch.
>>
>> Passes CI. Fingers crossed we really are done on this now. :)
>
> I assume this is now ft-2016100401 (git sha 743dd42) ?
>
> Queuing for the full run next… (Will know in 1..2 days)
>
> - Martin Winter
>
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev

On 5 Oct 2016, at 2:56, Olivier Dugeon wrote:

> Hello Martin,
>
> As only OSPF is concern, is it possible to restrict the tests
> conformity to only OSPF to speed up the process and get result sooner
> ?

Not really. I’m running each protocol on it’s own (in parallel) and
OSPF is the one taking the longest time.
I’ve added approx 10 of the failed tests to the CI system and they are
currently running

(see https://ci1.netdef.org/browse/QUAGGA-QMASTER30-2 - look for the
Extra OSPF Tests)
These tests were all failing before, but should pass.

I assume having 2 days wait for everyone before merge shouldn’t be a
big issue (and maybe
giving others a chance to do some testing as well)

- Martin

> Le 05/10/2016 à 11:40, Martin Winter a écrit :
>> On 4 Oct 2016, at 6:42, Paul Jakma wrote:
>>
>>> On Tue, 4 Oct 2016, Paul Jakma wrote:
>>>
>>>> Ah, never mind. stupid mis-merge, managed to drop one little but
>>>> important hunk on the "ospfd: Don't wait for state change to
>>>> Exchange to start LSReq" patch.
>>>
>>> Passes CI. Fingers crossed we really are done on this now. :)
>>
>> I assume this is now ft-2016100401 (git sha 743dd42) ?
>>
>> Queuing for the full run next… (Will know in 1..2 days)
>>
>> - Martin Winter
>>
>>
>> _______________________________________________
>> 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

On 5 Oct 2016, at 3:24, Martin Winter wrote:

> On 5 Oct 2016, at 2:56, Olivier Dugeon wrote:
>
>> Hello Martin,
>>
>> As only OSPF is concern, is it possible to restrict the tests
>> conformity to only OSPF to speed up the process and get result sooner
>> ?
>
> Not really. I’m running each protocol on it’s own (in parallel)
> and OSPF is the one taking the longest time.
> I’ve added approx 10 of the failed tests to the CI system and they
> are currently running
>
> (see https://ci1.netdef.org/browse/QUAGGA-QMASTER30-2 - look for the
> Extra OSPF Tests)
> These tests were all failing before, but should pass.
>
> I assume having 2 days wait for everyone before merge shouldn’t be a
> big issue (and maybe
> giving others a chance to do some testing as well)

And they just all passed!
https://ci1.netdef.org/browse/QUAGGA-QMASTER30-EXTRAV4OSPF-2/test

So I think we are on the right track.
The full run is already under way…

- Martin

>> Le 05/10/2016 à 11:40, Martin Winter a écrit :
>>> On 4 Oct 2016, at 6:42, Paul Jakma wrote:
>>>
>>>> On Tue, 4 Oct 2016, Paul Jakma wrote:
>>>>
>>>>> Ah, never mind. stupid mis-merge, managed to drop one little but
>>>>> important hunk on the "ospfd: Don't wait for state change to
>>>>> Exchange to start LSReq" patch.
>>>>
>>>> Passes CI. Fingers crossed we really are done on this now. :)
>>>
>>> I assume this is now ft-2016100401 (git sha 743dd42) ?
>>>
>>> Queuing for the full run next… (Will know in 1..2 days)
>>>
>>> - Martin Winter
>>>
>>>
>>> _______________________________________________
>>> 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

Paul,

Results are updated.

See
https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing

OSPFv2 issues are fixed.
I haven’t looked at all the other protocols, but overall they seem to
be mostly
ok.

Let me know if there are any concerns regarding a specific issue and
I’ll look into it,
but might both have much time this week anymore (as I’m at a
conference)

- Martin


On 5 Oct 2016, at 2:40, Martin Winter wrote:

> On 4 Oct 2016, at 6:42, Paul Jakma wrote:
>
>> On Tue, 4 Oct 2016, Paul Jakma wrote:
>>
>>> Ah, never mind. stupid mis-merge, managed to drop one little but
>>> important hunk on the "ospfd: Don't wait for state change to
>>> Exchange to start LSReq" patch.
>>
>> Passes CI. Fingers crossed we really are done on this now. :)
>
> I assume this is now ft-2016100401 (git sha 743dd42) ?
>
> Queuing for the full run next… (Will know in 1..2 days)
>
> - Martin Winter
>

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On Wed, 5 Oct 2016, Martin Winter wrote:

> OSPFv2 issues are fixed. I haven’t looked at all the other protocols,
> but overall they seem to be mostly ok.

\o/

> Let me know if there are any concerns regarding a specific issue and
> I’ll look into it, but might both have much time this week anymore (as
> I’m at a conference)

Great, so I propose master is ff'ed to the

volatile/patch-tracking/8/proposed/ff-2016100401

head ASAP, and we get a release out based on that.

I'll wait till tomorrow for objections (not aware of any objections bar
the OSPFv2 issue).

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
[We] use bad software and bad machines for the wrong things.
-- R.W. Hamming

On Wed, 5 Oct 2016, Martin Winter wrote:

> Paul,
>
> Results are updated.
>
> See
> https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing
>
> OSPFv2 issues are fixed.
> I haven’t looked at all the other protocols, but overall they seem to be
> mostly
> ok.

Yeah, mostly unchanged. couple of cases for OSPFv2 where a test that
generally fails passed with the last (broken) head. Maybe that's a
consequence of other things failing that made that particular test seem
to pass though.

One change from the last release in BGP is ANVL-BGPPLUS-17.1 related to
address used for nexthop - NHT related? Is it serious?

Looks acceptable generally.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
The most difficult thing in the world is to know how to do a thing and to
watch someone else doing it wrong, without commenting.
-- T.H. White

Paul,

On October 6, 2016 6:05:14 AM Paul Jakma <paul@jakma.org> wrote:

...
>
> One change from the last release in BGP is ANVL-BGPPLUS-17.1 related to
> address used for nexthop - NHT related? Is it serious?
>
> Looks acceptable generally.
>

One outstanding issue for the release is operation of BGP without zebra.
(The NHT change basically introduces a requirement to run BGP with
zebra, while there are route server/reflector configs which are viable
now running only BGP.)

I suggest changing the NHT code to either (a) automatically operate /
adjust to when zebra isn't present or (b) have a bgp config option to
ignore NHT, e.g., 'no bgp nexthop-tracking'.

Do you/anyone have a preference? -- Mine is (a).

I (or Paul Z.) can propose a patch for this change.

Lou


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

There are a few OSPFv3 issues as well

ANVL-OSPFV3-8.5 & 19.11-19.16

I have not looked yet into the failure case (sorry busy this week).
I would vote to address them after the merge to master.

- Martin

On 6 Oct 2016, at 3:02, Paul Jakma wrote:

> On Wed, 5 Oct 2016, Martin Winter wrote:
>
>> Paul,
>>
>> Results are updated.
>>
>> See
>> https://drive.google.com/drive/folders/0B8W_T0dxQfwxZFdJd1lPOXo3bHM?usp=sharing
>>
>> OSPFv2 issues are fixed.
>> I haven’t looked at all the other protocols, but overall they seem
>> to be mostly
>> ok.
>
> Yeah, mostly unchanged. couple of cases for OSPFv2 where a test that
> generally fails passed with the last (broken) head. Maybe that's a
> consequence of other things failing that made that particular test
> seem to pass though.
>
> One change from the last release in BGP is ANVL-BGPPLUS-17.1 related
> to address used for nexthop - NHT related? Is it serious?
>
> Looks acceptable generally.
>
> regards,
> --
> Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> The most difficult thing in the world is to know how to do a thing and
> to
> watch someone else doing it wrong, without commenting.
> -- T.H. White

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

I think something to address before a release, but not sure if we should
hold off merging to master because of it.

Lou, are you proposing to fix this before merging to master?

- Martin

On 6 Oct 2016, at 6:30, Lou Berger wrote:

> Paul,
>
> On October 6, 2016 6:05:14 AM Paul Jakma <paul@jakma.org> wrote:
>
> ...
>>
>> One change from the last release in BGP is ANVL-BGPPLUS-17.1 related to
>> address used for nexthop - NHT related? Is it serious?
>>
>> Looks acceptable generally.
>>
>
> One outstanding issue for the release is operation of BGP without zebra.
> (The NHT change basically introduces a requirement to run BGP with
> zebra, while there are route server/reflector configs which are viable
> now running only BGP.)
>
> I suggest changing the NHT code to either (a) automatically operate /
> adjust to when zebra isn't present or (b) have a bgp config option to
> ignore NHT, e.g., 'no bgp nexthop-tracking'.
>
> Do you/anyone have a preference? -- Mine is (a).
>
> I (or Paul Z.) can propose a patch for this change.
>
> Lou
>

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On 10/6/2016 9:35 AM, Martin Winter wrote:
> I think something to address before a release, but not sure if we should
> hold off merging to master because of it.
>
> Lou, are you proposing to fix this before merging to master?

No. Please merge to master ASAP.

This said -- just sending patch (based on ff-2016091901) now...

Lou

>
> - Martin
>
> On 6 Oct 2016, at 6:30, Lou Berger wrote:
>
>> Paul,
>>
>> On October 6, 2016 6:05:14 AM Paul Jakma <paul@jakma.org> wrote:
>>
>> ...
>>> One change from the last release in BGP is ANVL-BGPPLUS-17.1 related to
>>> address used for nexthop - NHT related? Is it serious?
>>>
>>> Looks acceptable generally.
>>>
>> One outstanding issue for the release is operation of BGP without zebra.
>> (The NHT change basically introduces a requirement to run BGP with
>> zebra, while there are route server/reflector configs which are viable
>> now running only BGP.)
>>
>> I suggest changing the NHT code to either (a) automatically operate /
>> adjust to when zebra isn't present or (b) have a bgp config option to
>> ignore NHT, e.g., 'no bgp nexthop-tracking'.
>>
>> Do you/anyone have a preference? -- Mine is (a).
>>
>> I (or Paul Z.) can propose a patch for this change.
>>
>> Lou
>>


_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Hi all,

On Thu, Oct 6, 2016 at 3:59 PM, Lou Berger <lberger@labn.net> wrote:

> > Lou, are you proposing to fix this before merging to master?
>
> No. Please merge to master ASAP.
>

+1

Philippe

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

Le 06/10/2016 à 17:01, Philippe Guibert a écrit :
>> No. Please merge to master ASAP.
>> >
> +1
+1

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On Thu, 6 Oct 2016, Lou Berger wrote:

> One outstanding issue for the release is operation of BGP without
> zebra. (The NHT change basically introduces a requirement to run BGP
> with zebra, while there are route server/reflector configs which are
> viable now running only BGP.)

> I suggest changing the NHT code to either (a) automatically operate /
> adjust to when zebra isn't present or (b) have a bgp config option to
> ignore NHT, e.g., 'no bgp nexthop-tracking'.
>
> Do you/anyone have a preference? -- Mine is (a).

Definitely a.

> I (or Paul Z.) can propose a patch for this change.

Cool.

So, that'd be a release blocker, but not a 'ff master' blocker, right?

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
I do desire we may be better strangers.
-- William Shakespeare, "As You Like It"

_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On October 6, 2016 11:47:59 AM Paul Jakma <paul@jakma.org> wrote:

> On Thu, 6 Oct 2016, Lou Berger wrote:
>
>> One outstanding issue for the release is operation of BGP without
>> zebra. (The NHT change basically introduces a requirement to run BGP
>> with zebra, while there are route server/reflector configs which are
>> viable now running only BGP.)
>
>> I suggest changing the NHT code to either (a) automatically operate /
>> adjust to when zebra isn't present or (b) have a bgp config option to
>> ignore NHT, e.g., 'no bgp nexthop-tracking'.
>>
>> Do you/anyone have a preference? -- Mine is (a).
>
> Definitely a.
>

Great. You should have the patch.

>> I (or Paul Z.) can propose a patch for this change.
>
> Cool.
>
> So, that'd be a release blocker, but not a 'ff master' blocker, right?
>
Agreed!

Lou

> regards,
> --
> Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> I do desire we may be better strangers.
> -- William Shakespeare, "As You Like It"
>



_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev

On Thu, 6 Oct 2016, Lou Berger wrote:

>> So, that'd be a release blocker, but not a 'ff master' blocker, right?
>>
> Agreed!

master forwarded.

$ git log remotes/quagga-gnu/volatile/patch-tracking/7/proposed/ff..remotes/quagga-gnu/master \
| awk '/^Date/ { count[$6]++} \
END { for (i in count) print i,count[i] }'
2007 1
2013 2
2014 7
2015 58
2016 103
$ git log
remotes/quagga-gnu/volatile/patch-tracking/7/proposed/ff..remotes/quagga-gnu/master
| grep ^commit | wc -l
171
$ git log
remotes/quagga-gnu/volatile/patch-tracking/7/proposed/ff..remotes/quagga-gnu/master
| grep ^Author | sort -u
Author: Andrej Ota <andrej@ota.si>
Author: Avneesh Sachdev <avneesh@sproute.com>
Author: Ayan Banerjee <ayan@cumulusnetworks.com>
Author: Balaji <balajig81@gmail.com>
Author: Boian Bonev <bbonev@ipacct.com>
Author: boris yakubov <borisyakubov@ruggedcom.com>
Author: Christian Franke <chris@opensourcerouting.org>
Author: Christian Franke <nobody@nowhere.ws>
Author: Colin Petrie <cpetrie@ripe.net>
Author: Daniel Walton <dwalton@cumulusnetworks.com>
Author: David Lamparter <equinox@opensourcerouting.org>
Author: Denil Vira <denil@cumulusnetworks.com>
Author: Dinesh Dutt <ddutt@cumulusnetworks.com>
Author: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Author: Donald Sharp <sharpd@cumulusnetworks.com>
Author: Evgeny Uskov <eu@qrator.net>
Author: Igor Ryzhov <iryzhov@nfware.com>
Author: Jafar Al-Gharaibeh <jafar@atcorp.com>
Author: James Li <jli@cumulusnetworks.com>
Author: kitty <khiruthigai.balasubramanian@hpe.com>
Author: Lou Berger <lberger@labn.net>
Author: Matthieu Boutier <boutier@pps.univ-paris-diderot.fr>
Author: Olivier Dugeon <olivier.dugeon@orange.com>
Author: Paul Jakma <paul.jakma@hpe.com>
Author: Paul Jakma <paul@jakma.org>
Author: Paul Jakma <paul@opensourcerouting.org>
Author: Pawel Wieczorkiewicz <pwieczorkiewicz@suse.de>
Author: Philippe Guibert <philippe.guibert@6wind.com>
Author: Piotr Chyt³a <pch@packetconsulting.pl>
Author: Pradosh Mohapatra <pmohapat@cumulusnetworks.com>
Author: Roman Hoog Antink <rha@open.ch>
Author: Udaya Shankara KS <shankara.k.s.u@gmail.com>
Author: Vipin Kumar <vipin@cumulusnetworks.com>
Author: Vivek Venkatraman <vivek@cumulusnetworks.com>
Author: vivek <vivek@cumulusnetworks.com>

Release either over the weekend or else on monday, unless something else
is deemed better.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Is it possible that software is not like anything else, that it is meant to
be discarded: that the whole point is to always see it as a soap bubble?