Paul,
I've just dropped this (up to 'I'm fairly...') in the google doc for
YE
(https://docs.google.com/document/d/1xYrpTKYDvK23BCxXP-dbE6nOuvBxbGIilNLfVkI3j-I/edit)
please feel free to edit directly or send revisions if that's problematic.
Thanks!
Lou
On 5/27/2016 11:03 AM, Paul Jakma wrote:
> Hi,
>
> The core process you describe isn't substantially different to what
> we've been developing since last July:
>
> --------------------------------------------------------------------------
> 1 Systematically collect all patches since the last integration round,
> and linearise them (i.e. queue them up, work out any conflicts if
> possible - push-back anything that can't be reconciled to the
> contributor) into a labelled 'round/$X/proposed' HEAD in git.
>
> 2 Publish the HEAD and a summary of what's in it to the list, and ask
> for any final reviews, with a bounded period.
>
> 3. Based on the reviews, sort the proposed patches into 'accepted',
> 'deferred' and 'rejected' heads (the latter probably better called
> 'pushback').
>
> 4a. Have a final call on the 'accepted' head.
>
> 4b. (More recent addition) NetDEF do basic protocol testing (in addition
> to the automated, per-contribution basic CI build tests they do)
>
> 5. Merge the 'accepted' head into the main 'master' of Quagga
>
> Rinse, lather, repeat. Ideally on a bounded basis (aiming for monthly).
> -----------------------------------------------------------------------
>
> The above process can be optimised. E.g. there are parts still to be
> pipe-lined better; there are parts that can be automated; there are
> parts that can be distributed.
>
> I'm fairly confident it can deal with things even as is. Hell, I've
> already got most of the outstanding patchwork patches queued up. The
> answer to our problems is just to knuckle down and get stuff done.
>
> Quagga in 2015 saw more commits than any year since 2004, inc the pimd
> merge (~170 commits at most) or 2006 excluding:
>
> By year
> 2003 101:*************
> 2004 554:*********************************************************************
> 2005 457:*********************************************************
> 2006 239:******************************
> 2007 126:****************
> 2008 105:**************
> 2009 185:************************
> 2010 59:********
> 2011 340:*******************************************
> 2012 357:*********************************************
> 2013 134:*****************
> 2014 133:*****************
> 2015 478:************************************************************
> 2016 76:**********
>
> Here's the monthlies, since we started rounds, which compares fairly
> well to monthly averages for years above (201502 is mostly pimd):
>
> 201501 17:*******
> 201502
> 170:*********************************************************************
> 201503 9:****
> 201504 51:*********************
> 201505 40:*****************
> 201506 31:*************
> 201507 10:*****
> 201508 9:****
> 201509 47:********************
> 201510 42:******************
> 201511 1:*
> 201512 51:*********************
> 201601 0:
> 201602 56:***********************
> 201603 20:*********
> 201604 0:
> 201605 0:
>
> I don't know why there's been nothing the last few months, but I'm
> preparing round 8 'proposed' now, which should pretty much get us caught
> up.
>
> The stuff about releases and what not is a distraction. People are
> welcome to go tend stable releases. Different flavours of 'stable' are
> possible - don't need consensus on that. Personally, I think that's
> stepping on the toes of vendors, and not per se Quagga.net can do better
> - but I wouldn't stop someone from trying. I'd suggest separating that
> discussion to make it easier for people interested in that.
>
> On the Google document, there's at least two things there you know I'm
> not at all comfortable with, so I'm just going to stay away from it.
>
> regards,
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
