On Mon, Sep 02, 2024 at 08:58:38PM +0200, Daniel Gröber wrote: > 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? > > [...] > > 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.
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.1723057453...@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. > > 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. 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.1723057453...@mail.carlthompson.net/T/#t 3: https://www.reddit.com/r/bcachefs/comments/1f4erbg/comment/lkped4c/ Hope this helps, Faidon
