On Wednesday, September 22, 2010, 8:06:12 AM, drag01 wrote: > On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: >> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote: >>> 2010/9/20 MichaÅ Piotrowski <mkkp4x4@xxxxxxxxx>: >>> > 2010/9/21 Toshio Kuratomi <a.badger@xxxxxxxxx>: >>> >> As the concept of using third party repositories (both as packagers and as >>> >> users) grows, this interdependence will grow. >>> > >>> > Ok, so maybe it's time to setup Fedora "backports" repo for these that >>> > wants new and shiny Firefox 4, PostgreSQL 9 or whatever with big >>> > number. >>> >>> >>> What exactly is the fear here with these updates? Are there many >>> desktop users who do NOT want the latest released Firefox? Are there >>> many people using Fedora as their OS for their database server? >> >> Maybe we should turn this around and ask why more people don't >> use Rawhide. > Well "use rawhide" for anything else than testing and/or developing > the new release just do not fly. > Some of the reasons I can think of: > 1) To high rate of changes / breakage These are two separate issues. Change: Without change in Fedora, we might as well turn off the lights. Keeping the change rate high in Rawhide is the whole point. After all, we are trying to keep the other releases more stable by minimizing unnecessary or incompatible changes there - E.G. the branched release that is being packaged, stabilized and validated for formal release, and especially the stable releases that folks need for normal day-to-day usage. Breakage: The problem you are describing in rawhide is partly due to your other points. "Np Frozen Rawhide" was introduced to try to make it so that given a functional Rawhide, the branching off of a new periodic release would become easier. One issue is that while the other releases have a base, updates and updates testing repository that is supposed to allow change to be introduced in a controlled manner, rawhide is basically the other side of the wall (as in, "throw the update over the wall" after it builds). This means rawhide tends to be broken because of incomplete or untested changes, rather than change in general. If a second rawhide-specific staging repository (equivalent to updates-testing, so call it rawhide-testing) was added with some autoqa automation to prevent gratuitous problems (such as broken dependencies in core components), I suspect the situation would improve. Migration of updated packages from rawhide-testing to rawhide would be controlled by the same koji mechanisms that control updating of the other fedora release, but with less restrictions (some wait by default, but not a week), support for karma (negative karma to require override to migrate). I suspect that proventester approval would not be required (aside from there not being enough proventesters to also handle rawhide). > 2) No signed packages There has been discussion of the signing to be there, marking the package as being built by the Fedora buildsystem. > 3) Slower kernel On purpose - first you get things right, then you get them fast. Those additional checks are important so that any issues are identified as soon as possible. You want to benchmark something? Build a no-debug kernel. > 4) To much of "manual fixing" required Maybe reduced with a bit of focus, but likely also part of the nature of the beast. > 5) To many broken deps, which might prevent applying updates and security fixes This one autoqa should be able to solve. Reduces breakage in general, and helps ensure that breakage in branched releases is identified sooner. > 6) Some others that I can't think of right now might be a consequence > of the above or something else Stuff happens, but Rawhide is the place for it to happen. But not gratuitously - that's not being nice to your fellow Fedora team members. > So please stop proposing rawhide for productive systems (or even > database servers *shrug*). I think that Rawhide is being proposed for testing those types of systems, so that folks help ensure new features reach branched releases ASAP... and in some cases, that might mean an exception granted to update a stable release. Anyone using Rawhide for actual production either knows exactly what they are doing, and is cherry-picking updates once they are done initial setup... or is irretrievably insane (in which case, they won't listen to any advise other than the voices in their heads). Al -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
