Whether or not the concept of Debian is a good idea probably isn't a constructive discussion for this list.
The problem here is that what was essentially an _alpha_ piece of software for what at the time was essentially an _alpha_ filesystem was allowed into the _stable_ release of Debian at all. Whoever on the Debian side allowed its inclusion dropped the ball. > On 2024-08-07 10:29 AM PDT Kent Overstreet <[email protected]> wrote: > > > On Wed, Aug 07, 2024 at 12:09:53PM GMT, Eli Schwartz wrote: > > On 8/7/24 12:01 PM, Kent Overstreet wrote: > > > This is holding up _bugfix releases_. > > > > > > Anyone would run screaming from a distro that didn't ship updates at > > > all. > > > > > > (What if I said that lots of people *do* run screaming from Debian?) > > Heh. > > Personally, in _general_, I feel quite affectionate towards debian; I've > been running it for 20 years, and there's a lot to like about it and a > lot of good stuff they've done. > > But lately a _lot_ of the bug reports I'm seeing have "I was running an > old broken Debian package" as a root cause or additional complicating > factor. > > And considering that this is due to something we discussed months? a > year? ago, and they're still insisting on broken policies, I am growing > _increasingly_ pissed off about it. > > (Personally, this is pushing me to migrate my infrastructure to NixOS > sooner rather than later...) > > > You have to manually negotiate for those, to avoid the risk of > > accidentally shipping an updated bugfix release that breaks their > > spacebar heating: https://xkcd.com/1172/ > > Which isn't remotely feasible; I have a lot of distros packaging > bcachefs, and I don't have time to devote to interactions like this with > all of them. This is Debian wanting to think they're special, assuming > that they can dominate with their policies - but that's not a winning > long term strategy, that's just going to result in them being left > behind. > > The only honest way of influencing other people, and the only way that > works long term, is with the quality of your ideas. "But this is our > policy and you just have to abide" - nope. Even if people don't react > right away, they see that and take note and start maing other plans. > > > When software cannot be updated by default because it might break > > someone's workflow, the natural result of sometimes needing an update is > > that people who want updates are pitted adversarially against people who > > do not want updates -- you need to plead your case and get permission > > and, well, fight for your right to receive a bugfix. > > I've put a _lot_ of work into making sure bcachefs updates are as > painless as they can be, with e.g. seamless upgrade and downgrade paths, > and ways of dealing with version mismatch between tools/kernel/ondisk > filesystem. > > Because we _have to be able to ship our work_, and in a timely manner. > Our systems get steadily more complicated year by year, decade by > decade, as we build up more processes and tooling around the whole > business of writing and shipping code. Making progress in our work > requires shipping code and iterating, so if we can't and we let the > political process bullshit it's death by a thousand cuts and work slowly > grinds to a halt. > > > Has anyone volunteered to be the political advocate for bcachefs-tools > > bugfix releases in Debian? > > No, and nor would I recommend anyone else for that kind of bullshit, > make-work job. > > The real issue here is just that Debian needs to figure out how to have > some flexibility, recognize when policies aren't working, and develop a > better and more practical minded attitude. > > So they can stop wasting my time with this stupid bullshit and I can get > back to real work.
