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