This isn't new

Posted Jul 16, 2012 20:14 UTC (Mon) by dwmw2 (subscriber, #2063)
In reply to: This isn't new by corbet
Parent article: Left by Rawhide

You may be right that what happens after a breakage is different — but that was always extremely variable from one developer to another anyway. So you'd need a reasonable sample size, over time, to really be sure of that.

I'm also not sure that such a change, if it's real, could necessarily be blamed on the no-frozen-rawhide thing. There have been other changes in Fedora packaging over time. There's much more of a focus on "packagers" these days, and much less on "package maintainers" who actually get their hands dirty and work on the code. This naturally translates into a much less happy experience for those who file bugs.

to post comments

This isn't new

Posted Jul 16, 2012 21:42 UTC (Mon) by johannbg (guest, #65743) [Link] (3 responses)

That's my assessment as well as in that quality of the components in the distribution has been thrown overboard for the quantity of components in the distribution...

This isn't new

Posted Jul 17, 2012 9:24 UTC (Tue) by drag (guest, #31333) [Link] (2 responses)

Which is yet another reason why distributions need to keep their scope limited, maintain standardized APIs across distributions, and have the upstream developers themselves package the software.

There is no way that you can expect a OS to bundle everything that everybody would possibly want run on it. Extensibility is important and users lack the knowledge, time, and drive to port and compile the software they want to use themselves.

This isn't new

Posted Jul 17, 2012 19:40 UTC (Tue) by epa (subscriber, #39769) [Link]

But equally, you can't expect an upstream developer to package the program for every possible distribution and architecture. Even expecting the upstream developer to support two is a losing proposition, since most people will have one distro that they use regularly.

Is there some way the distros and the upstreams can meet halfway? Source code could be distributed in a standard source package format, which as well as the usual configure script contains metadata about what files are built, what libraries are required and so on. This in turn can generate source packages for rpm, dpkg, Gentoo and so on using translator tools maintained by each distro. This would not be appropriate for core packages, which usually have a lot of distro-specific hacking, but for the long tail of applications and libraries it could bridge the gap between 'distro must package all possible programs' and 'upstream muat package for all possible distros'.

This isn't new

Posted Jul 20, 2012 10:57 UTC (Fri) by misc (subscriber, #73730) [Link]

You never tried to say "no" to a packager. Most of them all go with a frenzy phase of "let's add as much stuff we can to the distro, because users ask for it and threathen to go elsewhere". Then, that go to "we need more packager to take care of that", then "we need more QA and people doing the boring bits", except that boring stuff are not done, because that's boring.

A solution would be to take in account ressources as a whole, ie, you cannot upload a package unless there is enough people to take care for QA and updates.

But such view are far from being popular IMHO ( and most users do not care, like most do not care about sustainability ).

This isn't new

Posted Jul 17, 2012 17:14 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (8 responses)

This time (and all the previous times Rawhide spectacularly failed) the breakage came from Red Hat-written code pushed in Rawhide by the people who wrote it.

It's not pure packagers which are the problem. They are actually very careful about what they push precisely because they're not sure they'll be able to fix it if it breaks. The problem is people who write code and package it themselves, and feel they won't make any mistake ever, and anyway if it breaks they owe nothing to Rawhide guinea pigs which are only there to help them meet coding deadlines (gross generalization, dracut people are more aware than most of the risks though they do have to contend with systemd abrupt changes nowadays)

That's the typical problem you get in any project where you have devs that perform operational jobs, if you didn't make sure beforehand that they understand operations means they have real users and have to fix the problems they cause as soon as they cause them (unlike broken code that can languish in a VCS for days without consequences)

This isn't new

Posted Jul 18, 2012 5:08 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Case in point:

* Tue Jul 17 2012 020-96.git20120717 ← dracut working again
- disabled systemd in the initramfs, until it works correctly

* Wed Jul 11 2012 020-84.git20120711
- add back "--force" to switch-root, otherwise systemd umounts /run

* Wed Jul 11 2012 020-83.git20120711
- more systemd journal fixes
- nfs module fix
- install also /lib/modprobe.d/*
- fixed dracut-shutdown service
- safeguards for dracut-install
- for --include also copy symlinks

* Tue Jul 10 2012 020-72.git20120710
- stop journal rather than restart
- copy over dracut services to /run/systemd/system

* Tue Jul 10 2012 020-70.git20120710
- more systemd unit fixups
- restart systemd-journald in switch-root post
- fixed dracut-install loader ldd error message

* Mon Jul 09 2012 020-64.git20120709
- fixed plymouth install
- fixed resume
- fixed dhcp
- no dracut systemd services installed in the system

* Mon Jul 09 2012 020-57.git20120709
- more fixups for systemd-udevd unit renaming

* Mon Jul 09 2012 020-55.git20120709
- require systemd >= 186
- more fixups for systemd-udevd unit renaming

* Mon Jul 09 2012 020-52.git20120709
- fixed prefix in 01-dist.conf

* Fri Jul 06 2012 020-51.git20120706 ← start of huge breakage
- cope with systemd-udevd unit renaming
- fixed network renaming
- removed dash module

And:

* Tue Jul 03 2012 Lennart Poettering - 186-1
- New upstream release

This isn't new

Posted Jul 18, 2012 19:17 UTC (Wed) by nix (subscriber, #2304) [Link] (6 responses)

Ah, software developer optimism. You gotta love it.

(Of course *I* would never suffer from such a delusion. My code simply has no bugs. I know because I fixed all the bugs I found, and now I can find no more bugs so I know there must be no more bugs. Also, the Earth has a green sky and six retrograde moons.)

This isn't new

Posted Jul 20, 2012 3:27 UTC (Fri) by doogie (guest, #2445) [Link] (3 responses)

The only code that is bug free is that which is not yet written.

This isn't new

Posted Jul 20, 2012 8:47 UTC (Fri) by liw (subscriber, #6379) [Link] (2 responses)

Code not yet written doesn't run, which is a bug. ;-)

This isn't new

Posted Jul 20, 2012 9:24 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (1 responses)

Code not written has no users and thus by definition it is perfect.

That's the uncertainty principle applied to software: bugs not observed do not exist (yet)

This isn't new

Posted Jul 20, 2012 12:41 UTC (Fri) by nix (subscriber, #2304) [Link]

Not so. I currently suspect there is at least one bug in part of my code that has never run, but I am attacking it later, when other bugs are fixed so code flow can reach that bug and prove its existence. This bug is in an indeterminate state. :)

Schneier's law of software?

Posted Jul 22, 2012 4:40 UTC (Sun) by Max.Hyre (subscriber, #1054) [Link] (1 responses)

Sounds as if we have a programming equivalent of Schneier's Law:

Any programmer can write a program so good he can't find any bugs in it.

Schneier's law of software?

Posted Jul 23, 2012 17:45 UTC (Mon) by Tet (subscriber, #5433) [Link]

It pretty much already exists, and long predates Schneier's:

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
-- Brian Kernighan, "The Elements of Programming Style"