Ben Greear <[email protected]> writes:
>> It's difficult with only one hand on deck (myself) on the community
>> branch to do this, whilst we have changes in-flight, and whilst the code
>> is a moving target. To minimize churn, I tend to fork feature branches
>> and re-incorporate them further on; both the Windows port, and OLSR
>> code, were developed in this way.
>>
> Considering the small developer and testing base, I think forking
> would be a bad idea.
Hi Ben, Bruce,
I think the term "forking" should be avoided. It's a emotionally
loaded term that should be reserved for talking about when a project
splits into multiples. I hope that now the XORP open source project
is now hosted at sourceforge and has an independent community, there
will be no one who feels they need to create/maintain a fork to
accomplish their goals.
Now feature branches on the other hand... My understanding that in
the past, there was very little use of branches. Even the release
process essentially locked the repo while the release was being cut
(In my experience, this discourages developer activity during the
weeks it takes to make a solid release). It also made it difficult to
do bold and interesting experiments that may or may not pan out, or
long term infrastructure improvements that might take several release
cycles to complete since there was no place to collaborate on them
(Bruce's plan to replace XRL's with Thrift might fit both of those
categories).
Now that the project has moved from CVS to SVN, which has better
branch and merge support, I agree with Bruce that we should be using
them for release and feature development. And Ben, I don't think of
feature branches as some sort of limbo, but rather a staging area
where substantial pieces of work can be integrated so when they are
merged into the trunk, it will have minimal impact. From what I've
seen of the FEA virtualization patch, I think we can consider it
substantial.
> I think we should merge all that we possibly can and the have as
> many people as possible test it. I won't harp on this more, however
> :)
For 1.7, I think the priority should be to shake out the bugs in the
new build system. I'm afraid that if we start integrating new code,
we won't be able to make a release in a timely manner.
After the release, I'm all in favor of looking at what the best way to
integrate changes like Ben's.
--jtc
--
J.T. Conklin
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
