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

Balaji G balajig81 at gmail.com
Thu Feb 4 05:10:42 GMT 2010


> I'm happy to contribute the uml containers (and will try to help with QA)
That's great and yes UML would certainly help a lot

> Any ideas of creating harnesses or scenarios for functions of  quagga
> and then maybe vetting them (esp as new functionality is added?)
> (Would you like me to try and write some?)

We have new features queued up for 1.0 and 1.0 + releases but thats
not currently in the mainline those patches are queued up. you could
probably look into the mails and find out and my patches are @ my
branch.

>
> I have labs written for a particular configurations of  UML containers
> that could be extended to functionally test, provided the tests could
> be scripted.

It would really help coz with UML you could do good topologies and the
routing protocol part would get tested to a good extent and saves time
too.

> Are there protocol test suites in the existing source trees now?

As far as i know,I dont think so we have protocol test suites in the
source trees. If you wish to add you could probably contact Paul on
this.

Cheers,
 - Balaji



On 2/4/10, Adrian Terranova <aterranova at gmail.com> wrote:
> I'm happy to contribute the uml containers (and will try to help with QA)
>
> Any ideas of creating harnesses or scenarios for functions of  quagga
> and then maybe vetting them (esp as new functionality is added?)
> (Would you like me to try and write some?)
>
> I have labs written for a particular configurations of  UML containers
> that could be extended to functionally test, provided the tests could
> be scripted.
>
> Are there protocol test suites in the existing source trees now?
>
> --Adrian
>
> On Wed, Feb 3, 2010 at 12:12 AM, Balaji G <balajig81 at gmail.com> wrote:
>> 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
>>
>> Cheers,
>>  - 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
>>>
>> _______________________________________________
>> 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