Hi Faidon, Thanks so much for your perspective on the matter.
On Mon, Sep 02, 2024 at 08:38:46PM +0300, Faidon Liambotis wrote: > > 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. > > [...] > > 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). 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. > 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 I mean that's fair if our stuff is broken, no? Consider it this way: 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 #bcachefs on 2024-03-02: > 16:37:00 <dxld> not hiding problems is one of debian's core values BTW, but > hurting people's feelings doesn't tend to motivate them to invest time and > effort. > 16:37:43 <dxld> so go right ahead and complain loudly, just in such a way as > to not hurt anyone working on this 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? > 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. 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. > For example: > > [...] > > - 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. 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. > - 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.) 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. > Whoever ends up maintaining this package, will have the uphill battle of > working with what in Debian would call a "hostile upstream". 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 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 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 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" 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. > b) certain standards of conduct against the Debian maintainer will have > to be followed, no matter the disagreement. 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
signature.asc
Description: PGP signature
