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

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

[Wiles, Keith]

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

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

[Richardson, Bruce]

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

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

[Wiles, Keith]

— 
Regards,
++Keith Wiles

Intel Corporation







On 10/22/15, 6:56 AM, "Richardson, Bruce" <bruce.richardson@intel.com> wrote:

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

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

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

[Stephen Hemminger]

The issue is the speed of review and merging.
Adding branching will make this worse not better, because there will
be more branches no one is looking at.

I made some concrete suggestions at the DPDK Userspace Summit
that would help if implemented.