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
