development/integration branch?

development/integration branch?

[Marc Sune]

Good morning,

Some DPDK users, including myself, use a clone of the git repository to 
compile DPDK for their applications, instead of downloading the tarball 
of each release.

In my opinion, it would be useful for such users that the master branch 
contains only stable releases, to prevent (mistakenly) to use a wip DPDK 
version, and jump quickly to the latest stable with a simple git pull 
without having to check the tags. Also new users would clone the repo 
and get only the stable release.

So I would propose to use an integration/development branch, where the 
patches are integrated and only push to master once a stable release is 
tagged in this integration branch.

Thoughts?

best
marc

Re: development/integration branch?

[Richardson, Bruce]

> -----Original Message-----
> From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Marc Sune
> Sent: Tuesday, October 21, 2014 9:23 AM
> To: <dev-VfR2kkLFssw@public.gmane.org>
> Subject: [dpdk-dev] development/integration branch?
> 
> Good morning,
> 
> Some DPDK users, including myself, use a clone of the git repository to
> compile DPDK for their applications, instead of downloading the tarball
> of each release.
> 
> In my opinion, it would be useful for such users that the master branch
> contains only stable releases, to prevent (mistakenly) to use a wip DPDK
> version, and jump quickly to the latest stable with a simple git pull
> without having to check the tags. Also new users would clone the repo
> and get only the stable release.
> 
> So I would propose to use an integration/development branch, where the
> patches are integrated and only push to master once a stable release is
> tagged in this integration branch.
> 
> Thoughts?
> 
> best
> marc

Ideally, our master branch should always be good and stable, but given reality often interferes with such good intentions I think that having dev branches is not a bad idea. However, what we may lose by doing so is having a larger group of people constantly using the master branch and reporting problems to us. 

On balance, I'd be slightly in favour of this suggestion.

/Bruce

Re: development/integration branch?

[Thomas Monjalon]

2014-10-21 08:36, Richardson, Bruce:
> From: Marc Sune
> > Some DPDK users, including myself, use a clone of the git repository to
> > compile DPDK for their applications, instead of downloading the tarball
> > of each release.
> > 
> > In my opinion, it would be useful for such users that the master branch
> > contains only stable releases, to prevent (mistakenly) to use a wip DPDK
> > version, and jump quickly to the latest stable with a simple git pull
> > without having to check the tags. Also new users would clone the repo
> > and get only the stable release.
> > 
> > So I would propose to use an integration/development branch, where the
> > patches are integrated and only push to master once a stable release is
> > tagged in this integration branch.
> > 
> > Thoughts?
> 
> Ideally, our master branch should always be good and stable, but given
> reality often interferes with such good intentions I think that having
> dev branches is not a bad idea. However, what we may lose by doing so
> is having a larger group of people constantly using the master branch
> and reporting problems to us. 
> 
> On balance, I'd be slightly in favour of this suggestion.

My balance is different because I have a simpler solution for Marc's problem:
	git fetch && git merge $(git tag | grep -v -- -rc | tail -n1)

-- 
Thomas

Re: development/integration branch?

[Marc Sune]

On 21/10/14 10:46, Thomas Monjalon wrote:
> My balance is different because I have a simpler solution for Marc's problem:
> 	git fetch && git merge $(git tag | grep -v -- -rc | tail -n1)
Thomas,

We all know we _can_ do this. But is it really necessary? We should be 
all as lazy as possible and make it easy for users IMHO. `git pull` is 
easier :)

I don't see any drawback of using a development branch, except if you 
consider the extra push to master per release a drawback.

Also think about new users downloading the repo for the first time. They 
are forced to do this right now if they want to checkout the latest stable.

marc

Re: development/integration branch?

[Thomas Monjalon]

2014-10-21 11:14, Marc Sune:
> On 21/10/14 10:46, Thomas Monjalon wrote:
> > My balance is different because I have a simpler solution for Marc's problem:
> > 	git fetch && git merge $(git tag | grep -v -- -rc | tail -n1)
> 
> We all know we _can_ do this. But is it really necessary? We should be 
> all as lazy as possible and make it easy for users IMHO. `git pull` is 
> easier :)

Yes and lazy users download tarballs.

> I don't see any drawback of using a development branch, except if you 
> consider the extra push to master per release a drawback.

No I don't care to push one more thing.
But I care about the message brought by such change. It would mean that
we can break the development branch and that most of developers don't test
it nor base their patches on the latest commit. It's all about simple rules
and messages.

> Also think about new users downloading the repo for the first time. They 
> are forced to do this right now if they want to checkout the latest stable.

New users will get the latest release and expect to see current work in
progress right after cloning the git tree (in master branch).
It's also more common to see work in progress in default branch in cgit.

-- 
Thomas

Re: development/integration branch?

[Marc Sune]

Thomas,

On 21/10/14 11:28, Thomas Monjalon wrote:
> 2014-10-21 11:14, Marc Sune:
>> On 21/10/14 10:46, Thomas Monjalon wrote:
>>> My balance is different because I have a simpler solution for Marc's problem:
>>> 	git fetch && git merge $(git tag | grep -v -- -rc | tail -n1)
>> We all know we _can_ do this. But is it really necessary? We should be
>> all as lazy as possible and make it easy for users IMHO. `git pull` is
>> easier :)
> Yes and lazy users download tarballs.

At least for me, I stopped downloading DPDK tarballs after the third 
time I had to upgrade the release.
>> I don't see any drawback of using a development branch, except if you
>> consider the extra push to master per release a drawback.
> No I don't care to push one more thing.
> But I care about the message brought by such change. It would mean that
> we can break the development branch and that most of developers don't test
> it nor base their patches on the latest commit. It's all about simple rules
> and messages.

I understand your concern but, isn't peer reviewing meant to prevent this?

>> Also think about new users downloading the repo for the first time. They
>> are forced to do this right now if they want to checkout the latest stable.
> New users will get the latest release and expect to see current work in
> progress right after cloning the git tree (in master branch).
> It's also more common to see work in progress in default branch in cgit.
I know, but I also know other projects do the way I proposed with 
success. In any case it was just a suggestion to try to improve things.

marc

Re: development/integration branch?

[Neil Horman]

On Tue, Oct 21, 2014 at 11:38:34AM +0200, Marc Sune wrote:
> Thomas,
> 
> On 21/10/14 11:28, Thomas Monjalon wrote:
> >2014-10-21 11:14, Marc Sune:
> >>On 21/10/14 10:46, Thomas Monjalon wrote:
> >>>My balance is different because I have a simpler solution for Marc's problem:
> >>>	git fetch && git merge $(git tag | grep -v -- -rc | tail -n1)
> >>We all know we _can_ do this. But is it really necessary? We should be
> >>all as lazy as possible and make it easy for users IMHO. `git pull` is
> >>easier :)
> >Yes and lazy users download tarballs.
> 
> At least for me, I stopped downloading DPDK tarballs after the third time I
> had to upgrade the release.
> >>I don't see any drawback of using a development branch, except if you
> >>consider the extra push to master per release a drawback.
> >No I don't care to push one more thing.
> >But I care about the message brought by such change. It would mean that
> >we can break the development branch and that most of developers don't test
> >it nor base their patches on the latest commit. It's all about simple rules
> >and messages.
> 
> I understand your concern but, isn't peer reviewing meant to prevent this?
> 
> >>Also think about new users downloading the repo for the first time. They
> >>are forced to do this right now if they want to checkout the latest stable.
> >New users will get the latest release and expect to see current work in
> >progress right after cloning the git tree (in master branch).
> >It's also more common to see work in progress in default branch in cgit.
> I know, but I also know other projects do the way I proposed with success.
> In any case it was just a suggestion to try to improve things.
> 
> marc
> 

Ideally, I think the best solution (and I've proposed this on the list several
times), is to create a release branch when you begin tagging -rc branches, and
use that branch for stabilization/testing prior to a release.  Only fixes are
allowed in such a branch, and can be merged with master post release-tagging.
That would allow master to continue patch integration undeterred.

Alternatively, doing like Linus does is also a fine idea, announce a merge
window during which features are integrated, and after which new features are
disallowed during the pre-release stabilization period.  Doing so however
requires a high degree of commitment to not make exceptions.  If that is a
concern, then a release branch is the safer approach, as it separates fixes from
other patches.

Neil
 

Re: development/integration branch?

[Matthew Hall]

On Tue, Oct 21, 2014 at 11:28:47AM +0200, Thomas Monjalon wrote:
> But I care about the message brought by such change. It would mean that
> we can break the development branch and that most of developers don't test
> it nor base their patches on the latest commit. It's all about simple rules
> and messages.

I have seen two common ways to do this which I think are about equal.

1) master is latest release in production, develop branch is tip

2) master is tip, production releases live in branches / tags

A lot of non-free stuff uses (1) along with some open source.

So the DPDK is using model (2), which is pretty common for open source.

What I think git in general and DPDK in particular are missing is, they have a 
tradition tags for releases, however I think this is broken because you can't 
easily append more stuff to tages.

I really prefer putting my releases on actual branches to make it as easy as 
possible for users / maintenance programmers to follow and/or add stuff to a 
codeline. For example I'd like a 1.7.X branch I could follow for my app until 
1.8.X is ready.

Having a stable branch would also make stuff easier for guys like Marc who 
want to follow the known-stable release in an easy way without horsing around 
with "the latest tag of the day" all the time.

Perhaps this is an OK option?

Matthew.

Re: development/integration branch?

[Stephen Hemminger]

On Wed, 22 Oct 2014 00:00:58 -0700
Matthew Hall <mhall-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org> wrote:

> What I think git in general and DPDK in particular are missing is, they have a 
> tradition tags for releases, however I think this is broken because you can't 
> easily append more stuff to tages.

In git tags and branches are almost the same thing.
You can easily create a local branch off of a tag.

Re: development/integration branch?

[Matthew Hall]

I am aware of that. But it's a pain to do it. And then your local branch doesn't move forward when new stable releases come out. So I was suggesting we have a stable branch always available and known-good pointing to latest 1.X.X or 2.X.X release of latest stable 1.X or 2.X. It would also be friendly to maintenance programmers who want to submit patches to stable versions and encourage them to contribute stability fixes to DPDK just like Greg KH and the stable kernel guys do for the Long Term kernels.

Matthew.
-- 
Sent from my mobile device.

On October 22, 2014 6:43:36 AM PDT, Stephen Hemminger <stephen@networkplumber.org> wrote:
>On Wed, 22 Oct 2014 00:00:58 -0700
>Matthew Hall <mhall-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org> wrote:
>
>> What I think git in general and DPDK in particular are missing is,
>they have a 
>> tradition tags for releases, however I think this is broken because
>you can't 
>> easily append more stuff to tages.
>
>In git tags and branches are almost the same thing.
>You can easily create a local branch off of a tag.

Re: development/integration branch?

[Stephen Hemminger]

On Tue, 21 Oct 2014 11:14:43 +0200
Marc Sune <marc.sune-kpkqNMk1I7M@public.gmane.org> wrote:

> On 21/10/14 10:46, Thomas Monjalon wrote:
> > My balance is different because I have a simpler solution for Marc's problem:
> > 	git fetch && git merge $(git tag | grep -v -- -rc | tail -n1)
> Thomas,
> 
> We all know we _can_ do this. But is it really necessary? We should be 
> all as lazy as possible and make it easy for users IMHO. `git pull` is 
> easier :)
> 
> I don't see any drawback of using a development branch, except if you 
> consider the extra push to master per release a drawback.
> 
> Also think about new users downloading the repo for the first time. They 
> are forced to do this right now if they want to checkout the latest stable.
> 
> marc

For most project master is the development branch and where patches
should be targeted.

If you want stable branch, then either use releases or volunteer to
maintain a "master-stable" branch.

Re: development/integration branch?

[Marc Sune]

On 21/10/14 15:01, Stephen Hemminger wrote:
> On Tue, 21 Oct 2014 11:14:43 +0200
> Marc Sune <marc.sune-kpkqNMk1I7M@public.gmane.org> wrote:
>
>> On 21/10/14 10:46, Thomas Monjalon wrote:
>>> My balance is different because I have a simpler solution for Marc's problem:
>>> 	git fetch && git merge $(git tag | grep -v -- -rc | tail -n1)
>> Thomas,
>>
>> We all know we _can_ do this. But is it really necessary? We should be
>> all as lazy as possible and make it easy for users IMHO. `git pull` is
>> easier :)
>>
>> I don't see any drawback of using a development branch, except if you
>> consider the extra push to master per release a drawback.
>>
>> Also think about new users downloading the repo for the first time. They
>> are forced to do this right now if they want to checkout the latest stable.
>>
>> marc
> For most project master is the development branch and where patches
> should be targeted.

I don't know if most, but certainly some.

>
> If you want stable branch, then either use releases or volunteer to
> maintain a "master-stable" branch.

There is no need to _maintain_ any master-stable branch because that 
would be == to the latest stable tag, so it is just a push. You can give 
me push access for that if you want.

I also agree that would be interesting  to have release branches, 
independently if the development branch where patches are integrated is 
the master or not.

Marc