I'm planning to re-introduce bcachefs-tools in Debian after it was recently RMed by Jonathan: O: #1078599, RM: #1079375. Based on publically available [information], my previous and recent interactions with upstream this happend more due to personal differences with upstream than for technical reasons and I hope to be able to rebuild that damaged bridge. [information]: https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/ Jonathan, I would appreciate it if you could enlighten me on your side of the story, privately if you prefer, so I can get a more complete picture of what happened here. * Package name : bcachefs-tools Version : 1.9.4 Upstream Author : Kent Overstreet <kent.overstreet@linux.dev> * URL : https://evilpiepirate.org/git/bcachefs-tools.git * License : GPL-2+ Programming Lang: C Description : bcachefs userspace tools I would very much appreciate anyone willing to co-maintain the package with me. Especially someone with any serious Rust experience would be very helpful. Thanks, --Daniel
Hi Daniel, I'm not Jonathan, but I can perhaps help you into forming a more complete picture: The existing bcachefs packaging left a few things to be desired. This is not a criticism to Jonathan per se (he had his reasons), but it wasn't adequately maintained in my opinion. I've corresponded with Jonathan on that matter a number of times, in the BTS and offline. See, for example bugs #1054620, #1060256, #1066929, and #1074797, and my emails there in particular. I did some of the underlying work to build the Rust parts, both in Debian and upstream (Debian #1060256, upstream #202, #205 etc.). Steinar H. Gunderson also contributed quite a bit in this regard as well. The version of bcachefs-tools in experimental is mostly OK, but includes an upstream workaround that has since been reverted; it also continues to FTBFS on i386. I've proposed #1078698 to fix this properly. I've tried locallyt his and is (IMHO) relatively simple as it's a single upstream bindgen patch that applies cleanly + a biNMU for rust-bindgen-cli. (Even better of course would be a newer rust-bindgen, like Kent is asking for.) Once that is done, I am estimating that will be a low-effort package to maintain, on a technical level (unless a major refactor or something happens). On a social level... it won't be as easy. Upstream is... broadly upset with Debian (and Fedora), even going as far as sending a PSA on the bcachefs mailing list to "avoid Debian": https://lore.kernel.org/linux-bcachefs/917737081.127.1723057453386@mail.carlthompson.net/T/#t It looks like his issues are with the Debian maintainer having to stick with certain policies (primarily: not vendoring), rather than an issue with the bcachefs-tools packaging specifically, or Jonathan. For example, see: https://news.ycombinator.com/item?id=41408628 In my opinion, he also has a history of being uncompromising, unprofessional, and unempathetic towards the work of others including contributors and collaborators. For example: - Expressing his grievances against Jonathan publicly in a recent Reddit thread, in conduct that I personally believe is entirely unprofessional, then subsequently locking the thread for lack of professionalism (!?): https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/lkped4c/ - Expecting Debian to change its entire Rust policy, and/or the bcachefs maintainer to deviate from long-standing policies. In particular expressing that "with Debian and Fedora people alike it's been like talking to a brick wall", without being able to have the necessary empathy to understand that this is the case the other way around as well. - Misrepresenting on lkml that he expects major distros to pick up bcachefs soon, merely weeks after telling his users to not use Debian and in the very same week claiming on Reddit that he'd rather not it see packaged in both Debian and Fedora than packaged 'badly' (= following their policies): https://lore.kernel.org/lkml/nxyp62x2ruommzyebdwincu26kmi7opqq53hbdv53hgqa7zsvp@dcveluxhuxsd/ (Ironically this was in a thread that AIUI was a spat with Linus for not conforming to certain Linux standards/policies.) Whoever ends up maintaining this package, will have the uphill battle of working with what in Debian would call a "hostile upstream". I was originally enthusiastic about bcachefs and contributed a bunch into its packaging, as you might be able to tell from the bugs linked above. I persuaded Jonathan into not filing for a removal but orphan it instead. I've been increasingly convinced, and especially in the past couple of weeks, that I won't want to be anywhere near it, though. I would go as far as to say that it should not be packaged by anyone, unless upstream commits to a) accepting that there are certain policies that are broader than bcachefs, and while not immutable, it's not within each individual maintainer's scope to "just" deviate from because bcachefs is "special"; b) certain standards of conduct against the Debian maintainer will have to be followed, no matter the disagreement. I wish you luck nevertheless. Regards, Faidon
Hi Faidon, Thanks so much for your perspective on the matter. That doesn't sounds so bad to me on a technical level. Personally I don't care much about i386 so I would simply prevent it from building in unstable until someone sends patches along with a maintainance committment. bcachefs is his baby and we're huring it. How would you react? I'm just glad no personal attacks were thrown around in that post as I felt Kent was intending to do when talking on IRC. I'm not going to quote the relevant log myself but motivated readers may be able find them with this context: In my mind bcachefs is still under development so stable just isn't the right place for it yet and thats where all this friction is stemming from. We were perhaps just a bit over-enthusiastic in trying to have it there already? Thanks for the links I hadn't seen those yet. Your assessment essentially mirrors mine from the IRC interaction I mentioned above except for the the "unprofessional" bit. I know too many people that act exactly like this in their profession so I find this misleading and potentially hurtful for Kent. Let's try to not make things even worse please. Please also consider that for outsiders us Debianites can seem equally "uncompromising" due to all our policies so I consider this aspect of his behaviour an appropriate proportional response to our ways. Sure it's rooted in a organizational knowledge instead of personal decisions but that feels the same for the recipient when we externalize this. Again. I think we have to acknowledge this feeling is real and valid when interacting with ancient beasts like Debian or Fedora. The "he does this too" argument isn't as strong as you seem to think IMO. I used to think so too, but then I came across https://en.wikipedia.org/wiki/Tit_for_tat and it fundamentally changed my perspective. From my observations on IRC there has indeed been an uptick in project participants since the bcachefs *kernel* parts have been available through distros. I mean go figure. Using/trusting his kernel fork is much more tricky than just compiling a userspace tool. Your perceived "bad" observations here may just be miscomunication. Maybe I have "I can change him" syndrome, but I think we just need to approach this right and show Kent Debian can be less ridgid than he's experienced so far. I will respect your decision in any case, I would just like to ask you to give me a chance on trying to resolve this conflict and work with me on this. I don't agree with that unconditionall. Each maintainer in Debian is perfectly able, if they are willing, to ignore policy at their own political/organizational peril. In my experience so far these are usually little things, but I don't see why this must be so. This is the kind of ridgidity Kent is obviously upset about IMO. I've mentioned this on IRC in #debian-devel, but have you considered bcachefs-tools may not be suitable for stable however debian-fasttrack exists and is so far as I know explicitly designed for software with fast moving support timeframes such as Gitlab but perhaps also bcachefs-tools. Changing people is hard. I agree we should communicate our disappointment with his conduct, but making personal change a conditional here is unlikeley to help that change materialize. Show, don't tell. Thanks, --Daniel
No, I don't think this is where all the friction lies. That was a (small) part of it. Upstream's primary issue AIUI is: "Debian (as well as Fedora) currently have a broken policy of switching Rust dependencies to system packages. [...] We're primarily talking about the package in Debian _unstable_, although the ancient -tools package in stable is also causing problems"[1]. I believe the outdated versions of software that *unstable* carries, and the fact that dependencies need to be relaxed by patching Cargo.toml, etc. is also a major sticking point. It is my belief that this is going to be the major source of friction that you will have to deal with, either by setting some expectations at the beginning of your collaboration as a I suggested, or in perpetuity throughout the lifetime of this package (e.g. every time a package in the build-dep chain lags behind). For what it's worth, I certainly don't think ignoring existing Rust packaging practice, but rather fetching all all dependencies and sub-dependencies manually from crates.io and vendoring them to the source package is the way to go, especially for the sole reason of "bcachefs upstream thinks bcachefs-tools should be packaged in this way". There /is/ a concrete issue with the older version of rust-bindgen that we carry, however. This is the issue that I mentioned in my previous correspondence (#1078698). I do think this should be resolved with either a backport (i.e. my attempt at a compromise) or working with the Rust maintainers to upload a newer upstream. It's not just for the benefit of i386, but rather to fix an issue where the issue lies rather than patching bcachefs-tools to work around it. 1: https://lore.kernel.org/linux-bcachefs/917737081.127.1723057453386@mail.carlthompson.net/T/#t I would personally not accept being told to "stop wasting my time with this stupid bullshit"[2] and "[you] really screwed the pooch"[3] from e.g. a colleague, vendor or customer (i.e. what you would call a "professional setting") and would ask the individual to retract and promise to do better before continuing to work with them. I'm also pretty sure I'd be asked to leave from any professional establishment (like e.g. a bank or restaurant) if I spoke to its staff in this way, and conversely would certainly leave myself if I was spoken to in this way. I hope we can agree on that, but we can also agree to disagree. In any case, I don't think it'd be productive to litigate upstream's conduct any further. My goal here was for you to have all the facts, and I hope you at least have a clearer picture compared to when this conversation began! 2: https://lore.kernel.org/linux-bcachefs/917737081.127.1723057453386@mail.carlthompson.net/T/#t 3: https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/lkped4c/ Hope this helps, Faidon
Based on my own personal experience with trying to package another big Rust application a few years ago (Routinator) Jonathan is completely right and the common Rust practices of dealing with dependencies are rotten and hostile to distributions, but I wish you the best luck. :-) LOL (sorry).
You don’t need to re-introduce it, Jonathan took care to ensure that the package wouldn’t be fully removed, as explained in the blog post. If you want to go ahead with this, you should close the ITP (which isn’t needed), update #1078599 to indicate you intend to adopt the package, and when you upload a new package, close #1078599 in the changelog. See https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package and https://www.debian.org/devel/wnpp/#howto-o for details. Regards, Stephen
I think I need to explain my priorities. My #1 priority is ensuring that users have a reliable filesystem. There are real consequences for mistakes in this work. We've seen that with btrfs, where there are still users showing up regularly on IRC and the mailing list with bricked filesystems trying to get help. That shouldn't happen, and ensuring that it doesn't is my number one goal. Think about the users, and think about what happens if the filesystem fails. That's people's work, that's people's lives at risk. While I'm sure you're all wonderful people, and I'd never want to be a dick to any of you for no reason (I've been running Debian for decades) - your feelings are not my biggest priority. Getting this right so users can have something reliable is. Once we've got all the difficult issues sorted out, once we know our priorities are in the right place, _then_ we can get a beer and be nice to each other. Responsibilities come first. So: If bcachefs-tools is going to be packaged for Debian, I just want it done right. Let me make it clear that I didn't ask for bcachefs-tools to be packaged for Debian; Jonathan took that on himself and dropped a hot mess in my lap. Let's please not do that again; users weren't able to access their filesystems because of what happened. I laid out my asks on the bcachefs mailing list here: https://lore.kernel.org/linux-bcachefs/36xhap5tafvm4boiy3acu5kxlhkvnp32wp3oknbfbkxbdkeq7r@galecvidi3bn/T/#m854ffaa195fe62d67e0a120943d52dcb97b9bdbf If Debian isn't able to be flexible on its unbundling policies, and if we expect there'll be future friction - that's ok! don't package it! There's other distros out there, bcachefs doesn't have to be in all of them, at least not any time soon.
Hey everyone involved. Not seeing too much activity here. Can I take this over and reassign to me? I'm in touch with Kent and other people that would love to see bcachefs introduced in Debian even in experimental as a starting point. Bartek
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 :)
Please note that there is an experimental bcachefs-tools version in Debian still. So this ITP is not needed.
Hi Bartosz, Kent, Fine by me :-). Glad to hear you found someone to help you work with Debian. Best of luck, --Daniel <3