Bug#1080344: Chiming in
Hey all,
We've been putting together a team to finally give this the attention it
needs, and Bartek's been a great help in the area of Debian process, and
agreed to sponsor.
Immediate background:
- bcachefs is switching to shipping as DKMS. That puts us in a bit of a
bind, because there's a significant userbase out there we need to
support.
Previously, the lack of an updated bcachefs-tools package on Debian
hasn't been a major concern, because in generaly we have the
compatibility mechanisms to support widely differing kernel/userspace
versions and we don't depend on userspace fsck (kernel/userspace fsck
are equally supported) - meaning users could build bcachefs-tools from
source and update it infrequently without isuses.
But now with the DKMS switch coming we need to come up with a plan to
support the existing userbase, and hopefully a path to bcachefs on
Debian being a properly supported package like any other.
The Debian kernel team was initially planning on dropping bcachefs from
the kernel build in 6.17; I asked for and received an extension.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1634#login-pane
This doesn't put us in an immediate bind for 6.17, fortunately. We've
been grinding hard on bugs getting ready to take the experimental label
off, and 6.16 turned out very solid, based on user feedback. We
currently don't have any critical fixes we're rushing to get out, and I
don't anticipate anything coming up.
But we are trying to avoid leaving users with unbootable systems and
filesystems they can't access, and the kernel team isn't going to want
to leave a filesystem enabled in their kernel config that isn't
receiving updates, so our immediate hope is to get a package back into
experimental that we can properly support on our end.
Longer term, we are getting closer to lifting the experimental label. I
think it's fair to say that the previous bcachefs-tools effort in Debian
happened too soon (communications were quite strained), so it's our hope
to start a fresh conversation on all the process issues that caused
friction before - and take things slower this time. With stabilization
mostly done, we've also got more bandwidth this time around.
We don't want to rush anything beyond getting a package into Debian
experimental; the timeline on our end is that I expect to take the
experimental label off of bcachefs in the next 3 months or so (aiming
for by the end of the year, but that will depend on seeing all the
remaining outstanding bugs closed), and then we'll want to take some
more time to see what the backport situation looks like.
We've got a better integrated team this time around (Chris, the third
member, is likely going to be taking lead on much of this and has been a
long standing member of the bcachefs community; he's driving today so
I'm writing this up).
We've also got a very active community supporting this thing, with a
good track record of triaging and responding to bug reports; my intend
is to make sure that bug reports from Debian users can be supported just
as well as any other bcachefs user.
And, of course, our main goal is to get a filesystem out there with a
rock solid commitment to quality, robustness, and not losing your data
:)
-Kent
Reply to: