Re: branches! infernalis vs master, RIP next

[Daniel Gryniewicz]

On Tue, Sep 29, 2015 at 5:12 PM, Sage Weil  wrote:
>
>  1- Target any pull request with a bug fix that should go into infernalis
> at the infernalis branch.


So, currently, anything targeted at both infernalis and master should
have a pull request for infernalis only?  Or for both?

Daniel
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: branches! infernalis vs master, RIP next

[Sage Weil]

On Wed, 30 Sep 2015, Daniel Gryniewicz wrote:
> On Tue, Sep 29, 2015 at 5:12 PM, Sage Weil  wrote:
> >
> >  1- Target any pull request with a bug fix that should go into infernalis
> > at the infernalis branch.
> 
> 
> So, currently, anything targeted at both infernalis and master should
> have a pull request for infernalis only?  Or for both?

Only infernalis.  We will regularly merge infernalis back into 
master up until the final/initial release (9.2.0).

sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: branches! infernalis vs master, RIP next

[Sage Weil]

On Wed, 30 Sep 2015, Loic Dachary wrote:
> On 29/09/2015 23:12, Sage Weil wrote:
> > Having master and infernalis branches follow each other is preventing some 
> > folks from moving forward with post-infernalis work.  And it's confusing.  
> > So, we're proposing a new world order... and this time it should keep 
> > things consistent both during regular development and stabilization 
> > periods:
> > 
> >  master - where new feature work is merged
> >  infernalis ($next_stable) - where bug fixes are merged
> >  hammer, firefly ($previous_stable) - where bug fixes are merged
> > 
> > Previously we had a 'next' branch that was whatever the next pending 
> > release would be.  This will henceforth be named after the next major 
> > release (currently infernalis).  This let's us avoid having next sometimes 
> > during regular development periods and not during stabilization periods.  
> > It also means that we needn't know ahead of time whether the next release 
> > is going to be a development release, rc, or the initial (x.2.0) release 
> > of the next stable series.
> > 
> > That $next_stable branch (currently infernalis) will periodically get 
> > merged back into master, just like next did.  We will stop doing that when 
> > the release is made.  From that point forward, any stable series backports 
> > will be cherry-picked.
> > 
> > The only real difference then between the development and stabilization 
> > periods is that during development we pull in new stuff from master each 
> > time we release, and releases are x.0.z.  During stabilization, we do rc 
> > releases that look like x.1.z, and we don't merge in anything new from 
> > master.
> > 
> > So:
> > 
> >  1- Target any pull request with a bug fix that should go into infernalis 
> > at the infernalis branch.
> > 
> >  2- Before merging anything, make sure it is targetting the right branch.  
> > If it isn't, merge it manually, and verify it isn't pulling in a bunch of 
> > extra stuff (e.g., because a bug fix for infernalis was based on the 
> > current master branch).
> > 
> >  3- We will periodically merge infernalis back into master until the first 
> > infernalis (9.2.0) release.  After that we'll cherry-pick -x.
> > 
> >  4- At that point we'll create a jewel branch that will work the same way.  
> > (It will be regularly merged into master, will eventually result in 10.0.z 
> > releases, and will pull lumps of new stuff from master in each time that 
> > happens.)
> 
> When 10.0.0 is released, the jewel branch is reset to master and will 
> eventually be 10.0.1 etc. Is that right ?

Right!

sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

branches! infernalis vs master, RIP next

[Sage Weil]

Having master and infernalis branches follow each other is preventing some 
folks from moving forward with post-infernalis work.  And it's confusing.  
So, we're proposing a new world order... and this time it should keep 
things consistent both during regular development and stabilization 
periods:

 master - where new feature work is merged
 infernalis ($next_stable) - where bug fixes are merged
 hammer, firefly ($previous_stable) - where bug fixes are merged

Previously we had a 'next' branch that was whatever the next pending 
release would be.  This will henceforth be named after the next major 
release (currently infernalis).  This let's us avoid having next sometimes 
during regular development periods and not during stabilization periods.  
It also means that we needn't know ahead of time whether the next release 
is going to be a development release, rc, or the initial (x.2.0) release 
of the next stable series.

That $next_stable branch (currently infernalis) will periodically get 
merged back into master, just like next did.  We will stop doing that when 
the release is made.  From that point forward, any stable series backports 
will be cherry-picked.

The only real difference then between the development and stabilization 
periods is that during development we pull in new stuff from master each 
time we release, and releases are x.0.z.  During stabilization, we do rc 
releases that look like x.1.z, and we don't merge in anything new from 
master.

So:

 1- Target any pull request with a bug fix that should go into infernalis 
at the infernalis branch.

 2- Before merging anything, make sure it is targetting the right branch.  
If it isn't, merge it manually, and verify it isn't pulling in a bunch of 
extra stuff (e.g., because a bug fix for infernalis was based on the 
current master branch).

 3- We will periodically merge infernalis back into master until the first 
infernalis (9.2.0) release.  After that we'll cherry-pick -x.

 4- At that point we'll create a jewel branch that will work the same way.  
(It will be regularly merged into master, will eventually result in 10.0.z 
releases, and will pull lumps of new stuff from master in each time that 
happens.)

Sound okay?
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: branches! infernalis vs master, RIP next

[Loic Dachary]

On 29/09/2015 23:12, Sage Weil wrote:
> Having master and infernalis branches follow each other is preventing some 
> folks from moving forward with post-infernalis work.  And it's confusing.  
> So, we're proposing a new world order... and this time it should keep 
> things consistent both during regular development and stabilization 
> periods:
> 
>  master - where new feature work is merged
>  infernalis ($next_stable) - where bug fixes are merged
>  hammer, firefly ($previous_stable) - where bug fixes are merged
> 
> Previously we had a 'next' branch that was whatever the next pending 
> release would be.  This will henceforth be named after the next major 
> release (currently infernalis).  This let's us avoid having next sometimes 
> during regular development periods and not during stabilization periods.  
> It also means that we needn't know ahead of time whether the next release 
> is going to be a development release, rc, or the initial (x.2.0) release 
> of the next stable series.
> 
> That $next_stable branch (currently infernalis) will periodically get 
> merged back into master, just like next did.  We will stop doing that when 
> the release is made.  From that point forward, any stable series backports 
> will be cherry-picked.
> 
> The only real difference then between the development and stabilization 
> periods is that during development we pull in new stuff from master each 
> time we release, and releases are x.0.z.  During stabilization, we do rc 
> releases that look like x.1.z, and we don't merge in anything new from 
> master.
> 
> So:
> 
>  1- Target any pull request with a bug fix that should go into infernalis 
> at the infernalis branch.
> 
>  2- Before merging anything, make sure it is targetting the right branch.  
> If it isn't, merge it manually, and verify it isn't pulling in a bunch of 
> extra stuff (e.g., because a bug fix for infernalis was based on the 
> current master branch).
> 
>  3- We will periodically merge infernalis back into master until the first 
> infernalis (9.2.0) release.  After that we'll cherry-pick -x.
> 
>  4- At that point we'll create a jewel branch that will work the same way.  
> (It will be regularly merged into master, will eventually result in 10.0.z 
> releases, and will pull lumps of new stuff from master in each time that 
> happens.)

When 10.0.0 is released, the jewel branch is reset to master and will 
eventually be 10.0.1 etc. Is that right ?

> 
> Sound okay?
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre



signature.asc
Description: OpenPGP digital signature