Re: PSA: Avoid Debian

["Carl E. Thompson" <cet@carlthompson.net>]

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.

Carl


> On 2024-08-07 10:29 AM PDT Kent Overstreet <kent.overstreet@linux.dev> 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.