? Regards, ++Keith Wiles Intel Corporation
On 10/22/15, 6:56 AM, "Richardson, Bruce" <bruce.richardson at intel.com> wrote: > > >> -----Original Message----- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wiles, Keith >> Sent: Thursday, October 22, 2015 2:14 PM >> To: dev at 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. :-) I had no dreams this would solve the backlog problem, but I thought everyone wanted a different repo for the ?next? stuff and I was hoping to point out that a branch will work plus if we adopt a branching model then it would be clearer to everyone IMO. > >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! :-) Today we use basically the master only with patches and a branching model should help others with how and when they can merge into the release branch and master. A next release branch would help to focus everyone IMO. > >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
