[quagga-dev 7751] new dev model?

Chris Caputo 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 
line.

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
  zebra
  bgpd
  isisd
  ospfd
  ospf6d
  ripd
  ripngd
  ...

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 
works well.

Thoughts?

Chris



More information about the Quagga-dev mailing list