bobtail timing

bobtail timing

[Sage Weil]

I would like to freeze v0.55, the "bobtail" stable release, at the end of 
next week.  If there is any functionality you are working on that should 
be included, we need to get it into master (preferably well) before that.  
There will be several weeks of testing in the 'next' branch after that 
(probaly 3 weeks) before it is released.

sage

Re: bobtail timing

[Noah Watkins]

Which branch is the freeze taken against? master?

On Wed, Oct 31, 2012 at 1:46 PM, Sage Weil <sage@inktank.com> wrote:
> I would like to freeze v0.55, the "bobtail" stable release, at the end of
> next week.  If there is any functionality you are working on that should
> be included, we need to get it into master (preferably well) before that.
> There will be several weeks of testing in the 'next' branch after that
> (probaly 3 weeks) before it is released.
>
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: bobtail timing

[Sage Weil]

On Wed, 31 Oct 2012, Noah Watkins wrote:
> Which branch is the freeze taken against? master?

Right.  Basically, every 3-4 weeks:

 - next is tagged as v0.XX
   - and is merged back into master
 - next branch is reset to current master
 - testing branch is reset to just-tagged v0.XX

sage


> 
> On Wed, Oct 31, 2012 at 1:46 PM, Sage Weil <sage@inktank.com> wrote:
> > I would like to freeze v0.55, the "bobtail" stable release, at the end of
> > next week.  If there is any functionality you are working on that should
> > be included, we need to get it into master (preferably well) before that.
> > There will be several weeks of testing in the 'next' branch after that
> > (probaly 3 weeks) before it is released.
> >
> > sage
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: bobtail timing

[Cláudio Martins]

On Wed, 31 Oct 2012 14:38:28 -0700 (PDT) Sage Weil <sage@inktank.com> wrote:
> On Wed, 31 Oct 2012, Noah Watkins wrote:
> > Which branch is the freeze taken against? master?
> 
> Right.  Basically, every 3-4 weeks:
> 
>  - next is tagged as v0.XX
>    - and is merged back into master
>  - next branch is reset to current master
>  - testing branch is reset to just-tagged v0.XX
> 

 Hmm, interesting. But doesn't that mean that when the real v0.XX is
later officially _released_, its top commit might not be the commit
that was tagged as v0.XX? Assuming that issues are found after the
testing branch is reset to v0.XX, fixes would go on top of v0.XX, right?

 Am I missing something, or people checking out a v0.XX with git might
not be getting the real v0.XX that was released as tarballs?

Thanks

Cláudio

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

Re: bobtail timing

[Mike Ryan]

On Thu, Nov 01, 2012 at 03:12:46AM +0000, Cl??udio Martins wrote:
> 
> On Wed, 31 Oct 2012 14:38:28 -0700 (PDT) Sage Weil <sage@inktank.com> wrote:
> > On Wed, 31 Oct 2012, Noah Watkins wrote:
> > > Which branch is the freeze taken against? master?
> > 
> > Right.  Basically, every 3-4 weeks:
> > 
> >  - next is tagged as v0.XX
> >    - and is merged back into master
> >  - next branch is reset to current master
> >  - testing branch is reset to just-tagged v0.XX
> > 
> 
>  Hmm, interesting. But doesn't that mean that when the real v0.XX is
> later officially _released_, its top commit might not be the commit
> that was tagged as v0.XX? Assuming that issues are found after the
> testing branch is reset to v0.XX, fixes would go on top of v0.XX, right?
> 
>  Am I missing something, or people checking out a v0.XX with git might
> not be getting the real v0.XX that was released as tarballs?

The tarball is released as soon as it's tagged. The tag never changes
once it's tagged. Therefore tag v0.XX == tarball v0.XX.

Re: bobtail timing

[Sage Weil]

On Thu, 1 Nov 2012, Cl?udio Martins wrote:
> On Wed, 31 Oct 2012 14:38:28 -0700 (PDT) Sage Weil <sage@inktank.com> wrote:
> > On Wed, 31 Oct 2012, Noah Watkins wrote:
> > > Which branch is the freeze taken against? master?
> > 
> > Right.  Basically, every 3-4 weeks:
> > 
> >  - next is tagged as v0.XX
> >    - and is merged back into master
> >  - next branch is reset to current master
> >  - testing branch is reset to just-tagged v0.XX
> > 
> 
>  Hmm, interesting. But doesn't that mean that when the real v0.XX is
> later officially _released_, its top commit might not be the commit
> that was tagged as v0.XX? Assuming that issues are found after the
> testing branch is reset to v0.XX, fixes would go on top of v0.XX, right?
> 
>  Am I missing something, or people checking out a v0.XX with git might
> not be getting the real v0.XX that was released as tarballs?

The releases and tarballs contain *exactly* the content that is tagged 
v0.X.  The branches may accumulate additional fixes after that, which 
will later be tagged with a v0.X.Y point release.  Since we've started 
maintaing a stable release, we haven't done point releases for 
the development 'testing' releases, although if there are important bugs 
we may need to do so in the future.

The 'stable' branch tracks the last stable release (currently argonaut) 
and is where bug fixes accumulate until the next release.  For example, 
stable current contains v0.48.2 and several additional commits (mostly 
backports of proviioning scripts to support the ceph-deploy tool that 
we're working on).

sage

Re: bobtail timing

[Cláudio Martins]

On Wed, 31 Oct 2012 20:17:49 -0700 (PDT) Sage Weil <sage@inktank.com> wrote:
> On Thu, 1 Nov 2012, Cl?udio Martins wrote:
> > On Wed, 31 Oct 2012 14:38:28 -0700 (PDT) Sage Weil <sage@inktank.com> wrote:
> > > On Wed, 31 Oct 2012, Noah Watkins wrote:
> > > > Which branch is the freeze taken against? master?
> > > 
> > > Right.  Basically, every 3-4 weeks:
> > > 
> > >  - next is tagged as v0.XX
> > >    - and is merged back into master
> > >  - next branch is reset to current master
> > >  - testing branch is reset to just-tagged v0.XX
> > > 
> > 
> >  Hmm, interesting. But doesn't that mean that when the real v0.XX is
> > later officially _released_, its top commit might not be the commit
> > that was tagged as v0.XX? Assuming that issues are found after the
> > testing branch is reset to v0.XX, fixes would go on top of v0.XX, right?
> > 
> >  Am I missing something, or people checking out a v0.XX with git might
> > not be getting the real v0.XX that was released as tarballs?
> 
> The releases and tarballs contain *exactly* the content that is tagged 
> v0.X.  The branches may accumulate additional fixes after that, which 
> will later be tagged with a v0.X.Y point release.  Since we've started 
> maintaing a stable release, we haven't done point releases for 
> the development 'testing' releases, although if there are important bugs 
> we may need to do so in the future.
> 
> The 'stable' branch tracks the last stable release (currently argonaut) 
> and is where bug fixes accumulate until the next release.  For example, 
> stable current contains v0.48.2 and several additional commits (mostly 
> backports of proviioning scripts to support the ceph-deploy tool that 
> we're working on).
> 

 Ok, it makes perfect sense now. I wasn't realising that the tarball is
released as soon as the branch is tagged, sorry about that.

Thanks for the clarification.

Best regards

Cláudio

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

Re: bobtail timing

[Yehuda Sadeh]

On Wed, Oct 31, 2012 at 1:46 PM, Sage Weil <sage@inktank.com> wrote:
> I would like to freeze v0.55, the "bobtail" stable release, at the end of
> next week.  If there is any functionality you are working on that should
> be included, we need to get it into master (preferably well) before that.
> There will be several weeks of testing in the 'next' branch after that
> (probaly 3 weeks) before it is released.

I merged (against current master) and pushed all the pending rgw stuff
to wip-rgw-integration. This includes:

wip-post-cleaned
wip-stripe
wip-keystone
wip-3452
wip-3453
wip-swift-token

All that stuff needs to go into bobtail, but still waiting for review.
The bottom 3 are trivial.

Yehuda

Re: bobtail timing

[Samuel Just]

I've got wip_recovery_qos and wip_persist_missing that should go into bobtail.

wip_recovery_qos passed regression (mostly, failures due to fsx, a bug
fixed in master, and timeouts waiting for machines), and is waiting on
review.

wip_persist_missing has a teuthology test I'll push tomorrow
(wip_divergent_priors).  The second commit in wip_persist_missing I
think still needs review (formerly wip_divergent_entries).
-Sam

On Thu, Nov 8, 2012 at 5:30 PM, Yehuda Sadeh <yehuda@inktank.com> wrote:
> On Wed, Oct 31, 2012 at 1:46 PM, Sage Weil <sage@inktank.com> wrote:
>> I would like to freeze v0.55, the "bobtail" stable release, at the end of
>> next week.  If there is any functionality you are working on that should
>> be included, we need to get it into master (preferably well) before that.
>> There will be several weeks of testing in the 'next' branch after that
>> (probaly 3 weeks) before it is released.
>
> I merged (against current master) and pushed all the pending rgw stuff
> to wip-rgw-integration. This includes:
>
> wip-post-cleaned
> wip-stripe
> wip-keystone
> wip-3452
> wip-3453
> wip-swift-token
>
> All that stuff needs to go into bobtail, but still waiting for review.
> The bottom 3 are trivial.
>
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html