[Xorp-users] Call for feedback/volunteers: Build system, platform tier support.

[Ben Greear]

On 07/16/2009 06:13 AM, Bruce Simpson wrote:

> One big concern of mine is that we get a lot of people wanting to use
> XORP, who have no clue about hacking C++ (And why should
> they...arguments abound), and either don't want to learn, or don't have
> time to. It is a hard tool to use, and hopefully, sorting out the middle
> tier will help. I need to stay focused on that goal.

They shouldn't need to know anything about c++ to use it, only to hack
on it.

For me, the biggest problem was figuring out the code paths since you
have interprocess communication through an opaque middle layer.  There is
little you can grep for or otherwise follow in order to see what calls
go where.

After several years, I have less trouble.  Not every project can be simple,
an a distributed multi-process router daemon might just be one of those that
will always be a bit tricky :)

> There's knowledge locked up in the minds of the original development
> team 'oh this assertion means that, etc'. which is pretty essential to
> debugging these issues.

The more asserts that are removed (replaced with better error handling and/or
detailed error messages to the users) the better, as far as I'm concerned.

>> I see hints that outside developers
>> will be given some sort of commit privileges, but it's my opinion that
>> some Xorp person should be the gatekeeper (much as Linus is for Linux).
>
> It's pretty much essential -- the XORP C++ code can be impenetrable to
> those who haven't spent years studying it. This should NOT be the case.
>
> The problem is that having one person as that gatekeeper effectively
> overloads them, and makes it difficult for them to do other stuff, if
> that's all they're doing.

That is true.  If Xorp.com wants to harness the energy of the community,
the cost is likely going to be paying a very good engineer to act as
gatekeeper and integrator.

If xorp.com is going to use the community tree similar to how RedHat uses
Fedora, then it is beneficial to have good engineers hacking on it, with
the idea that the stable code will be integrated into xorp's commercial
offerings.

If they are not going to put any energy into it, then the first person that
cares will probably fork it.  Since the code is GPL, it seems xorp.com has
nothing to gain by letting the community branch hang in the wind.

> One of my hopes with Thrift + Boost is that we can lower the bar to
> entry in the XORP development community. It's 2009, we understand
> protocols need to run fast and be tightly coupled to the kernel, for
> embedded use. But it's feasible to embed scripting languages now -- it
> just depends how tightly you define 'embedded', embedded for what?

Lets get a community tree up and functional and then see what the
patches look like.

>> Otherwise, there may be no one to keep me from dumping all of my
>> virtualization patches upstream, which would obviously be great for me,
>> but perhaps of questionable use for others ;)
>
> Features are cool, but they need a test framework, especially if radical
> in nature.

My LANforge product basically is a test framework for Xorp.  For the more complex
things (adding/removing network interfaces dynamically, in large OSPF meshes, etc),
you can't really do it manually, and you surely can't do it with a simple script.


Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com