Hi Daniel,

On 2/9/24 5:24 μ.μ., Daniel Gröber wrote:
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.

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.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. 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 would very much appreciate anyone willing to co-maintain the package
with me. Especially someone with any serious Rust experience would be
very helpful.

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

Reply via email to