Adding to this…
On 24 Jun 2016, at 9:16, Lou Berger wrote: > 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. Yes, a lot of confusion. Even for patches which got ack’ed, it is completely unknown if and when they go into the active development branch. (They could sit on patchwork for a long time). Things going in on more FREQUENT interval (and in smaller batches) would make things so much easier. >> 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 Strongly support this. I really think that things need to move from ACK into the master (or whatever the development branch is) in matter of days. This would make integration (and testing) much simpler: Further contribution would be tested on top of the development branch and it would be much more clear when/what broke - and give more people time to test against the growing development tree. The current model of “proposed trees” just doesn’t work. It was a fair try, but I think we now have enough evidence to improve the process. >> 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 think most of this is based (at least) on confusion. Most people think that you only look at yourself, Vincent and Greg as actual maintainers and the rest (i.e. Donald) as sub-maintainers or “round keepers” without the right on merging into master without your ok. This is not encouraging their work. >>> 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. Yes, I think that’s exactly what these 3 documents are trying to do. I think this is a great start on consolidating everyones thoughts and experience and trying to come up with a new way. It might not be perfect on the first try, but at least a group of active contributors would like to give it a new try. >> 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? Some here. I see a lot of them just documenting the existing way (at least as I think it is right now). Only a few changes to actual work. >> 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. Paul, you seem to be mostly absent on all the discussion. So what we try is to make a way which is acceptable to you as well - giving you some way to continue the existing way while allowing everyone who is willing to try a new way to do this and see how it turns out. >> (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. Missed them too. Can you point to the email or the comments? I would mainly be interested on what part you support/are ok with/ or disagree on each of the documents. And maybe you can even suggest some new version of the parts you disagree for the community to discuss. Thanks, - Martin _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
