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.
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... :/
Your thoughts on this would be very welcome.
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
