All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linh Vu <vul-keaFvQtjc6i7NGdpmJTKYQ@public.gmane.org>
To: Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org>,
	"ceph-users-Qp0mS5GaXlQ@public.gmane.org"
	<ceph-users-Qp0mS5GaXlQ@public.gmane.org>,
	"ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"dev-a8pt6IJUokc@public.gmane.org"
	<dev-a8pt6IJUokc@public.gmane.org>
Subject: Re: Changing the release cadence
Date: Thu, 6 Jun 2019 00:31:53 +0000	[thread overview]
Message-ID: <ME1PR01MB070645B4EDCB63853433D02A81170@ME1PR01MB0706.ausprd01.prod.outlook.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1906051556500.987-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 3971 bytes --]

I think 12 months cycle is much better from the cluster operations perspective. I also like March as a release month as well.
________________________________
From: ceph-users <ceph-users-bounces-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org> on behalf of Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org>
Sent: Thursday, 6 June 2019 1:57 AM
To: ceph-users-Qp0mS5GaXlQ@public.gmane.org; ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; dev-a8pt6IJUokc@public.gmane.org
Subject: [ceph-users] Changing the release cadence

Hi everyone,

Since luminous, we have had the follow release cadence and policy:
 - release every 9 months
 - maintain backports for the last two releases
 - enable upgrades to move either 1 or 2 releases heads
   (e.g., luminous -> mimic or nautilus; mimic -> nautilus or octopus; ...)

This has mostly worked out well, except that the mimic release received
less attention that we wanted due to the fact that multiple downstream
Ceph products (from Red Has and SUSE) decided to based their next release
on nautilus.  Even though upstream every release is an "LTS" release, as a
practical matter mimic got less attention than luminous or nautilus.

We've had several requests/proposals to shift to a 12 month cadence. This
has several advantages:

 - Stable/conservative clusters only have to be upgraded every 2 years
   (instead of every 18 months)
 - Yearly releases are more likely to intersect with downstream
   distribution release (e.g., Debian).  In the past there have been
   problems where the Ceph releases included in consecutive releases of a
   distro weren't easily upgradeable.
 - Vendors that make downstream Ceph distributions/products tend to
   release yearly.  Aligning with those vendors means they are more likely
   to productize *every* Ceph release.  This will help make every Ceph
   release an "LTS" release (not just in name but also in terms of
   maintenance attention).

So far the balance of opinion seems to favor a shift to a 12 month
cycle[1], especially among developers, so it seems pretty likely we'll
make that shift.  (If you do have strong concerns about such a move, now
is the time to raise them.)

That brings us to an important decision: what time of year should we
release?  Once we pick the timing, we'll be releasing at that time *every
year* for each release (barring another schedule shift, which we want to
avoid), so let's choose carefully!

A few options:

 - November: If we release Octopus 9 months from the Nautilus release
   (planned for Feb, released in Mar) then we'd target this November.  We
   could shift to a 12 months candence after that.
 - February: That's 12 months from the Nautilus target.
 - March: That's 12 months from when Nautilus was *actually* released.

November is nice in the sense that we'd wrap things up before the
holidays.  It's less good in that users may not be inclined to install the
new release when many developers will be less available in December.

February kind of sucked in that the scramble to get the last few things
done happened during the holidays.  OTOH, we should be doing what we can
to avoid such scrambles, so that might not be something we should factor
in.  March may be a bit more balanced, with a solid 3 months before when
people are productive, and 3 months after before they disappear on holiday
to address any post-release issues.

People tend to be somewhat less available over the summer months due to
holidays etc, so an early or late summer release might also be less than
ideal.

Thoughts?  If we can narrow it down to a few options maybe we could do a
poll to gauge user preferences.

Thanks!
sage


[1] https://twitter.com/larsmb/status/1130010208971952129

_______________________________________________
ceph-users mailing list
ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com


[-- Attachment #1.2: Type: text/html, Size: 5417 bytes --]

[-- Attachment #2: Type: text/plain, Size: 178 bytes --]

_______________________________________________
ceph-users mailing list
ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

  parent reply	other threads:[~2019-06-06  0:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 15:57 Changing the release cadence Sage Weil
     [not found] ` <alpine.DEB.2.11.1906051556500.987-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>
2019-06-05 17:37   ` Daniel Baumann
2019-06-05 19:16   ` Alexandre DERUMIER
     [not found]     ` <12252276.433203.1559762173198.JavaMail.zimbra-U/x3PoR4x10AvxtiuMwx3w@public.gmane.org>
2019-06-05 20:27       ` Chris Taylor
2019-06-06  0:31   ` Linh Vu [this message]
     [not found]     ` <ME1PR01MB070645B4EDCB63853433D02A81170-2wSXk0H63TwVj78W2k5HnsNU+h3Mz0HLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2019-06-06  7:26       ` Xiaoxi Chen
     [not found]         ` <CAEYCsVLdWh_hGQN+LoTrX1=BOVJZ-ras+PTGgRJ0n1Z_3-P3dw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-06  7:37           ` Daniel Baumann
2019-06-17 16:21   ` Sage Weil
     [not found]     ` <alpine.DEB.2.11.1906171621000.20504-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>
2019-06-17 20:08       ` David Turner
     [not found]         ` <CAN-Gep+9bxadHMTFQgUFUt_q9Jmfpy3MPU5UTTRNY1jueu7n9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-18  5:39           ` Daniel Baumann
2019-06-25 14:31           ` Alfredo Deza
     [not found]             ` <CAC-Np1zcniBxm84SEGhzYfu55t+fckg1d-Dq0xpab62+ON4K5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-26 12:55               ` Sage Weil
     [not found]             ` <CAE6AcseMEfRjRtA0iUPMwsQPP+ebEqDDHYeWUpXWGeWTggnKRw@mail.gmail.com>
     [not found]               ` <CAE6AcseMEfRjRtA0iUPMwsQPP+ebEqDDHYeWUpXWGeWTggnKRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-06-26 12:57                 ` Sage Weil
     [not found]                   ` <alpine.DEB.2.11.1906261255530.17148-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>
2019-06-26 14:45                     ` Sage Weil
     [not found]                       ` <alpine.DEB.2.11.1906261437280.17148-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>
2019-06-26 14:56                         ` Bob Farrell
2019-06-26 15:21                         ` Lars Marowsky-Bree
2019-07-22  3:03   ` Brent Kennedy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ME1PR01MB070645B4EDCB63853433D02A81170@ME1PR01MB0706.ausprd01.prod.outlook.com \
    --to=vul-keafvqtjc6i7ngdpmjtkyq@public.gmane.org \
    --cc=ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ceph-users-Qp0mS5GaXlQ@public.gmane.org \
    --cc=dev-a8pt6IJUokc@public.gmane.org \
    --cc=sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.