On Mar 3, 2016 6:59 PM, "Donald Sharp" <sha...@cumulusnetworks.com> wrote: > > Paul - > > I believe I understand your logic. I'm not sure I agree with it, but I don't have to necessarily :) > > The one thing that concerns me most is the semantics of 'rounds keeper'. If I go and talk to someone outside of the quagga community and explain what I do( or am attempting to do ) in the quagga community 'rounds keeper' has no meaning and just provokes more questions. I think I would prefer terms that are universally understood by people and as such 'rounds keeper' fails this test for me. > > Why not call you, Vincent, and Greg the board of directors
Sounds interesting. I guess we can have another name so that it sounds more of an open source project. and people with commit access maintainers? > > donald > > On Fri, Feb 26, 2016 at 11:02 AM, Paul Jakma <p...@jakma.org> wrote: >> >> Hi, >> >> A topic that rumbles around in the background. Here's my view of the status quo. The key, for me, is that everyone should feel able to be involved: >> >> General governance and admin: >> >> - Quagga is a community project. >> >> - The running and development of Quagga proceeds by community consensus >> the intersection of what is broadly acceptable - as much as possible. >> >> - Everyone is welcome to participate >> >> - The final arbiters and stewards of Quagga are the "maintainers", >> currently Paul Jakma, Vincent Jardin, and Greg Troxel (who have been >> with Quagga for a long time) They should operate on consensus >> themselves. >> >> - The consensus is (or should be) documented in HACKING.md in the SCM. >> All community members are encouraged to help update and evolve this >> document. >> >> >> In terms of specific development processes, things have evolved and should continue to evolve. At present it's roughly: >> >> - Contributors submit a patch to the list as a 'diff' with a suitable >> commit message. >> >> The best way to do this is to prepare a commit to a local git tree and >> use 'git send-email' to send it to the list. >> >> As per HACKING, note the commit message is there for a number of >> reasons. Good commit messages make life easier for everyone >> ultimately. >> >> - Patches are tracked via 'patchwork' currently, though you may also use >> bugzilla (create a bugzilla bug, include the bug ID in the commit with >> "bug #ID", attach patch there, git-send-email it to the list too) >> >> - A "rounds keeper" will queue *every* patch to a set of "proposed" >> branches, under volatile/patch-tracking/$ROUND/proposed/... >> >> - At some point, a review deadline is set - of at least 2 weeks >> currently (if I remember correctly). >> >> *Everyone* is entitled to give reviews, comments and objections to >> patches queued up as proposed. >> >> - Patches by default go in. I.e. the default is a "fast-track" for >> contributions. >> >> Queries, objections, etc., to a (set) of patches send them off this >> default fast-path, to a path where the contributor and the reviewers >> should work together to find the acceptable patch-set. This may >> require different degrees of discussion and iteration of the >> contribution. Once there >> >> - The "rounds keeper" curates a branch with contributions that are ready >> for integration. I.e., those on the fast-track, and any others on >> which there is consensus. This branch is published and some kind of >> summary sent to the list for verification and final testing (e.g., >> NetDEF do a wide range of platform and protocol conformance and >> regression tests, as a very useful service to the community). >> >> - After a review window of time has passed and everything appears in >> order, the rounds keeper may integrate the consensus patches to >> 'master', and start a new round. >> >> Patches still in discussion from the previous should be carried >> forward. Contributors should though re-submit if they feel something >> has been missed. >> >> - Repeat >> >> The "rounds keeper" task should be fairly objective, and my goal is to have it regularly rotated around anyone able and willing to do it, as a 'chore'. >> >> The above might not be perfect, and it may be we need to change it. That's fine. Other projects do thinks like give 'windows' to people who have a patch train, to integrate stuff. >> >> We still don't track patch status perfectly (patchwork is great, but not perfect). >> >> regards, >> -- >> Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A >> Fortune: >> Don't guess -- check your security regulations. >> >> _______________________________________________ >> 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
_______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
