One of the things that bothers me about Fedora development is that things automatically end up anywhere after being built. I’m a big believer in having to do something to put software in the hands of users, even if they are running a development distribution, and even if they should “be able to fix whatever breaks”. Today, if you build something in rawhide, it’ll land on user machines tomorrow (in the default case). This applies especially if you do a “known good” build and then do “just one more” before the early morning hours when the mirrors get updated with today’s version.
In my opinion, rawhide isn’t a playpen. It’s supposed to be a place where things bake, but it should not be the place where random crap is shoved that might (or might not) randomly break things because it hasn’t even been tested on a local machine somewhere first. I think packages should always at least pass a boot/login test (or whatever appropriately similar activity) on a local system before they are made available in rawhide, and there should be some minimal activity involved to indicate that a package is intended for pushing (not just a build that wasn’t done as a scratch or that needs to be tested, etc.). It doesn’t have to require any proventester, any specific QE, any whatever, but it should require that the packager type something that indicates they built this package intending for it to be used by a lot of rawhide users. Again, rawhide is for fun, but it’s not a playpen.
Jon.
I kind of agree, since I’d love to be able to use Rawhide on a regular basis, which isn’t really possible at the moment.
However, I think a much bigger problem is when someone builds a package that will land in Rawhide the next day, breaking everything that depends on this package because the maintainer didn’t bother rebuilding them all together or ask for a custom tag.
We can’t do any actual development that way.
You cannot require us to run Rawhide. How can I do development if my development machine does not work?
It’s already enough of a PITA to have to deal with Bodhi for released distributions, doing it for Rawhide would break Fedora development entirely.
That’s what –scratch is all about … or local sanity checks before Koji submission.
It has been the plan since the start of the AutoQA effort (a few years ago at a FUDCon in Boston) that there would be a layer of AutoQA between a build completing, and a build being tagged for public consumption. If you wish to get this in place sooner, please donate some time to the AutoQA project.
If you only want to play with the package yourself, you need to do a scratch build. Regular builds are only to build packages intended to go into the distro. Conceptually I think that’s enough, but perhaps the UI should encourage scratch builds first and make regular builds seem more like the exception.