Re: Rust policy for bcachefs-tools in Debian
On Fri, Sep 19, 2025 at 05:34:36PM +0200, Fabian Grünbichler wrote:
> On Fri, Sep 19, 2025, at 5:17 PM, Kent Overstreet wrote:
> > On Fri, Sep 19, 2025 at 04:40:44PM +0200, Fabian Grünbichler wrote:
> >> On Sun, Sep 14, 2025, at 8:08 PM, Kent Overstreet wrote:
> >> > On Sun, Sep 14, 2025 at 07:33:56PM +0200, Matthias Geiger wrote:
> >> >> - Security issues: If they occur the can be easily migitated by a rebuild
> >> >> archive-wide for the packaged crates (not when vendored)
> >> >
> >> > For security issues, I think this is a solved problem; there are bots
> >> > that watch repositories and notify if there are out of date dependecies
> >> > (and I've got these notificiations once or twice in the past).
> >>
> >> Yeah, that's not how security updates are done in Debian (except sometimes
> >> in unstable ;)). For stable, you absolutely need a minimal fix targeting
> >> just the issue at hand, unless you have a proven track record and agreement
> >> with the security team which allows you to import collected security fix
> >> *releases* done upstream, or something like that. Wholesale updating of
> >> dependencies is only done as a last resort (see below).
> >
> > You guys may have to constrain yourself to the realm of the possible :)
> >
> > I've been scanning through past threads and noticing a lot of
> > commonality and similar stories in the problems that came up when
> > packaging web browsers, which is not too surprising; filesystems and web
> > browsers are both massive projects. Filesystems may not be able to
> > compete on raw amount of code (~150k loc for bcachefs), but the
> > reliability and correctness requirements are as high as it gets in
> > filesystem land (with commensuratily high QA requirements), which makes
> > us particularly sensitive to a lot of these issues; and we have to be
> > picky about where we spend our limited engineering cycles.
>
> Sure. You might have noticed that both major browsers are included in the
> list of existing exceptions. Both have stable branches with upstream
> security support which the packages for Debian stable are based upon.
> The existence of those branches is pretty much a requirement for those
> browser being in stable in the first place.
Yeah, that's the plan for bcachefs; it's just the "2 years of backports"
that I would be extremely hesitant to commit to.
We're currently publishing two channels - nightly and release - and the
plan is to add a third channel, stable, probably soon after dropping the
experimental label.
How much stable will lag behind release is still to be determined, it'll
be based on the data we see re: bugs that make it past QA, severity and
how long it takes us to catch them, as well as user feedback.
> Yes. See above for kernel/systemd as examples of projects in a similar boat
> (maybe less so w.r.t. hotfixes, but rather fixes for bugs affecting that
> stable release train - but do note that upstream and distros, in particular
> distros like Debian, often disagree about the urgency of fixing such issues,
> something you upstream might consider a hotfix you want to release tomorrow
> might very well be something that Debian considers to be okay to fix in the
> next point release, which might be up to 2 months away).
I am quite familiar with QA release process... :)
I have been closely observing how well it has (and hasn't) been working
for filesystems over the course of bcachefs development (and listened to
many bitchfests from other filesystem developers intimately involved
with said process); there's quite a lot in my approach to bcachefs
QA/release management that's directly based on lessons learned from
that.
The big lesson learned has been investing heavily into QA from the start
- both automated testing, and building up a community of users that run
my nightlies and getting everyone used to working together and well
practiced at validating new features.
As far as I know, there is _still_ no QA besides manual patch review on
Greg's stable branches, and that's bit filesystems multiple times.
That's been the big motivation for being hands on with as much of the
release process for bcachefs as possible - that way I can make sure
everything is running through the same QA pipeline.
(And in the long run it makes my life way easier by having fewer bug
reports to respond to :)
> > Is this a want or a need, though?
>
> Both, I'd say. It's a want (because it has desirable properties, in
> particular when using dynamic linking, archive-wide changes, ..) and a need
> (because a lot of the infrastructure and work flows are not setup to handle
> code copies well).
If there's any infrastructure or workflows that this causes problems
for, that's something we may be able to solve - and making Debian
packaging work is an area people in the project have already been very
active and helpful , so I think we'd have the manpower available.
Reply to: