[quagga-dev 7757] Re: new dev model?

Balaji G balajig81 at gmail.com
Wed Feb 3 05:12:17 GMT 2010

Hi Everybody

I agree to the above thread.I spoke to Paul too on this and i guess
this sub maintainers concept works well. I could chip in with my
contributions too and help track patches and apply it to the branch. I
guess we could follow something that's followed in the linux network
subsystem which i am part of. I guess Stephen would know it in and
out. People send out the patches David applies it and sends out an
email in that way we could ask people to pull it . I could do whatever
i could from my end for sure.

Just my thoughts

  - Balaji

On 2/3/10, Stephen Hemminger <shemminger at vyatta.com> wrote:
> On Tue, 2 Feb 2010 20:07:20 +0000 (UTC)
> Chris Caputo <ccaputo at alt.net> wrote:
>> 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
>>   ...
> The problem is lack of full-time maintainers and conflict between
> production and development folks.  As a Linux kernel developer, I like
> the sub-maintainer concept; but a project has to accept changes at full
> speed
> (keep up with the fire hose). And sure there are problems that need redesign
> and refactoring, but there is no reason to split off and go away to a
> developer branch, it is perfectly possible to slip stream in redesigns
> incrementally. The three month cycle works out. With merge window in
> the first month.
> The bigger issue is the quagga community is small, and the number
> of willing testers is small.
> --
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev

More information about the Quagga-dev mailing list