> * Drop the odd releases, and aim for a ~9 month cadence. This splits the > difference between the current even/odd pattern we've been doing. > > + eliminate the confusing odd releases with dubious value > + waiting for the next release isn't quite as bad > - required upgrades every 9 months instead of ever 12 months As a user is probably closest to the ideal, although a production deployment might slip out of the LTS view in 18 months given once deployed they tend to stay static. >From a testing perspective it would be good to know you could deploy the "early access" version of a release and test with that rather than having to switch release to productionise when that release is blessed. Also, and this might be harder to achieve, but could krbd support for new releases be more aligned with kernel versions? Or at the least a definitive map of what kernels and backports support which release. Confidentiality: This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They may only be copied, distributed or disclosed with the consent of the copyright owner. If you have received this email by mistake or by breach of the confidentiality clause, please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake. _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |