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

[Bruce Simpson]

Ben Greear wrote:
>> If I had to pin down one Fedora release for XORP community support,
>> which one would you recommend?
>
> The latest (FC 11, currently).  If you can get something building rpms
> for that, it's very likely someone else (perhaps me) can easily get it 
> working on
> older systems for those who care.

OK. Fedora 11 it is. XORP's SCONS build seems to compile there. There is 
no regression test coverage at the moment.

[Given there have been no functional changes to the code -- just the 
build system -- I am not going to be losing any sleep over having no 
regression test coverage.]

>   I can't necessarily test all releases,
> but I have lots of different build machines (FC2, FC5, FC8, FC8-64, 
> F11-64,
> buntu 9.04, etc).

Ubuntu 9.04 I've touched.

>
> Please also understand:  I am running fairly heavily patched xorp, and
> that will be my personal focus.  I'll try to get as much of these 
> patches accepted
> upstream as possible when the public tree opens again, but I'm not sure
> how much of that will actually be accepted.

OK. Will need to consider on case-by-case basis. It's likely that the 
approach to a lot of stuff there will change radically.

>
>> The Boost project ship a run.py script which automatically gathers
>> everything, and submits an XML report upstream:
>>
>
> I doubt I'd have time to do any significant work on something like this.
>
> I think it would be better to see what kind of user reports come in
> and then concentrate on fixing whatever bugs people find.

As you can see from the traffic we get from this list, most of the 
queries are pretty basic, or concern problems configuring essential 
/basic features.

    I don't really have free time/energy to delve into every detail of 
what they run into at the moment, *and* fix what I'm trying to fix 
elsewhere, sadly.
    My hope would be that we could get folk within XORP, Inc. to play 
more of a role in this, say 1 hour on a Friday afternoon 'doing' 
community work, but of course this involves breathing life back into the 
community branch.

    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.

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.

If I weren't hacking SVN and SCons* files, and setting up VMs like a mad 
axeman this week, I might have more time to deal with these issues...

>
> I'm very interested to know how Xorp plans to handle the public tree
> v/s whatever else they have going.

At the moment, our hands are tied. We're waiting for the legal dust to 
settle. I am working flat out to get GNU autotools axed and some sort of 
sanity into community releases.

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

    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?

For what it's worth, Macromedia had a similar situation on their hands 
with Flash and Shockwave. Those are also moderately large C++  systems. 
Folk from that org I've spoken to say it takes 12-18 months to get 
proficient in their code base.

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


> In my experience, nothing rots faster than
> automated regression tests and builds.

They can also cry wolf, and are easy to ignore.

cheers,
BMS