* Changing the release cadence @ 2019-06-05 15:57 Sage Weil [not found] ` <alpine.DEB.2.11.1906051556500.987-qHenpvqtifaMSRpgCs4c+g@public.gmane.org> 0 siblings, 1 reply; 17+ messages in thread From: Sage Weil @ 2019-06-05 15:57 UTC (permalink / raw) To: ceph-users-Qp0mS5GaXlQ, ceph-devel-u79uwXL29TY76Z2rM5mHXA, dev-a8pt6IJUokc 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <alpine.DEB.2.11.1906051556500.987-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>]
* Re: Changing the release cadence [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 ` (3 subsequent siblings) 4 siblings, 0 replies; 17+ messages in thread From: Daniel Baumann @ 2019-06-05 17:37 UTC (permalink / raw) To: ceph-users-Qp0mS5GaXlQ; +Cc: ceph-devel-u79uwXL29TY76Z2rM5mHXA, dev-a8pt6IJUokc On 6/5/19 5:57 PM, Sage Weil wrote: > So far the balance of opinion seems to favor a shift to a 12 month > cycle [...] it seems pretty likely we'll make that shift. thanks, much appreciated (from an cluster operating point of view). > Thoughts? GNOME and a few others are doing April and October releases which seems balanced and to be good timing for most people; personally I prefer spring rather than autum for upgrades, hence.. would suggest April. Regards, Daniel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Changing the release cadence [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-06 0:31 ` Linh Vu ` (2 subsequent siblings) 4 siblings, 1 reply; 17+ messages in thread From: Alexandre DERUMIER @ 2019-06-05 19:16 UTC (permalink / raw) To: Sage Weil; +Cc: ceph-devel, ceph-users, dev-a8pt6IJUokc Hi, >>- 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. For the 2 last debian releases, the freeze was around january-february, november seem to be a good time for ceph release. ----- Mail original ----- De: "Sage Weil" <sage@newdream.net> À: "ceph-users" <ceph-users@ceph.com>, "ceph-devel" <ceph-devel@vger.kernel.org>, dev@ceph.io Envoyé: Mercredi 5 Juin 2019 17:57:52 Objet: 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@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <12252276.433203.1559762173198.JavaMail.zimbra-U/x3PoR4x10AvxtiuMwx3w@public.gmane.org>]
* Re: Changing the release cadence [not found] ` <12252276.433203.1559762173198.JavaMail.zimbra-U/x3PoR4x10AvxtiuMwx3w@public.gmane.org> @ 2019-06-05 20:27 ` Chris Taylor 0 siblings, 0 replies; 17+ messages in thread From: Chris Taylor @ 2019-06-05 20:27 UTC (permalink / raw) To: Alexandre DERUMIER; +Cc: ceph-devel, ceph-users, dev-a8pt6IJUokc It seems like since the change to the 9 months cadence it has been bumpy for the Debian based installs. Changing to a 12 month cadence sounds like a good idea. Perhaps some Debian maintainers can suggest a good month for them to get the packages in time for their release cycle. On 2019-06-05 12:16 pm, Alexandre DERUMIER wrote: > Hi, > > >>> - 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. > > For the 2 last debian releases, the freeze was around january-february, > november seem to be a good time for ceph release. > > ----- Mail original ----- > De: "Sage Weil" <sage@newdream.net> > À: "ceph-users" <ceph-users@ceph.com>, "ceph-devel" > <ceph-devel@vger.kernel.org>, dev@ceph.io > Envoyé: Mercredi 5 Juin 2019 17:57:52 > Objet: 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@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Changing the release cadence [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 @ 2019-06-06 0:31 ` Linh Vu [not found] ` <ME1PR01MB070645B4EDCB63853433D02A81170-2wSXk0H63TwVj78W2k5HnsNU+h3Mz0HLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> 2019-06-17 16:21 ` Sage Weil 2019-07-22 3:03 ` Brent Kennedy 4 siblings, 1 reply; 17+ messages in thread From: Linh Vu @ 2019-06-06 0:31 UTC (permalink / raw) To: Sage Weil, ceph-users-Qp0mS5GaXlQ, ceph-devel-u79uwXL29TY76Z2rM5mHXA, dev-a8pt6IJUokc [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <ME1PR01MB070645B4EDCB63853433D02A81170-2wSXk0H63TwVj78W2k5HnsNU+h3Mz0HLvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>]
* Re: Changing the release cadence [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> 0 siblings, 1 reply; 17+ messages in thread From: Xiaoxi Chen @ 2019-06-06 7:26 UTC (permalink / raw) To: Linh Vu Cc: ceph-devel-u79uwXL29TY76Z2rM5mHXA, ceph-users-Qp0mS5GaXlQ, dev-a8pt6IJUokc We go with upstream release and mostly Nautilus now, probably the most aggressive ones among serious production user (i.e tens of PB+ ), I will vote for November for several reasons: 1. Q4 is holiday season and usually production rollout was blocked , especially storage related change, which usually give team more time to prepare/ testing/ LnP the new releases, as well as catch up with new features. 2. Q4/Q1 is usually the planning season, having the upstream released and testing to know the readiness of new feature, will greatly helps when planning the feature/offering of next year. 3. Users have whole year to migrate their provision/monitoring/deployment/remediation system to new version, and have enough time to fix and stable the surrounding system before next holiday season. Release in Feb or March will make the Q4 just in the middle of the cycle, and lot of changes will land at last minutes(month), in which case, few things can be test and forecasted based on the state-of-art in Q4. -Xiaoxi Linh Vu <vul@unimelb.edu.au> 于2019年6月6日周四 上午8:32写道: > > 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@lists.ceph.com> on behalf of Sage Weil <sage@newdream.net> > Sent: Thursday, 6 June 2019 1:57 AM > To: ceph-users@ceph.com; ceph-devel@vger.kernel.org; dev@ceph.io > 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://protect-au.mimecast.com/s/N1l6CROAEns1RN1Zu9Jwts?domain=twitter.com > > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAEYCsVLdWh_hGQN+LoTrX1=BOVJZ-ras+PTGgRJ0n1Z_3-P3dw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Changing the release cadence [not found] ` <CAEYCsVLdWh_hGQN+LoTrX1=BOVJZ-ras+PTGgRJ0n1Z_3-P3dw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2019-06-06 7:37 ` Daniel Baumann 0 siblings, 0 replies; 17+ messages in thread From: Daniel Baumann @ 2019-06-06 7:37 UTC (permalink / raw) To: ceph-users-Qp0mS5GaXlQ; +Cc: ceph-devel-u79uwXL29TY76Z2rM5mHXA, dev-a8pt6IJUokc On 6/6/19 9:26 AM, Xiaoxi Chen wrote: > I will vote for November for several reasons: [...] as an academic institution we're aligned by August to July (school year) instead of the January to December (calendar year), so all your reasons (thanks!) are valid for us.. just shifted by 6 months, hence Q1 is ideal for us. however, given that academic institutions are the minority, I'm convinced now that November is the better choice for everyone. Regards, Daniel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Changing the release cadence [not found] ` <alpine.DEB.2.11.1906051556500.987-qHenpvqtifaMSRpgCs4c+g@public.gmane.org> ` (2 preceding siblings ...) 2019-06-06 0:31 ` Linh Vu @ 2019-06-17 16:21 ` Sage Weil [not found] ` <alpine.DEB.2.11.1906171621000.20504-qHenpvqtifaMSRpgCs4c+g@public.gmane.org> 2019-07-22 3:03 ` Brent Kennedy 4 siblings, 1 reply; 17+ messages in thread From: Sage Weil @ 2019-06-17 16:21 UTC (permalink / raw) To: ceph-users-Qp0mS5GaXlQ, ceph-devel-u79uwXL29TY76Z2rM5mHXA, dev-a8pt6IJUokc On Wed, 5 Jun 2019, Sage Weil wrote: > 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! I've put up a twitter poll: https://twitter.com/liewegas/status/1140655233430970369 Thanks! sage ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <alpine.DEB.2.11.1906171621000.20504-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>]
* Re: Changing the release cadence [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> 0 siblings, 1 reply; 17+ messages in thread From: David Turner @ 2019-06-17 20:08 UTC (permalink / raw) To: Sage Weil; +Cc: Ceph Devel, Ceph-User, dev-a8pt6IJUokc [-- Attachment #1.1: Type: text/plain, Size: 1123 bytes --] This was a little long to respond with on Twitter, so I thought I'd share my thoughts here. I love the idea of a 12 month cadence. I like October because admins aren't upgrading production within the first few months of a new release. It gives it plenty of time to be stable for the OS distros as well as giving admins something low-key to work on over the holidays with testing the new releases in stage/QA. On Mon, Jun 17, 2019 at 12:22 PM Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org> wrote: > On Wed, 5 Jun 2019, Sage Weil wrote: > > 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! > > I've put up a twitter poll: > > https://twitter.com/liewegas/status/1140655233430970369 > > Thanks! > sage > _______________________________________________ > 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: 1755 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAN-Gep+9bxadHMTFQgUFUt_q9Jmfpy3MPU5UTTRNY1jueu7n9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Changing the release cadence [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 1 sibling, 0 replies; 17+ messages in thread From: Daniel Baumann @ 2019-06-18 5:39 UTC (permalink / raw) To: ceph-users-Qp0mS5GaXlQ; +Cc: ceph-devel-u79uwXL29TY76Z2rM5mHXA, dev-a8pt6IJUokc Hi, I didn't bother to create a twitter account just to be able to participate in the poll.. so.. please count me in for October. Regards, Daniel ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Changing the release cadence [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> [not found] ` <CAE6AcseMEfRjRtA0iUPMwsQPP+ebEqDDHYeWUpXWGeWTggnKRw@mail.gmail.com> 1 sibling, 2 replies; 17+ messages in thread From: Alfredo Deza @ 2019-06-25 14:31 UTC (permalink / raw) To: David Turner; +Cc: Ceph Devel, Ceph-User, dev-a8pt6IJUokc On Mon, Jun 17, 2019 at 4:09 PM David Turner <drakonstein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > This was a little long to respond with on Twitter, so I thought I'd share my thoughts here. I love the idea of a 12 month cadence. I like October because admins aren't upgrading production within the first few months of a new release. It gives it plenty of time to be stable for the OS distros as well as giving admins something low-key to work on over the holidays with testing the new releases in stage/QA. October sounds ideal, but in reality, we haven't been able to release right on time as long as I can remember. Realistically, if we set October, we are probably going to get into November/December. For example, Nautilus was set to release in February and we got it out late in late March (Almost April) Would love to see more of a discussion around solving the problem of releasing when we say we are going to - so that we can then choose what the cadence is. > > On Mon, Jun 17, 2019 at 12:22 PM Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org> wrote: >> >> On Wed, 5 Jun 2019, Sage Weil wrote: >> > 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! >> >> I've put up a twitter poll: >> >> https://twitter.com/liewegas/status/1140655233430970369 >> >> Thanks! >> sage >> _______________________________________________ >> ceph-users mailing list >> ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > _______________________________________________ > ceph-users mailing list > ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAC-Np1zcniBxm84SEGhzYfu55t+fckg1d-Dq0xpab62+ON4K5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Changing the release cadence [not found] ` <CAC-Np1zcniBxm84SEGhzYfu55t+fckg1d-Dq0xpab62+ON4K5w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2019-06-26 12:55 ` Sage Weil 0 siblings, 0 replies; 17+ messages in thread From: Sage Weil @ 2019-06-26 12:55 UTC (permalink / raw) To: Alfredo Deza; +Cc: Ceph Devel, Ceph-User, dev-a8pt6IJUokc On Tue, 25 Jun 2019, Alfredo Deza wrote: > On Mon, Jun 17, 2019 at 4:09 PM David Turner <drakonstein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > This was a little long to respond with on Twitter, so I thought I'd share my thoughts here. I love the idea of a 12 month cadence. I like October because admins aren't upgrading production within the first few months of a new release. It gives it plenty of time to be stable for the OS distros as well as giving admins something low-key to work on over the holidays with testing the new releases in stage/QA. > > October sounds ideal, but in reality, we haven't been able to release > right on time as long as I can remember. Realistically, if we set > October, we are probably going to get into November/December. > > For example, Nautilus was set to release in February and we got it out > late in late March (Almost April) > > Would love to see more of a discussion around solving the problem of > releasing when we say we are going to - so that we can then choose > what the cadence is. I think the "on time" part is solveable. We should just use the amount of time between take the previous release's freeze date and the target release date and go with that. It is a bit fuzzy because I left it up to the leads how they handle the freeze, but I think mid-Januaray is about right (in reality we waiting longer than that for lots of RADOS stuff). v14.2.0 was Mar 18, so ~2 months. The cadence is really separate from that, though: even if every release were 2 full months late, if we start with the same target it's still a 1 year cycle. sage ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAE6AcseMEfRjRtA0iUPMwsQPP+ebEqDDHYeWUpXWGeWTggnKRw@mail.gmail.com>]
[parent not found: <CAE6AcseMEfRjRtA0iUPMwsQPP+ebEqDDHYeWUpXWGeWTggnKRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: Changing the release cadence [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> 0 siblings, 1 reply; 17+ messages in thread From: Sage Weil @ 2019-06-26 12:57 UTC (permalink / raw) To: Alfonso Martinez Hidalgo; +Cc: Ceph Devel, Ceph-User, dev-a8pt6IJUokc [-- Attachment #1: Type: TEXT/PLAIN, Size: 2933 bytes --] On Wed, 26 Jun 2019, Alfonso Martinez Hidalgo wrote: > I think March is a good idea. Spring had a slight edge over fall in the twitter poll (for whatever that's worth). I see the appeal for fall when it comes to down time for retailers, but as a practical matter for Octopus specifically, a target of say October means freezing in August, which means we only have 2 more months of development time. I'm worried that will turn Octopus in another weak (aka lightly adopted) release. March would mean freezing in January again, which would give us July to Dec... 6 more months. sage > > On Tue, Jun 25, 2019 at 4:32 PM Alfredo Deza <adeza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > > > On Mon, Jun 17, 2019 at 4:09 PM David Turner <drakonstein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > wrote: > > > > > > This was a little long to respond with on Twitter, so I thought I'd > > share my thoughts here. I love the idea of a 12 month cadence. I like > > October because admins aren't upgrading production within the first few > > months of a new release. It gives it plenty of time to be stable for the OS > > distros as well as giving admins something low-key to work on over the > > holidays with testing the new releases in stage/QA. > > > > October sounds ideal, but in reality, we haven't been able to release > > right on time as long as I can remember. Realistically, if we set > > October, we are probably going to get into November/December. > > > > For example, Nautilus was set to release in February and we got it out > > late in late March (Almost April) > > > > Would love to see more of a discussion around solving the problem of > > releasing when we say we are going to - so that we can then choose > > what the cadence is. > > > > > > > > On Mon, Jun 17, 2019 at 12:22 PM Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org> wrote: > > >> > > >> On Wed, 5 Jun 2019, Sage Weil wrote: > > >> > 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! > > >> > > >> I've put up a twitter poll: > > >> > > >> https://twitter.com/liewegas/status/1140655233430970369 > > >> > > >> Thanks! > > >> sage > > >> _______________________________________________ > > >> ceph-users mailing list > > >> ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org > > >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > > _______________________________________________ > > > ceph-users mailing list > > > ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org > > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > -- > > Alfonso Martínez > > Senior Software Engineer, Ceph Storage > > Red Hat <https://www.redhat.com> > <https://red.ht/sig> > [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <alpine.DEB.2.11.1906261255530.17148-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>]
* Re: Changing the release cadence [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> 0 siblings, 1 reply; 17+ messages in thread From: Sage Weil @ 2019-06-26 14:45 UTC (permalink / raw) To: Ceph Devel, Ceph-User, dev-a8pt6IJUokc [-- Attachment #1: Type: TEXT/PLAIN, Size: 4122 bytes --] Hi everyone, We talked a bit about this during the CLT meeting this morning. How about the following proposal: - Target release date of Mar 1 each year. - Target freeze in Dec. That will allow us to use the holidays to do a lot of testing when the lab infrastructure tends to be somewhat idle. If we get an early build out at the point of the freeze (or even earlier), perhaps this capture some of the time that the retailers have during their lockdown to identify structural issues with release. It is probably better to do more of this testing at this point in the cycle so that we have time to properly fix any big issues (like performance or scaling regressions). It is of course a challenge to motivate testing on something that is too far from the final a release, but we can try. This avoids an abbreviated octopus cycle, and avoids placing August (which also often has people out for vacations) right in the middle of the lead-up to the freeze. Thoughts? sage On Wed, 26 Jun 2019, Sage Weil wrote: > On Wed, 26 Jun 2019, Alfonso Martinez Hidalgo wrote: > > I think March is a good idea. > > Spring had a slight edge over fall in the twitter poll (for whatever > that's worth). I see the appeal for fall when it comes to down time for > retailers, but as a practical matter for Octopus specifically, a target of > say October means freezing in August, which means we only have 2 > more months of development time. I'm worried that will turn Octopus > in another weak (aka lightly adopted) release. > > March would mean freezing in January again, which would give us July to > Dec... 6 more months. > > sage > > > > > > > On Tue, Jun 25, 2019 at 4:32 PM Alfredo Deza <adeza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > > > > > On Mon, Jun 17, 2019 at 4:09 PM David Turner <drakonstein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > wrote: > > > > > > > > This was a little long to respond with on Twitter, so I thought I'd > > > share my thoughts here. I love the idea of a 12 month cadence. I like > > > October because admins aren't upgrading production within the first few > > > months of a new release. It gives it plenty of time to be stable for the OS > > > distros as well as giving admins something low-key to work on over the > > > holidays with testing the new releases in stage/QA. > > > > > > October sounds ideal, but in reality, we haven't been able to release > > > right on time as long as I can remember. Realistically, if we set > > > October, we are probably going to get into November/December. > > > > > > For example, Nautilus was set to release in February and we got it out > > > late in late March (Almost April) > > > > > > Would love to see more of a discussion around solving the problem of > > > releasing when we say we are going to - so that we can then choose > > > what the cadence is. > > > > > > > > > > > On Mon, Jun 17, 2019 at 12:22 PM Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org> wrote: > > > >> > > > >> On Wed, 5 Jun 2019, Sage Weil wrote: > > > >> > 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! > > > >> > > > >> I've put up a twitter poll: > > > >> > > > >> https://twitter.com/liewegas/status/1140655233430970369 > > > >> > > > >> Thanks! > > > >> sage > > > >> _______________________________________________ > > > >> ceph-users mailing list > > > >> ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org > > > >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > > > > _______________________________________________ > > > > ceph-users mailing list > > > > ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org > > > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > > > > > -- > > > > Alfonso Martínez > > > > Senior Software Engineer, Ceph Storage > > > > Red Hat <https://www.redhat.com> > > <https://red.ht/sig> > > [-- 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <alpine.DEB.2.11.1906261437280.17148-qHenpvqtifaMSRpgCs4c+g@public.gmane.org>]
* Re: Changing the release cadence [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 1 sibling, 0 replies; 17+ messages in thread From: Bob Farrell @ 2019-06-26 14:56 UTC (permalink / raw) Cc: Ceph Devel, Ceph-User, dev-a8pt6IJUokc [-- Attachment #1.1: Type: text/plain, Size: 4989 bytes --] March seems sensible to me for the reasons you stated. If a release gets delayed, I'd prefer it to be on the spring side of Christmas (again for the reasons already mentioned). That aside, I'm now very impatient to install Octopus on my 8-node cluster. : ) On Wed, 26 Jun 2019 at 15:46, Sage Weil <sweil-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > Hi everyone, > > We talked a bit about this during the CLT meeting this morning. How about > the following proposal: > > - Target release date of Mar 1 each year. > - Target freeze in Dec. That will allow us to use the holidays to do a > lot of testing when the lab infrastructure tends to be somewhat idle. > > If we get an early build out at the point of the freeze (or even earlier), > perhaps this capture some of the time that the retailers have during their > lockdown to identify structural issues with release. It is probably > better to do more of this testing at this point in the cycle so that we > have time to properly fix any big issues (like performance or scaling > regressions). It is of course a challenge to motivate testing on > something that is too far from the final a release, but we can try. > > This avoids an abbreviated octopus cycle, and avoids placing August (which > also often has people out for vacations) right in the middle of the > lead-up to the freeze. > > Thoughts? > sage > > > > On Wed, 26 Jun 2019, Sage Weil wrote: > > > On Wed, 26 Jun 2019, Alfonso Martinez Hidalgo wrote: > > > I think March is a good idea. > > > > Spring had a slight edge over fall in the twitter poll (for whatever > > that's worth). I see the appeal for fall when it comes to down time > for > > retailers, but as a practical matter for Octopus specifically, a target > of > > say October means freezing in August, which means we only have 2 > > more months of development time. I'm worried that will turn Octopus > > in another weak (aka lightly adopted) release. > > > > March would mean freezing in January again, which would give us July to > > Dec... 6 more months. > > > > sage > > > > > > > > > > > > On Tue, Jun 25, 2019 at 4:32 PM Alfredo Deza <adeza-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: > > > > > > > On Mon, Jun 17, 2019 at 4:09 PM David Turner <drakonstein-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > > > wrote: > > > > > > > > > > This was a little long to respond with on Twitter, so I thought I'd > > > > share my thoughts here. I love the idea of a 12 month cadence. I like > > > > October because admins aren't upgrading production within the first > few > > > > months of a new release. It gives it plenty of time to be stable for > the OS > > > > distros as well as giving admins something low-key to work on over > the > > > > holidays with testing the new releases in stage/QA. > > > > > > > > October sounds ideal, but in reality, we haven't been able to release > > > > right on time as long as I can remember. Realistically, if we set > > > > October, we are probably going to get into November/December. > > > > > > > > For example, Nautilus was set to release in February and we got it > out > > > > late in late March (Almost April) > > > > > > > > Would love to see more of a discussion around solving the problem of > > > > releasing when we say we are going to - so that we can then choose > > > > what the cadence is. > > > > > > > > > > > > > > On Mon, Jun 17, 2019 at 12:22 PM Sage Weil <sage-BnTBU8nroG7k1uMJSBkQmQ@public.gmane.org> > wrote: > > > > >> > > > > >> On Wed, 5 Jun 2019, Sage Weil wrote: > > > > >> > 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! > > > > >> > > > > >> I've put up a twitter poll: > > > > >> > > > > >> https://twitter.com/liewegas/status/1140655233430970369 > > > > >> > > > > >> Thanks! > > > > >> sage > > > > >> _______________________________________________ > > > > >> ceph-users mailing list > > > > >> ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org > > > > >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > > > > > > _______________________________________________ > > > > > ceph-users mailing list > > > > > ceph-users-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org > > > > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > > > > > > > > > > > > -- > > > > > > Alfonso Martínez > > > > > > Senior Software Engineer, Ceph Storage > > > > > > Red Hat <https://www.redhat.com> > > > <https://red.ht/sig> > > > _______________________________________________ > 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: 7338 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Changing the release cadence [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 1 sibling, 0 replies; 17+ messages in thread From: Lars Marowsky-Bree @ 2019-06-26 15:21 UTC (permalink / raw) To: Ceph Devel, Ceph-User, dev-a8pt6IJUokc On 2019-06-26T14:45:31, Sage Weil <sweil-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote: Hi Sage, I think that makes sense. I'd have preferred the Oct/Nov target, but that'd have made Octopus quite short. Unsure whether freezing in December with a release in March is too long though. But given how much people scramble, setting that as a goal probably will help with stabilization. I'm also hoping that one day, we can move towards a more agile continuously integration model (like the Linux kernel does) instead of massive yearly forklifts. But hey, that's just me ;-) Regards, Lars -- SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) "Architects should open possibilities and not determine everything." (Ueli Zbinden) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Changing the release cadence [not found] ` <alpine.DEB.2.11.1906051556500.987-qHenpvqtifaMSRpgCs4c+g@public.gmane.org> ` (3 preceding siblings ...) 2019-06-17 16:21 ` Sage Weil @ 2019-07-22 3:03 ` Brent Kennedy 4 siblings, 0 replies; 17+ messages in thread From: Brent Kennedy @ 2019-07-22 3:03 UTC (permalink / raw) To: 'Sage Weil', ceph-users-Qp0mS5GaXlQ, ceph-devel-u79uwXL29TY76Z2rM5mHXA, dev-a8pt6IJUokc 12 months sounds good to me, I like the idea of march as well since we plan on doing upgrades in June/July each year. Gives it time to be discussed and marinate before we decide to upgrade. -Brent -----Original Message----- From: ceph-users <ceph-users-bounces-idqoXFIVOFJgJs9I8MT0rw@public.gmane.org> On Behalf Of Sage Weil Sent: Wednesday, June 5, 2019 11:58 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2019-07-22 3:03 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 [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
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.