Re: [dpdk-dev] GIT workflow model to help solve some of the problems

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wiles, Keith
> Sent: Thursday, October 22, 2015 2:14 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] GIT workflow model to help solve some of the problems
> 
> I have been looking at the a GIT flow model that seems to help with our
> backlog problem and how we stage releases.
> 
> I found this model a few years ago and find it to be very reasonable and
> helps us with development.
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> The model may not be perfect, but it does give us the next branch via the
> develop branch and gets any bugs/patches off the master branch. I have not
> found a simpler solution that does not have problem and this one may have
> problems as well, but it seem to be reasonable. Some call the develop
> branch the ‘next’ branch, but it does not matter what it is called IMO.
> 
> —
> Regards,
> ++Keith Wiles
> Intel Corporation

Hi Keith,

I agree that such a git model can work very well, and indeed we used to use something a bit like it internally on DPDK development in the pre-dpdk.org era. However, I don't think a branching model will solve the patch backlog issues we are currently having on dpdk.org, as the branching strategy can't possibly affect the speed at which reviews of patches get done, or how quickly reviewed patches get applied to the mainline for the next release. I believe that our problems are more caused by the limitation of 24 hours in a day, than in a lack of branches (or whole trees) in git. :-)

To try and solve the backlog, it's been discussed trying to scale things by increasing the number of committers on the project - specifically sub-tree maintainers - so as to reduce Thomas's direct workload. Thomas was hinting repeatedly at the userspace conference that he'd like me to take over as committer for a separate drivers/net subtree, and (following some arm-twisting from various sources :-)) I've decided that I do indeed need to take on such a role starting from the 2.3 release. [Declan has similarly already volunteered to maintain a subtree for crypto drivers.] I'm sure I'll learn soon enough what I've let myself in for! :-)

With regards to branches, I believe at userspace Stephen H had volunteered some time/resources to see about back-porting fixes to earlier releases, which presumably necessitates separate release branches like that in the link you sent. Stephen, any follow-up on that - is it still a possibility?

Regards,
/Bruce