Paul,
On 6/24/2016 11:33 AM, Paul Jakma wrote: > On Fri, 24 Jun 2016, Lou Berger wrote: > >> I can only speak to what's motivated my participation in this >> discussion. I think the root issues I'd like to see addressed are: >> 1. no ability to predict when the next release with *any* fixes will be >> available >> 2. lack of an active (rolling) development/integration master branch >> 3. lack of visibility and transparency in the integration and release >> process > The process developed late last year, initiated by Vincent and developed > into roughly month-based rounds of queueing patches objectively (i.e. > hoovering up everything possible from patchwork that came in since last > round); posting summary mails of said 'proposed' queue to the list; > having a bounded review period; and then sorting patches into: > > - deferred > - rejected > - accepted > > based on the feedback, then testing 'accepted' and merging into master, > was supposed to have answered 2 and 3. Though 'deferred' probably not a > good idea, and 'rejected' probably should be 'pushedback' or somesuch. > > Particularly on 3, the idea being that between the summary mail at the > start of the review period and 'gitk --all' at the end, it'd be very > clear what went where. > > To what extent did that fail to be transparent. so this is respect to 3. I personally don't recall a discussion on this on list, but perhaps missed it. I also don't see the process documented anywhere. Also, it's unclear how patches Ack'ed on list would end up anywhere but accepted. -- Keep in mind, my perspective is as user and contributor, not maintainer. > On 2, it seemed to be going well. We had (almost) month based > integration rounds, and had (from whatever arbitrary starting point in > patchwork) clear everything in patchwork from at least that point > forward. > > Why was that not meeting the 'active integration head' objective? It comes down to where I should do my development, test and submissions. Right now there is no changes between releases except at the last minute (or couple of weeks). This means: - no testing on ack'ed patches - no easy way for a user to see if an issue is addressed by the dev branch - submitted patches are often out of date (and need rebasing) and occasionally are duplicative > Further, why did that break down earlier this year? (I know what it > looks like to me, and I have asked this question several times now on > list, and no one answers). I have no idea. I only got involved beyond the contributor level once things broke down. >> I probably wouldn't have cared enough to speak up on 3 if 1 and 2 >> weren't issues. > Great, so why not propose fixes that make reference to the current > practices? This is where I started, but couldn't find it documented anywhere. And it seemed that others had their own ideas. > Rather than just go with a clean-sheet document that (at > best) ignores prior experience and lessons and the realities of > integration. What about any of the 3 discussed documents leads you to conclude they are clean-sheet documents? I see folks that have been active for a while contributing to each? > Indeed, it's primary feature (in the early draft I read) seemed to be > "Let's have one branch for Paul, and another for those who don't want to > deal with Paul's comments" - and you can imagine what I feel about that. I read this as allowing for Paul's approach given his long role in the project, but doing so in a way that allows the community to change based on community consensus. I personally think a single definitive quagga release that comes out 2 or 3 times a year would be preferred, but my understanding is that you vetoed this. > (And my comments were not even that onerous AFAIK; some are pretty damn > reasonable too; and I even offered the code for some). I'm not tracking the drafts as closely as some, but I don't recall seeing any changes or comments in the google docs from you (or for that matter on this list). Perhaps I missed them. Either way, it would be good to see your specific comments. Thanks, Lou > regards, _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
