Thomas Goirand <zigo@xxxxxxxxxx>于2022年7月28日 周四05:20写道：
Hi,
FYI, I was able to build Ceph 16.2.10 after adding the #include <memory>
in buffer.h as you backported.
On 7/27/22 12:42, kefu chai wrote:
> Will this be backported to Pacific, or will this be worked-on only
> in master?
>
>
> as in general, only the changes with backport tracker tickets are
> tracked and backported systematically.
>
> Those without tracker tickets can also backported if changes are
> justified. I guess the change to fix the FTBFS of an LTS branch on an
> unstable distro might be controversial.
Unstable is just a name. You may also say "testing", or "Debian next
stable" because that's the same thing we're talking about at the end.
Thanks for your explanation! Actually, I use sid myself. With the context you provided in you reply, I understand the situation we are facing much better. Sorry I missed the point that Debian is rolling its builds. Without the packages prepared in unstable, we’d never have them in stable.
> As some of us might argue, why not package Quincy?
Because Debian Stable (ie: Bullseye, aka Debian 11) has 14.2.x, and we
want to have an upgrade path, we can only package 16.2.x in the next
stable (ie: Bookworm, aka Debian 12).
I very much would like the situation to change. This can only happen if:
- Ceph upstream makes its release cycle longer, so Debian can catch-up
(we freeze every 2 years, so even if we don't have a set-in-advance
release date, we're always on a 2 years cadence...).
- Ceph upstream makes it possible to skip one more version (ie: skip 2,
not only 1).
It's already *very* nice that Ceph is on a 1 year release cycle and
allow skipping one release each time, as this is aligned with Debian,
but I have no solution right now to go directly to Quincy... :/
IIRC, you raised this concern before. But unfortunately, we didn’t come up with a sound solution. In other words, the combination of these two release schedules forces Debian users to upgrade their cluster to a new stable release of Ceph and Debian every major release of Debian. It might be like a life-long marathon to those who don’t have the {willing,money,power,interests} to maintain their own Ceph branch..
Your thoughts on this would be very welcome.
This was a major decision () we made for the release schema couple years ago. If we want to put it on the table again, it would probably be a topic for CLTs and governing board discussions.
> But personally, if some of us volunteer to do this. And the fix is
> low-risk. I don’t see why we should not accept the changes to fix FTBFS
> on older but active LTS branches.
Cheers,
Thomas Goirand (zigo)
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
Regards
Kefu Chai
Kefu Chai
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
