[quagga-dev 7751] new dev model?
ccaputo at alt.net
Tue Feb 2 20:07:20 GMT 2010
Has any thought be given to the idea of having each daemon have a
maintainer which manages a per-daemon git tree, each of which acts as a
gateway for patches for the daemon they are responsible for. Once a
maintainer approves of a patch, the patch heads to the master merger(s)
for inclusion in the main tree, with the maintainer's "Signed-off-by:"
stamp. The master merger has less work to do, because they can tend to
trust their per-area maintainers to not be sending broken code up the
This would seem to me to be a way to be a reasonable way to spread out the
workload. The linux folks follow a similar model, with Torvalds at the
top, and various lieutenants overseeing the different parts of the kernel
for which they have an expertise.
Possible sub-areas, which could each have their own maintainer, could be:
build tools & lib & vtysh & watchquagga sub-dirs
Hypothetically, we could have Paul & Ovsienko as the master mergers, which
also includes responsibility for the "build tools & lib & vtysh &
watchquagga" areas. Joakim could be the maintainer for ospfd, while
someone else with an interest and expertise for it, handles ospf6d.
Stephen on bgpd, someone else on isisd, etc, etc. (Actual names to be
determined after this model has support and volunteers come forward.)
When someone wants to do an overhaul, such as a new zebra RIB or
implementation of threading for bgpd, they create a new directory and
become the maintainer for it. That way the interested party can go nuts
on innovation and not be ham-strung by the stability needs of an existing
daemon. Once the new code is ready, it can be included in releases under
a different directory, with optional build hooks. This enables the code
to get out to the community as part of releases, while minimizing risk to
code which is in wide use. Testers can use the new code, and when the new
code reaches parity with the existing, a future release can favor it.
Along with all this, I'd love to see a "-rcX" model in which we have
release candidates that act as a clear indication of lack of readiness.
So next release would be 1.0-rc1 and then 1.0-rc2 and so on until the
master mergers think it is time to call it 1.0. Once 1.0 is out, there
are 1.0.x releases which consist of only priority bug fixes & security
fixes to the 1.0 release. Dev moves on to 1.1-rcX and the process
repeats. The 1.y.x releases can be maintained by an additional volunteer,
so the master mergers aren't bogged down with past releases.
Yes, this is all essentially based on the linux dev model, which I think
More information about the Quagga-dev