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 [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Don't guess -- check your security regulations.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
