Mailing List Archive

Hello!

There are some small patches in the patchwork that are applicable, reviewed
and tested by CI, for example:

https://patchwork.quagga.net/patch/1959/
https://patchwork.quagga.net/patch/1969/
https://patchwork.quagga.net/patch/2009/

and so on.

Maybe you can also apply them and include into the release?

Best regards,
Igor

On Fri, Oct 7, 2016 at 7:18 PM, Paul Jakma <paul@jakma.org> wrote:

> 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?
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>

On Fri, 7 Oct 2016, Igor Ryzhov wrote:

> Maybe you can also apply them and include into the release?

I'll have a look and see.

Though, be even better to get just to steady integration and releases.
There's no reason not to have releases every couple of months - assuming
there's new stuff to be released.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You've been telling me to relax all the way here, and now you're telling
me just to be myself?
-- The Return of the Secaucus Seven

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

Paul/All,

A couple of suggestions:

1) do the update to master now and release once the integration run
completes

2) start immediately on the next release

3) require any multipart pass pull+regression using dev/automerge branch
(you choose if only ack'ed patches should be pull requested or not.)

Lou

On 10/7/2016 12:44 PM, Paul Jakma wrote:
> On Fri, 7 Oct 2016, Igor Ryzhov wrote:
>
>> Maybe you can also apply them and include into the release?
> I'll have a look and see.
>
> Though, be even better to get just to steady integration and releases.
> There's no reason not to have releases every couple of months - assuming
> there's new stuff to be released.
>
> regards,


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

woops, guess I should have checked the repo before sending (re #1) -
nice to see the change!!!


On 10/7/2016 1:15 PM, Lou Berger wrote:
> Paul/All,
>
> A couple of suggestions:
>
> 1) do the update to master now and release once the integration run
> completes
>
> 2) start immediately on the next release
>
> 3) require any multipart pass pull+regression using dev/automerge branch
> (you choose if only ack'ed patches should be pull requested or not.)
>
> Lou
>
> On 10/7/2016 12:44 PM, Paul Jakma wrote:
>> On Fri, 7 Oct 2016, Igor Ryzhov wrote:
>>
>>> Maybe you can also apply them and include into the release?
>> I'll have a look and see.
>>
>> Though, be even better to get just to steady integration and releases.
>> There's no reason not to have releases every couple of months - assuming
>> there's new stuff to be released.
>>
>> regards,


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

Paul,

if you are planning with an actual release, then please declare it as a
release candidate
on the list (maybe new email with such a subject to make it clear to
everyone) and
give it at least a week to settle and give everyone a chance to object.
(Preferably we would create a branch with it, so we can move on with
master)

There are still a few errors from my compliance testing which I want to
look into.
Will know more once I had time to look at it if it’s anything
important.

- Martin

On 7 Oct 2016, at 9:18, Paul Jakma wrote:

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

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

Hi,

On Sat, 8 Oct 2016, Martin Winter wrote:

> Paul,
>
> if you are planning with an actual release, then please declare it as
> a release candidate on the list (maybe new email with such a subject
> to make it clear to everyone) and give it at least a week to settle
> and give everyone a chance to object. (Preferably we would create a
> branch with it, so we can move on with master)

Well, 'master' is a release candidate, go forth and test. :)

My experience is people who care to test devel will do so anyway; while
distros aren't going to package anything till there's a release ('rc'
version numbers that do not sort lexographically in the same order as
the version order historically were problematic for at least some distro
package tools, and may still be), and many people won't test anything
till there's a distro package.

So, I'd tend to getting a release out ASAP, so it can go into the
'testing' channels of distros ASAP, which will bring the most testing.

We can always document the expected stability levels in the release
notes, e.g.:

"This is a major release with many changes to the code. While it has
many improvements and bug fixes, it also has at least a couple of
known regressions. Another point release may follow shortly with
further fixes. Please consider this a feature preview release and
test accordingly."

We have an 'Unlimited' subscription with the Sofware Version Assignment
Board - we're not on the €100 per version number PAYG option - so
there's no need to conserve on version numbers, AFAIK. ;)

If someone wanted to maintain stable point releases (subset of the
commits in 'master') of Quagga, that could be nice. Though, 'stable'
means different things to different people, and so it can be a bit of a
thankless task this.

> There are still a few errors from my compliance testing which I want
> to look into. Will know more once I had time to look at it if it’s
> anything important.

Ok.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Behind every great computer sits a skinny little geek.

On 10 Oct 2016, at 1:40, Paul Jakma wrote:

> Hi,
>
> On Sat, 8 Oct 2016, Martin Winter wrote:
>
>> Paul,
>>
>> if you are planning with an actual release, then please declare it as
>> a release candidate on the list (maybe new email with such a subject
>> to make it clear to everyone) and give it at least a week to settle
>> and give everyone a chance to object. (Preferably we would create a
>> branch with it, so we can move on with master)
>
> Well, 'master' is a release candidate, go forth and test. :)

I’m working on it. I have a few “anomalies” in my test results
which I like to
address and wanted to look at some static analysis as well.
So about a week of only critical bug fixes (feature freeze on the
release candidate)
would be good for me.

And I would welcome anyone else to test as well

- Martin

> My experience is people who care to test devel will do so anyway;
> while distros aren't going to package anything till there's a release
> ('rc' version numbers that do not sort lexographically in the same
> order as the version order historically were problematic for at least
> some distro package tools, and may still be), and many people won't
> test anything till there's a distro package.
>
> So, I'd tend to getting a release out ASAP, so it can go into the
> 'testing' channels of distros ASAP, which will bring the most testing.
>
> We can always document the expected stability levels in the release
> notes, e.g.:
>
> "This is a major release with many changes to the code. While it has
> many improvements and bug fixes, it also has at least a couple of
> known regressions. Another point release may follow shortly with
> further fixes. Please consider this a feature preview release and
> test accordingly."
>
> We have an 'Unlimited' subscription with the Sofware Version
> Assignment Board - we're not on the €100 per version number PAYG
> option - so there's no need to conserve on version numbers, AFAIK. ;)
>
> If someone wanted to maintain stable point releases (subset of the
> commits in 'master') of Quagga, that could be nice. Though, 'stable'
> means different things to different people, and so it can be a bit of
> a thankless task this.
>
>> There are still a few errors from my compliance testing which I want
>> to look into. Will know more once I had time to look at it if it’s
>> anything important.
>
> Ok.
>
> regards,
> --
> Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
> Fortune:
> Behind every great computer sits a skinny little geek.

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

Hi all,

It is great that the master branch has been merged with
origin/volatile/patch-tracking/8/proposed/ff-2016100701.
I was wondering, when will the next release open ?
Is the CI automatically taking master branch to apply newly received patches ?

Regards,

Philippe


On Fri, Oct 7, 2016 at 7:15 PM, Lou Berger <lberger@labn.net> wrote:
> Paul/All,
>
> A couple of suggestions:
>
> 1) do the update to master now and release once the integration run
> completes
>
> 2) start immediately on the next release
>
> 3) require any multipart pass pull+regression using dev/automerge branch
> (you choose if only ack'ed patches should be pull requested or not.)
>
> Lou
>
> On 10/7/2016 12:44 PM, Paul Jakma wrote:
>> On Fri, 7 Oct 2016, Igor Ryzhov wrote:
>>
>>> Maybe you can also apply them and include into the release?
>> I'll have a look and see.
>>
>> Though, be even better to get just to steady integration and releases.
>> There's no reason not to have releases every couple of months - assuming
>> there's new stuff to be released.
>>
>> regards,
>
>
> _______________________________________________
> 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 10 Oct 2016, at 3:17, Philippe Guibert wrote:

> Hi all,
>
> It is great that the master branch has been merged with
> origin/volatile/patch-tracking/8/proposed/ff-2016100701.
> I was wondering, when will the next release open ?

Not what the exact plans is, but I prefer either a release
branch started now or new commits which are not only bug fixes to
be held up for a week to let the code “settle” and give everyone
time to test.

> Is the CI automatically taking master branch to apply newly received
> patches ?

Yes, the patches emailed to the list (and picked up by patchwork)
are always tested against the latest master.

But we should go back to a discussion on how this should be done.
Personally, I would prefer to never ever have such a large
“proposed”
branch. Preferrably commits to master on a continuous way.

I think Paul felt the pain very well and I’m curious what his
suggestion
is at this time on how to do this in the future.

Paul?

- Martin


> On Fri, Oct 7, 2016 at 7:15 PM, Lou Berger <lberger@labn.net> wrote:
>> Paul/All,
>>
>> A couple of suggestions:
>>
>> 1) do the update to master now and release once the integration run
>> completes
>>
>> 2) start immediately on the next release
>>
>> 3) require any multipart pass pull+regression using dev/automerge
>> branch
>> (you choose if only ack'ed patches should be pull requested or not.)
>>
>> Lou
>>
>> On 10/7/2016 12:44 PM, Paul Jakma wrote:
>>> On Fri, 7 Oct 2016, Igor Ryzhov wrote:
>>>
>>>> Maybe you can also apply them and include into the release?
>>> I'll have a look and see.
>>>
>>> Though, be even better to get just to steady integration and
>>> releases.
>>> There's no reason not to have releases every couple of months -
>>> assuming
>>> there's new stuff to be released.
>>>
>>> regards,
>>
>>
>> _______________________________________________
>> 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 Mon, 10 Oct 2016, Martin Winter wrote:

> Not what the exact plans is, but I prefer either a release branch
> started now or new commits which are not only bug fixes to be held up
> for a week to let the code “settle” and give everyone time to test.

Ok, lets wait till the end of the week then.

> But we should go back to a discussion on how this should be done.
> Personally, I would prefer to never ever have such a large “proposed”
> branch. Preferrably commits to master on a continuous way.

Well, of course. :)

> I think Paul felt the pain very well and I’m curious what his
> suggestion is at this time on how to do this in the future.

Some systematic way to collect patches, wait for some sync point on
reviews, integrate to master and repeat. On an X-weekly basis (X := 1 to
4). Regular releases, 3, 4 or even more / year - if we've got new fixes
or features, we can always release. Long cycles just hurt.

- Systematic way to collect patches could be:

* Patchwork (it has issues over longer time spans, but prob ok on
short ones)

* Bugzilla

* automated list crawler and applier (I'd prefer not to put closed
tools in the middle of this though)

Nothing is perfect though.

If I could figure out why git-bz doesn't work with a proxy on Fedora,
I'd say bugzilla was the no-brainer. Sigh.

- Reviews: People just need to pitch in with reviewing. Contributors
need to get on with addressing comments.

Ask not what your open source project should be doing for you, but
what you can do for your open source project.

- Sync point and integration may require some human intervention.

From experience with this project and maybe another, it's good to have
a specific named person on 'duty' (to avoid cracks for things to fall
through) and with the duty period limited (to avoid burn-out, and for
continuity/repeatability).

Then we find people willing and able, so: Comfortable with the tools.
Willing to donate some time on inevitable integration monkey work (even
with perfect tools, there will be some of this, inc. on contributors
side). Willing to apply the patches and the review comments.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Clarke's Conclusion:
Never let your sense of morals interfere with doing the right thing.

On Mon, 10 Oct 2016, Paul Jakma wrote:

> From experience with this project and maybe another, it's good to
> have a specific named person on 'duty' (to avoid cracks for things to
> fall through) and with the duty period limited (to avoid burn-out,
> and for continuity/repeatability).

Oh, that doesn't preclude having a group of people able to commit at the
same time. Just in addition, over whatever defined period, there should
also be a specific person who is responsible for taking care of
contributions generally.

Just some protocol is needed then wrt git to avoid stompage, in allowing
for reviews/drops/reworks of patches.

regards,
--
Paul Jakma | paul@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Stay together, drag each other down.

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

On 10/10/2016 10:16 AM, Paul Jakma wrote:
> On Mon, 10 Oct 2016, Martin Winter wrote:
>
>> > Not what the exact plans is, but I prefer either a release branch
>> > started now or new commits which are not only bug fixes to be held up
>> > for a week to let the code “settle” and give everyone time to test.
> Ok, lets wait till the end of the week then.
>

I sent two NHT related changes to the list. The first cleans up a
warning, so is optional. The second change is a must - my other testing
is looking good.

Lou


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

> - Systematic way to collect patches could be:
>
> * Patchwork (it has issues over longer time spans, but prob ok on
> short ones)
>
> * Bugzilla
>
> * automated list crawler and applier (I'd prefer not to put closed
> tools in the middle of this though)
>
> Nothing is perfect though.

GregKH gave an interesting talk about why the Linux kernel uses email:

https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/

Maybe that talk can spark come ideas for what would work well for
quagga.

Andrew

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