Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
Le mercredi 22 septembre 2010 à 21:30 -0400, Gerald Henriksen a écrit : After all Gnome 2.32 isn't released until later this month, and the beta releases have been included in Fedora 14 up to now. Is that a good example ? Gnome has been broken one way or another in Fedora 14 since branching point (I'm missing the *stable* GNOME experience I had in rawhide). The desktop team usually handles alpha/beta well, but this time they've overshot imho. -- Nicolas Mailhot signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Thu, Sep 23, 2010 at 8:34 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le mercredi 22 septembre 2010 à 21:30 -0400, Gerald Henriksen a écrit : After all Gnome 2.32 isn't released until later this month, and the beta releases have been included in Fedora 14 up to now. Is that a good example ? Gnome has been broken one way or another in Fedora 14 since branching point (I'm missing the *stable* GNOME experience I had in rawhide). The desktop team usually handles alpha/beta well, but this time they've overshot imho. Well this cycle there was on the way to gnome3 and back situation, which caused a lot of churn (even upstream). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On 23 September 2010 08:37, drago01 drag...@gmail.com wrote: Well this cycle there was on the way to gnome3 and back situation, which caused a lot of churn (even upstream). For what it's worth, the GNOME will we, won't we on a few different issues (GApplication, GTK3, etc) has cost a lot of developer time, and from an upstream perspective was a royal pain in the behind. I think Matthias has done a wonderful job keeping F14 in some sort of semblance, even with all this upstream turmoil. I think 2.32 is going to be a pretty good, stable release, but a lot of people (myself included) are saving the new bells and whistles for GNOME 3.0. Expect the Fedora 15 feature page for GNOME to read a little more interesting, for sure. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Thu, Sep 23, 2010 at 9:59 AM, Richard Hughes hughsi...@gmail.com wrote: On 23 September 2010 08:37, drago01 drag...@gmail.com wrote: Well this cycle there was on the way to gnome3 and back situation, which caused a lot of churn (even upstream). For what it's worth, the GNOME will we, won't we on a few different issues (GApplication, GTK3, etc) has cost a lot of developer time, and from an upstream perspective was a royal pain in the behind. That's what I meant with even upstream. I think Matthias has done a wonderful job keeping F14 in some sort of semblance, even with all this upstream turmoil. No disagreement here. I think 2.32 is going to be a pretty good, stable release, but a lot of people (myself included) are saving the new bells and whistles for GNOME 3.0. Expect the Fedora 15 feature page for GNOME to read a little more interesting, for sure. Neither here ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
Le jeudi 23 septembre 2010 à 08:59 +0100, Richard Hughes a écrit : On 23 September 2010 08:37, drago01 drag...@gmail.com wrote: Well this cycle there was on the way to gnome3 and back situation, which caused a lot of churn (even upstream). For what it's worth, the GNOME will we, won't we on a few different issues (GApplication, GTK3, etc) has cost a lot of developer time, and from an upstream perspective was a royal pain in the behind. I think Matthias has done a wonderful job keeping F14 in some sort of semblance, even with all this upstream turmoil. I agree completely. My point was that it is *hard* to push new major versions reliably just-before-freeze, that even big stable paid teams with lots of experience like the desktop team do not always manage it well, and people should stop claiming this kind of update is suitable for a stable release just because they'd like it to happen. Major updates require lots of testing to limit harmful side-effects. People have the choice of waiting for the next stable release, while this testing occurs in rawhide and alpha/beta/etc, or provide this testing live in rawhide. Direct dump in stable with minimal testing and no problems, is a nice fantasy, but it's just that, a *fantasy*. Facts do not agree with this idea. Upstream projects that claim it can be done usually define working as my stuff works, if I broke something in other apps it's not my problem (netscape projects like mozilla, firefox nss are a case in point: they are pathologically unable to provide updates that work well with the rest of the ecosystem. It only works on windows because there the rest of the ecosystem is so foreign it shares nothing with them) -- Nicolas Mailhot signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
Er, whut? I didn't post anything advocating people use Rawhide for day-to-day purposes. I wouldn't suggest such a thing. All I said was that I haven't noticed the speed difference between debug and non-debug kernels, because I haven't. I know it's measurably present, but it doesn't affect any of my typical usage visibly. People are recommending it for people who want the latest software. Which isn't what Rawhide is for (based on all information I've read and know about it). We seem to have users who want less updates and no changes. We also have users who want to be on the forefront of change. I think everyone could be helped by making it easier to use repos for non savvy users. It would keep the main repo focused on stable software for users who are afraid of change. The alternate repos would be available for the more adventurous users or developers. Rawhide is for testers and developers. I don't think anyone sane uses Rawhide for 'production use' or even 'general purpose use' unless testing. Some people also pointed out another interesting tidbit and that is proprietary video drivers. Some of us use them and want to be able to use them. We wouldn't be using a rawhide kernel if it won't load the modules. I assume users of proprietary kernel drivers would have to set it up in f13 with rpmfusion and nvidia-akmod first before upgrading to rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Thu, Sep 23, 2010 at 09:34:12 -0400, Brandon Lozza bran...@pwnage.ca wrote: Some people also pointed out another interesting tidbit and that is proprietary video drivers. Some of us use them and want to be able to use them. We wouldn't be using a rawhide kernel if it won't load the modules. I assume users of proprietary kernel drivers would have to set it up in f13 with rpmfusion and nvidia-akmod first before upgrading to rawhide. The kmod rpms for rawhide are already provided by rpmfusion. I don't know how often they do them nor how often new kernel releases just plain break the proprietary drivers. But it sure likes look at least some of the time you should be able to use them. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
Bruno Wolff III wrote: The kmod rpms for rawhide are already provided by rpmfusion. I don't know how often they do them nor how often new kernel releases just plain break the proprietary drivers. But it sure likes look at least some of the time you should be able to use them. Bruno, you can't use certain proprietary modules with debugging kernels. GPL symbols prevent you. In particular, the LOCKDEP stuff. Frank mentioned[1] a viable option for Rawhide, but with Rawhide broken more often then not, it still isn't a viable option to use every day. I can't recommend it to Joe Schmoe if he wants Firefox 4.0 and he runs into broken deps or broken apps and goes off and uses Ubuntu or SuSE because of it. [1] http://lists.fedoraproject.org/pipermail/kernel/2010-September/002688.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Thu, 23 Sep 2010 08:34:06 +0200, you wrote: Le mercredi 22 septembre 2010 à 21:30 -0400, Gerald Henriksen a écrit : After all Gnome 2.32 isn't released until later this month, and the beta releases have been included in Fedora 14 up to now. Is that a good example ? Gnome has been broken one way or another in Fedora 14 since branching point (I'm missing the *stable* GNOME experience I had in rawhide). The desktop team usually handles alpha/beta well, but this time they've overshot imho. Well, Gnome has a proven track record and this release seems to be the exception. In fairness to the desktop team, who seem to have been given a mess with the delay of Gnome 3, I think Gnome should have skpped the 2.32 release rather than this attempt to get something newish just to meet a schedule. It's unfortunate that the desktop team will get blamed for what is a Gnome mistake. But the broader point is what criteria is used to determine what software gets included in a given release of Fedora. A key point in the drive to have stable releases is that it is only a 6 month wait to get a newer version of something into Fedora. But there is a danger that this can go too far and end up being 9 or 10 months if a project must have a final release before Fedora branches. Someone wanting the latest PostgreSQL is looking at an 8 month wait (assuming a May Fedora 15), and anything that was released in August but not included in the Fedora 14 branch has 9 months if we don't allow pre-releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Thu, Sep 23, 2010 at 11:23:25 -0500, Michael Cronenworth m...@cchtml.com wrote: Bruno Wolff III wrote: The kmod rpms for rawhide are already provided by rpmfusion. I don't know how often they do them nor how often new kernel releases just plain break the proprietary drivers. But it sure likes look at least some of the time you should be able to use them. Bruno, you can't use certain proprietary modules with debugging kernels. GPL symbols prevent you. In particular, the LOCKDEP stuff. That's interesting, because rpmfusion has nvidia modules in their development repo. It could be that they were for older kernels or something, I didn't look at the versions too closely. Frank mentioned[1] a viable option for Rawhide, but with Rawhide broken more often then not, it still isn't a viable option to use every day. I can't recommend it to Joe Schmoe if he wants Firefox 4.0 and he runs into broken deps or broken apps and goes off and uses Ubuntu or SuSE because of it. To use rawhide you really need to be able to fix things; so you need to be an advanced user. There is also the branched release. It should be a bit better than rawhide, but does seem to get broken on occasion. Builds go through testing, so there is a chance to catch a lot of the bad stuff there before it gets to people not using testing. This would still be for advanced linux users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: 2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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. I use Rawhide on my laptop and one of my servers, so I'll tell you the answer to this: because critical components such as the kernel are often broken. IME this is because there is no testing of these components before they get pushed out, and also the kernel developers ignore bug reports. This is reasonably easy to fix: we should do some testing and withhold packages from Rawhide if they don't pass some basic sanity checks (eg. does it boot, can an X server be started). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
2010/9/22 Richard W.M. Jones rjo...@redhat.com: Maybe we should turn this around and ask why more people don't use Rawhide. Maybe because when I installed rawhide I lost my desktop icons? :) IMHO rawhide isn't the right answer for most users who wants just one new app. Rich. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote: This is reasonably easy to fix: we should do some testing and withhold packages from Rawhide if they don't pass some basic sanity checks (eg. does it boot, can an X server be started). That's basically the proven testers process, which at present is running around capacity trying to cover three releases (two current stable, plus Branched). I'm really not sure we could manage another release, especially one like Rawhide where people have a right to expect updates to land quickly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: 2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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 2) No signed packages 3) Slower kernel 4) To much of manual fixing required 5) To many broken deps, which might prevent applying updates and security fixes 6) Some others that I can't think of right now might be a consequence of the above or something else So please stop proposing rawhide for productive systems (or even database servers *shrug*). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 8:06 AM, drago01 drag...@gmail.com wrote: On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: 2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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 2) No signed packages 3) Slower kernel 4) To much of manual fixing required 5) To many broken deps, which might prevent applying updates and security fixes 6) Some others that I can't think of right now might be a consequence of the above or something else So please stop proposing rawhide for productive systems (or even database servers *shrug*). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel That's why I propose an easy way to install additional repos. I can't see a non tech savvy user installing the chromium browser on fedora, to be brutally honest. It's annoying having to hold their hand and walk them through it. I don't see why the user can't double click the repo file and have some application do the work for them. Or even have a place where they can input a URL for the repo and some program adds it to the database. Expecting the user to copy the .repo file into the yum repos directory is extremely non intuitive and to be perfectly honest I'm tech savvy and I can't be bothered to remember the path name for that directory. If people want Fedbuntu, at least copy this feature. Every other distro has an easy way for the user to add third party repositories using a tool. Perhaps an add button inside kpackagekit? It does have the ability to disable and enable repos. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 2010-09-22 at 08:20 -0400, Brandon Lozza wrote: That's why I propose an easy way to install additional repos. I can't see a non tech savvy user installing the chromium browser on fedora, to be brutally honest. It's annoying having to hold their hand and walk them through it. I don't see why the user can't double click the repo file and have some application do the work for them. It's already possible, the chromium repo just isn't set up this way (it's a bit of work). See the rpmfusion repo setup process for an example. It's basically just an RPM which contains the repo definitions; you double-click the RPM, PackageKit pops up and installs it, and hey presto, you have a new repo. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2010 05:06 AM, drago01 wrote: 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 Not much one can do on this one, other than choose when to apply their updates. 2) No signed packages We will be fixing that, so that anything that falls out of koji will get signed (except scratch builds) 3) Slower kernel Not much I can do about that. 4) To much of manual fixing required 5) To many broken deps, which might prevent applying updates and security fixes 6) Some others that I can't think of right now might be a consequence of the above or something else I think those can be addressed by placing an AutoQA filter between a build from master and the build showing up in rawhide. So please stop proposing rawhide for productive systems (or even database servers *shrug*). - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyagM0ACgkQ4v2HLvE71NUmWwCgxETatIEx39lknPjpOMk1aIFH LFMAni7OnWZD/TigvHv2dnEqkXJoqiYE =Y1mY -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2010 04:07 AM, Adam Williamson wrote: On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote: This is reasonably easy to fix: we should do some testing and withhold packages from Rawhide if they don't pass some basic sanity checks (eg. does it boot, can an X server be started). That's basically the proven testers process, which at present is running around capacity trying to cover three releases (two current stable, plus Branched). I'm really not sure we could manage another release, especially one like Rawhide where people have a right to expect updates to land quickly. I think the idea is to apply an AutoQA filter between the builds and showing up in rawhide, not applying a bunch of human tester filters and bodhi. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyagPAACgkQ4v2HLvE71NUqsQCeI2Txx7Xfd8X7PmbdKJVEUakd KaEAni/nSvaBFQfqVXST+wv6WhOyb7aI =3BxD -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 12:07:24PM +0100, Adam Williamson wrote: On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote: This is reasonably easy to fix: we should do some testing and withhold packages from Rawhide if they don't pass some basic sanity checks (eg. does it boot, can an X server be started). That's basically the proven testers process, which at present is running around capacity trying to cover three releases (two current stable, plus Branched). I'm really not sure we could manage another release, especially one like Rawhide where people have a right to expect updates to land quickly. I really meant automated tests. At the moment when I build libguestfs is when I find many kernel and qemu bugs, because that is the first time that anyone has tried to actually run the things. (Unfortunately at the moment I have had to turn this testing off for Rawhide because of a fatal kernel bug that no one has acknowleged -- 630777). This testing is completely automatic and happens in Koji as part of the %check section of the build. We run the kernel/qemu/userspace combination together and subject them to about an hour of stress-testing. All I'm saying is, run these automated tests and fail the build if the %check section fails. For extra marks, fix the bugs that are found. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 02:06:12PM +0200, drago01 wrote: On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: 2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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. If you read the second part of what I said, you'll see that I proposed a way to address some of these issues. Some of the reasons I can think of: 1) To high rate of changes / breakage 2) No signed packages 3) Slower kernel 4) To much of manual fixing required 5) To many broken deps, which might prevent applying updates and security fixes 6) Some others that I can't think of right now might be a consequence of the above or something else Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
I should add that whether this testing happens in Koji or in AutoQA isn't material. AutoQA is probably better. *Provided* that if the basic sanity tests fail they must prevent the packages from going into the Rawhide compose. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 9:33 AM, Richard W.M. Jones rjo...@redhat.com wrote: I should add that whether this testing happens in Koji or in AutoQA isn't material. AutoQA is probably better. *Provided* that if the basic sanity tests fail they must prevent the packages from going into the Rawhide compose. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Having an rpm add a repo file doesn't automatically solve the problem for 100% of the repos out there. That leaves delegates the repo work to the package maintainer. All because we don't want to copy Ubuntu's GOOD ideas, just their BAD ones (like stale software updates vision). As I said I'm not a programmer or I would do this myself. I don't want Fedora to keep being behind openSUSE. Worst case scenario we'll see a fork over the updates vision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
something like sidux, but fedora based im thinking stable f14 with the goodies stable vision blocks because people want stale software, and i'd rather not use rawhide or opensuse On Wed, Sep 22, 2010 at 9:53 AM, Brandon Lozza bran...@pwnage.ca wrote: On Wed, Sep 22, 2010 at 9:33 AM, Richard W.M. Jones rjo...@redhat.com wrote: I should add that whether this testing happens in Koji or in AutoQA isn't material. AutoQA is probably better. *Provided* that if the basic sanity tests fail they must prevent the packages from going into the Rawhide compose. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Having an rpm add a repo file doesn't automatically solve the problem for 100% of the repos out there. That leaves delegates the repo work to the package maintainer. All because we don't want to copy Ubuntu's GOOD ideas, just their BAD ones (like stale software updates vision). As I said I'm not a programmer or I would do this myself. I don't want Fedora to keep being behind openSUSE. Worst case scenario we'll see a fork over the updates vision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wednesday, September 22, 2010, 8:06:12 AM, drag01 wrote: On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: 2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 2010-09-22 at 15:18 -0700, Jesse Keating wrote: 4) To much of manual fixing required 5) To many broken deps, which might prevent applying updates and security fixes 6) Some others that I can't think of right now might be a consequence of the above or something else I think those can be addressed by placing an AutoQA filter between a build from master and the build showing up in rawhide. That would likely be an improvement, but have you thought through the interaction issues? Builds are rarely standalone, so we need to figure out which builds go with which other builds so they can be tested together. Or we can test an entire Rawhide push at one time, but in that case, which package do you block if the automated test fails? All of them? Pick one at random? Try and write heuristics so AutoQA can figure out which package to block? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wednesday, September 22, 2010, 6:19:28 PM, Jesse wrote: On 09/22/2010 04:07 AM, Adam Williamson wrote: On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote: This is reasonably easy to fix: we should do some testing and withhold packages from Rawhide if they don't pass some basic sanity checks (eg. does it boot, can an X server be started). That's basically the proven testers process, which at present is running around capacity trying to cover three releases (two current stable, plus Branched). I'm really not sure we could manage another release, especially one like Rawhide where people have a right to expect updates to land quickly. I think the idea is to apply an AutoQA filter between the builds and showing up in rawhide, not applying a bunch of human tester filters and bodhi. Add a separate rawhide-testing repo as a staging area for changes (equivalent to updates-testing in a branched release). - Use autoqu to run basic tests and dependency checks. - Use a subset of the controls for branched releases. The focus should be that once dependencies and any package-provide tests are good things can quickly and automatically move into rawhide. Suggestions re controls: Make the delay for automatic promotion short (say 2 days delay instead of a week). Let bad karma hold back bad updates, but make promotion easier than for a branched release. Don't tie up proventester resources. Allow developers to push directly to rawhide if the autoqa tests pass - require FES override otherwise. In other words, create a sane system that parallels that used by branched releases. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 10:24:38 +0100, Richard W.M. Jones rjo...@redhat.com wrote: I use Rawhide on my laptop and one of my servers, so I'll tell you the answer to this: because critical components such as the kernel are often broken. IME this is because there is no testing of these components before they get pushed out, and also the kernel developers ignore bug reports. The kernel isn't that big of a deal unless there is a bug tied to your specific hardware. You can make the default the old kernel on updates and upgrade the kernel at a convenient time. If one breaks things for everyone, that will get fixed pretty quick. If there is a bug tied to specific hardware, affecting a small number people, it can take a long time to fixed in some cases. I find it's more just random stuff breaks and I need to work around something at a bad time. This is more likely to happen when some big change first lands. Or when the thunderbird guys update thunderbird and sunbird, but don't care if sunbird even works. If we were better about getting big changes in before the branch, running branched versions would probably be reasonable for people that want something close to a rolling update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 14:06:12 +0200, drago01 drag...@gmail.com wrote: Some of the reasons I can think of: 2) No signed packages There is a plan to deal with that, but I am not sure what its current status is. 5) To many broken deps, which might prevent applying updates and security fixes Hopefully autoqa will deal with this. My opinion is broken deps shouldn't be allowed except in updates-testing repos. Not even in rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 09:59:51 -0400, Al Dunsmuir al.dunsm...@sympatico.ca wrote: 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. That is what branched releases have. Running one of these still gets you pretty up to date stuff, but a bit more protection from breakage. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 15:34:34 +0100, Richard W.M. Jones rjo...@redhat.com wrote: No, I think you are wrong. First of all, I can see no benefit in pushing a package that cannot do its basic function to Rawhide. Even in Rawhide, no one wants a kernel that doesn't boot, even if in some circumstances they could go to the trouble of downgrading their kernel. If we can test these situations easily and reject these packages, we should just do it. (libguestfs %check is a proof by example that such a thing is possible and easy in Koji). My issue was with how much of a problem broken kernels in rawhide are. It's still a problem, but not as big of a problem as other random breakage when trying to run rawhide as your desktop. Secondly, it does matter that in Rawhide you can at least get to the login prompt, log in, and get a shell. AIUI this was the basic idea behind the critical path packages. From the shell you have a hope of fixing things. Your browser not working is a problem you might be able to fix with a shell. Your kernel hanging under disk load or hanging in init scripts (both actual problems with the current Rawhide kernel) is a good deal more complex to fix. Sure, but if you don't automatically switch to the new kernel on every update (there's a setting to control this), you won't likely run into that because of a kernel update. You might have something else cause that though. The downside is that at some point you need to manually go in and switch kernels. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2010 04:14 PM, Al Dunsmuir wrote: On Wednesday, September 22, 2010, 6:19:28 PM, Jesse wrote: On 09/22/2010 04:07 AM, Adam Williamson wrote: On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote: This is reasonably easy to fix: we should do some testing and withhold packages from Rawhide if they don't pass some basic sanity checks (eg. does it boot, can an X server be started). That's basically the proven testers process, which at present is running around capacity trying to cover three releases (two current stable, plus Branched). I'm really not sure we could manage another release, especially one like Rawhide where people have a right to expect updates to land quickly. I think the idea is to apply an AutoQA filter between the builds and showing up in rawhide, not applying a bunch of human tester filters and bodhi. Add a separate rawhide-testing repo as a staging area for changes (equivalent to updates-testing in a branched release). - Use autoqu to run basic tests and dependency checks. - Use a subset of the controls for branched releases. The focus should be that once dependencies and any package-provide tests are good things can quickly and automatically move into rawhide. Suggestions re controls: Make the delay for automatic promotion short (say 2 days delay instead of a week). Let bad karma hold back bad updates, but make promotion easier than for a branched release. Don't tie up proventester resources. Allow developers to push directly to rawhide if the autoqa tests pass - require FES override otherwise. In other words, create a sane system that parallels that used by branched releases. Al I don't see the need to actually publish a rawhide-testing repo. Just rawhide. If a package passes autoqa, let it in. If a maintainer waives the autoqa failure, let it in. I really don't want to run bodhi on rawhide. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaGWsACgkQ4v2HLvE71NWqjgCgpn0wX6QcKFjGliKuHkLOwj6Z scAAoJuqQolUnAPXNMvOlOugpafYu2gr =wBqL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2010 04:14 PM, Adam Williamson wrote: That would likely be an improvement, but have you thought through the interaction issues? Builds are rarely standalone, so we need to figure out which builds go with which other builds so they can be tested together. Or we can test an entire Rawhide push at one time, but in that case, which package do you block if the automated test fails? All of them? Pick one at random? Try and write heuristics so AutoQA can figure out which package to block? The way I was thinking is this. There would be two tags, rawhide and rawhide-pending. the rawhide tag (or whatever it is an alias for) is where things go that have passed autoqa. rawhide-pending is where things go that have not yet passed auto-qa, and is the first stop after a build. When things land in rawhide-pending an autotest run is ran in two stages. One stage just uses what's currently in rawhide. If it passes, let it through. If it fails, do another stage that includes all the packages in rawhide /and/ rawhide-pending for it's repodata. If the package passes it will have to be marked as requiring something that is in -pending and not in rawhide yet. Insert some magic here. It isn't going to be perfect, but it'll definitely be better than what we have now. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaGzoACgkQ4v2HLvE71NUaiACggUis0yoy8WIUeN5m1XkAjMX1 raUAn30Tx48M8pY2BGtc+XE6FFBQcQbh =6zdx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 17:05:30 +0200, Jesse Keating jkeat...@redhat.com wrote: It isn't going to be perfect, but it'll definitely be better than what we have now. The other case to consider is two updates in rawhide-pending that each are OK with rawhide, but which together have dependency issues. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/22/2010 05:07 PM, Bruno Wolff III wrote: On Wed, Sep 22, 2010 at 17:05:30 +0200, Jesse Keating jkeat...@redhat.com wrote: It isn't going to be perfect, but it'll definitely be better than what we have now. The other case to consider is two updates in rawhide-pending that each are OK with rawhide, but which together have dependency issues. In this case, the first one tested will get in, the second one will not. Most likely we will need to lock autoqa down to testing one package at a time and not move on to the next build until after the first test/move is done to avoid races, if they are common. Stuff to explore. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyaHQAACgkQ4v2HLvE71NXclACgrCRnMsmUysJDKz7LqkU77MM1 nXYAnA/Z68opRU28IaoPL+yNbk5mf6UA =nnuL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
Jesse Keating wrote: It isn't going to be perfect, but it'll definitely be better than what we have now. I'm still not going to use rawhide. There would have to be a kernel without debugging before I would even think of using it for my home or work systems. I have a need for speed. :P -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 2010-09-22 at 10:13 -0500, Michael Cronenworth wrote: Jesse Keating wrote: It isn't going to be perfect, but it'll definitely be better than what we have now. I'm still not going to use rawhide. There would have to be a kernel without debugging before I would even think of using it for my home or work systems. I have a need for speed. :P I've honestly never noticed the difference between a debug and a non-debug kernel. I guess I spend too much money on CPUs. Or don't work 'em hard enough. :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 04:22:45PM +0100, Adam Williamson wrote: On Wed, 2010-09-22 at 10:13 -0500, Michael Cronenworth wrote: Jesse Keating wrote: It isn't going to be perfect, but it'll definitely be better than what we have now. I'm still not going to use rawhide. There would have to be a kernel without debugging before I would even think of using it for my home or work systems. I have a need for speed. :P I've honestly never noticed the difference between a debug and a non-debug kernel. I guess I spend too much money on CPUs. Or don't work 'em hard enough. :P I've not noticed it either, and that is with running Rawhide on my two most-used systems. And I'm not exactly using leading-edge hardware either. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 6:55 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Sep 22, 2010 at 04:22:45PM +0100, Adam Williamson wrote: On Wed, 2010-09-22 at 10:13 -0500, Michael Cronenworth wrote: Jesse Keating wrote: It isn't going to be perfect, but it'll definitely be better than what we have now. I'm still not going to use rawhide. There would have to be a kernel without debugging before I would even think of using it for my home or work systems. I have a need for speed. :P I've honestly never noticed the difference between a debug and a non-debug kernel. I guess I spend too much money on CPUs. Or don't work 'em hard enough. :P I've not noticed it either, and that is with running Rawhide on my two most-used systems. And I'm not exactly using leading-edge hardware either. You both don't use GPUs are lot aren't you? ;) While working on gnome-shell we noticed a ~30-40% performance drop by running a debugging kernel compared to a non debug build (on both intel and radeon). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 22 Sep 2010 13:57:49 +0100, Adam Williamson wrote: On Wed, 2010-09-22 at 08:20 -0400, Brandon Lozza wrote: That's why I propose an easy way to install additional repos. I can't see a non tech savvy user installing the chromium browser on fedora, to be brutally honest. It's annoying having to hold their hand and walk them through it. I don't see why the user can't double click the repo file and have some application do the work for them. It's already possible, the chromium repo just isn't set up this way (it's a bit of work). See the rpmfusion repo setup process for an example. It's basically just an RPM which contains the repo definitions; you double-click the RPM, PackageKit pops up and installs it, and hey presto, you have a new repo. I believe Brandon want something that openSUSE already does with it's One Click Install -- a small script that drops a new repo file, *then* issue an install instruction for one of the packages from that repo. I'm traveling right now, but depending on how good the Internet connection is, I might be able to work on Fedora-izing the one-click system. Hopefully not much needs changing to adapt it to Yum instead of whatever openSUSE uses right now (is it still Zypper? My workplace is still on openSUSE 11.1 and I don't have a newer version installed elsewhere) Cheers, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 22 Sep 2010 09:33:47 -0500, Bruno Wolff III wrote: On Wed, Sep 22, 2010 at 09:59:51 -0400, Al Dunsmuir al.dunsm...@sympatico.ca wrote: 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. That is what branched releases have. Running one of these still gets you pretty up to date stuff, but a bit more protection from breakage. But branched releases stabilize sometime before the beta point is reached, which triggered off this huge discussion in the first place, because Postgresql 9.0 came out too late for inclusion. -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 22 Sep 2010 19:00:25 +0200, drago01 wrote: On Wed, Sep 22, 2010 at 6:55 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Sep 22, 2010 at 04:22:45PM +0100, Adam Williamson wrote: I guess I spend too much money on CPUs. Or don't work 'em hard enough. :P I've not noticed it either, and that is with running Rawhide on my two most-used systems. And I'm not exactly using leading-edge hardware either. You both don't use GPUs are lot aren't you? ;) While working on gnome-shell we noticed a ~30-40% performance drop by running a debugging kernel compared to a non debug build (on both intel and radeon). One could always use a stable kernel in conjunction with Rawhide. Speaking of debugging info, are they still turned on for branched releases like F-14? -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
Michel Alexandre Salim wrote: One could always use a stable kernel in conjunction with Rawhide. Speaking of debugging info, are they still turned on for branched releases like F-14? Yes. Not until the Final RC builds is debugging switched off. (IIRC) Rawhide kernels or using a stable kernel w/ Rawhide are not valid options. Rawhide is rawhide - development of Fedora, not for production use. Period. You can't jazz it up no matter how hard you try (Looking at you Jesse, Adam, and Bruno). P.S. Can't use proprietary kernel modules (which some people have to use) with debugging kernels. The world isn't perfect and neither is Fedora. I can see a big increase in boot time with my desktop setup when using a debugging kernel among other slow-downs. From 8 seconds (non-debug) at least double that. I use modern CPUs (quad core a minimum) with SSDs and fast GPUs. Speed is very important to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 19:33:22 +, Michel Alexandre Salim fed...@michelsylvain.info wrote: But branched releases stabilize sometime before the beta point is reached, which triggered off this huge discussion in the first place, because Postgresql 9.0 came out too late for inclusion. But if you are tracking branch releases you still need to wait less time. I don't have the planned date, but I think the F15 branch will occur in December which cuts the waiting time down to a about 3 months instead of about 7 months. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 14:45:03 -0500, Michael Cronenworth m...@cchtml.com wrote: Rawhide kernels or using a stable kernel w/ Rawhide are not valid options. Rawhide is rawhide - development of Fedora, not for production use. Period. You can't jazz it up no matter how hard you try (Looking at you Jesse, Adam, and Bruno). Well that depends on what you mean by production and what your needs are. The people that running rawhide or branched are suggested to are generally asking about using it to run the very latest of something (without having to go through the trouble of packaging it themselves). That sounds like testing to me, not production. People that try to both at the same time (like I do for my personal systems) have to balance both uses. P.S. Can't use proprietary kernel modules (which some people have to use) with debugging kernels. The world isn't perfect and neither is Fedora. The earlier message about debugging kernels has prompted a message to the Fedora kernel list about that topic. If you are interested in this, you might want to comment in that discussion. (All of one message so far.) http://lists.fedoraproject.org/pipermail/kernel/2010-September/002682.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 2010-09-22 at 14:45 -0500, Michael Cronenworth wrote: Michel Alexandre Salim wrote: One could always use a stable kernel in conjunction with Rawhide. Speaking of debugging info, are they still turned on for branched releases like F-14? Yes. Not until the Final RC builds is debugging switched off. (IIRC) Rawhide kernels or using a stable kernel w/ Rawhide are not valid options. Rawhide is rawhide - development of Fedora, not for production use. Period. You can't jazz it up no matter how hard you try (Looking at you Jesse, Adam, and Bruno). Er, whut? I didn't post anything advocating people use Rawhide for day-to-day purposes. I wouldn't suggest such a thing. All I said was that I haven't noticed the speed difference between debug and non-debug kernels, because I haven't. I know it's measurably present, but it doesn't affect any of my typical usage visibly. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, Sep 22, 2010 at 02:45:03PM -0500, Michael Cronenworth wrote: I can see a big increase in boot time with my desktop setup when using a debugging kernel among other slow-downs. From 8 seconds (non-debug) at least double that. I use modern CPUs (quad core a minimum) with SSDs and fast GPUs. Speed is very important to me. booting with slab_debug=- should mitigate one of the more expensive options. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Wed, 22 Sep 2010 19:33:22 + (UTC), you wrote: On Wed, 22 Sep 2010 09:33:47 -0500, Bruno Wolff III wrote: That is what branched releases have. Running one of these still gets you pretty up to date stuff, but a bit more protection from breakage. But branched releases stabilize sometime before the beta point is reached, which triggered off this huge discussion in the first place, because Postgresql 9.0 came out too late for inclusion. But did Postgresql 9 come out too late? PostgreSQL had a 2nd beta release on June 4th, which could have gone into Rawhide, and hence allowed PostgreSQL 9 to be in Fedora 14 (assuming that the packager had time to do it, and confidence that the PostgreSQL final release would have been in time). After all Gnome 2.32 isn't released until later this month, and the beta releases have been included in Fedora 14 up to now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 21 Sep 2010 01:43:43 +0100, Adam Williamson wrote: The Mandriva policy is a reasonable starting point: http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy it's sketchy and not greatly written, but the basic idea is that backports should only be 'leaf' packages (things on which nothing else depends) and libs required _only_ by the packages that are being backported. Packages on which other, unrelated packages depend shouldn't be backported. Sounds like the only way to package Firefox under such a backport scheme would be to bundle Gecko etc. -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 2010-09-21 at 08:49 +, Michel Alexandre Salim wrote: On Tue, 21 Sep 2010 01:43:43 +0100, Adam Williamson wrote: The Mandriva policy is a reasonable starting point: http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy it's sketchy and not greatly written, but the basic idea is that backports should only be 'leaf' packages (things on which nothing else depends) and libs required _only_ by the packages that are being backported. Packages on which other, unrelated packages depend shouldn't be backported. Sounds like the only way to package Firefox under such a backport scheme would be to bundle Gecko etc. Yup. In MDV, Firefox isn't/wasn't allowed under the backports guidelines. I think this makes sense given how important it is and how easy it is to break other stuff by touching Firefox. Some stuff just isn't right for a backports repo. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On 09/21/2010 02:19 PM, Michel Alexandre Salim wrote: On Tue, 21 Sep 2010 01:43:43 +0100, Adam Williamson wrote: The Mandriva policy is a reasonable starting point: http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy it's sketchy and not greatly written, but the basic idea is that backports should only be 'leaf' packages (things on which nothing else depends) and libs required _only_ by the packages that are being backported. Packages on which other, unrelated packages depend shouldn't be backported. Sounds like the only way to package Firefox under such a backport scheme would be to bundle Gecko etc. Yep. For a number of important packages, we have to resort to bundling libraries if we go this route. Other distros like Ubuntu are already doing this for their main Firefox packages. It might be a trade off worth considering for backport repo if one exists. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
2010/9/21 Adam Williamson awill...@redhat.com: On Tue, 2010-09-21 at 08:49 +, Michel Alexandre Salim wrote: Sounds like the only way to package Firefox under such a backport scheme would be to bundle Gecko etc. Yup. In MDV, Firefox isn't/wasn't allowed under the backports guidelines. I think this makes sense given how important it is and how easy it is to break other stuff by touching Firefox. Some stuff just isn't right for a backports repo. It seems to me that backports repo should be treated on a different basis by developers and users than any other official repos. I do not expect that it will have the normal technical support. I do not expect that the installation of package from the will not break anything. This should be something like use at your own risk if you want some newer packages, but do not expect that it will work completely without any problem with official Fedora repo and other repos like rpmfusion etc -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote: Setting up official backport repo will avoid repos fragmentation. Keeping all cool updates in one place appears to be a reasonable idea. Am I right? Wait a minute! You need to define fragmentation here. It seems you refer to the geographical location of repos only. More important is the fragmentation caused by increasing the number of repos, especially if they create additional targets to build for. Considering how APIs/ABIs and stable packages are broken regularly, I don't think Fedora Packagers could handle the increased maintenance requirements added by a backports repo. Whether official or not, just imagine what can happen if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better attempt at making the current dist release usable/deployable in production environments, and encourage more users to take a look at Rawhide and Alpha/Beta releases earlier. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 2010-09-21 at 13:49 +0200, Michael Schwendt wrote: On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote: Setting up official backport repo will avoid repos fragmentation. Keeping all cool updates in one place appears to be a reasonable idea. Am I right? Wait a minute! You need to define fragmentation here. It seems you refer to the geographical location of repos only. More important is the fragmentation caused by increasing the number of repos, especially if they create additional targets to build for. Considering how APIs/ABIs and stable packages are broken regularly, I don't think Fedora Packagers could handle the increased maintenance requirements added by a backports repo. Whether official or not, just imagine what can happen if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better attempt at making the current dist release usable/deployable in production environments, and encourage more users to take a look at Rawhide and Alpha/Beta releases earlier. I think he meant the same thing as you. He wasn't using 'place' literally. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
One thing I wanted to point out. Windows users get to install the latest Firefox, KDE, and other apps without having to wait for a new Windows release. If users had to wait for Windows 8 to get the latest Firefox, things would be messy. I don't understand what the fear is of doing this on GNU/Linux. On Tue, Sep 21, 2010 at 8:01 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2010-09-21 at 13:49 +0200, Michael Schwendt wrote: On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote: Setting up official backport repo will avoid repos fragmentation. Keeping all cool updates in one place appears to be a reasonable idea. Am I right? Wait a minute! You need to define fragmentation here. It seems you refer to the geographical location of repos only. More important is the fragmentation caused by increasing the number of repos, especially if they create additional targets to build for. Considering how APIs/ABIs and stable packages are broken regularly, I don't think Fedora Packagers could handle the increased maintenance requirements added by a backports repo. Whether official or not, just imagine what can happen if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better attempt at making the current dist release usable/deployable in production environments, and encourage more users to take a look at Rawhide and Alpha/Beta releases earlier. I think he meant the same thing as you. He wasn't using 'place' literally. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
Is GNU/Linux supposed to be a mirror into software's past? On Tue, Sep 21, 2010 at 10:20 AM, Brandon Lozza bran...@pwnage.ca wrote: One thing I wanted to point out. Windows users get to install the latest Firefox, KDE, and other apps without having to wait for a new Windows release. If users had to wait for Windows 8 to get the latest Firefox, things would be messy. I don't understand what the fear is of doing this on GNU/Linux. On Tue, Sep 21, 2010 at 8:01 AM, Adam Williamson awill...@redhat.com wrote: On Tue, 2010-09-21 at 13:49 +0200, Michael Schwendt wrote: On Tue, 21 Sep 2010 01:51:03 +0200, Michał wrote: Setting up official backport repo will avoid repos fragmentation. Keeping all cool updates in one place appears to be a reasonable idea. Am I right? Wait a minute! You need to define fragmentation here. It seems you refer to the geographical location of repos only. More important is the fragmentation caused by increasing the number of repos, especially if they create additional targets to build for. Considering how APIs/ABIs and stable packages are broken regularly, I don't think Fedora Packagers could handle the increased maintenance requirements added by a backports repo. Whether official or not, just imagine what can happen if repo 1 upgrades repo 2, or vice versa, and unexpectedly. Better attempt at making the current dist release usable/deployable in production environments, and encourage more users to take a look at Rawhide and Alpha/Beta releases earlier. I think he meant the same thing as you. He wasn't using 'place' literally. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 21 Sep 2010 00:36:46 -0400, you wrote: On Tue, Sep 21, 2010 at 12:29 AM, Gerald Henriksen ghenr...@gmail.com wrote: On Mon, 20 Sep 2010 21:58:53 -0400, you wrote: 2010/9/20 Micha? Piotrowski mkkp...@gmail.com: 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? What if you are using a Firefox extension that hasn't been ported to the latest release yet? You don't update Firefox till the extension comes out. And if there is a security update required that makes updating Firefox mandatory, what then? Fedora wouldn't be packaging the latest Firefox 3.* because under you scenario Firefox is at version 4. Sure, but I thought Fedora was all about pushing new, free software. It is, in two ways. One, Fedora makes releases every 6 months where new software can debut without worrrying about backwards compatibility. Secondly, for those more adventurous, you can run Rawhide which (subject to the packagers) can always have the just released versions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2010 07:20 AM, Brandon Lozza wrote: One thing I wanted to point out. Windows users get to install the latest Firefox, KDE, and other apps without having to wait for a new Windows release. If users had to wait for Windows 8 to get the latest Firefox, things would be messy. I don't understand what the fear is of doing this on GNU/Linux. Windows releases are years apart, not even close to comparable. Also Firefox updates are provided to the user via mozilla, not Microsoft. The same can be done on Fedora, if you really wanted to you could go get the new firefox from Mozilla (or somebody else who builds a more Fedora suitable version for you). - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyZQlcACgkQ4v2HLvE71NVvnACgmXQHpE/VAN9fEu2uqsvShmlu tP0AoJRSFDlmK8dg5tzVqDTsXz4Kv1tp =us5B -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, Sep 21, 2010 at 7:40 PM, Jesse Keating jkeat...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/21/2010 07:20 AM, Brandon Lozza wrote: One thing I wanted to point out. Windows users get to install the latest Firefox, KDE, and other apps without having to wait for a new Windows release. If users had to wait for Windows 8 to get the latest Firefox, things would be messy. I don't understand what the fear is of doing this on GNU/Linux. However, if for example Microsoft had a similar system and did package software for it. Their users would be up in arms for the latest firefox too and Microsoft wouldn't keep them on an old firefox version. Where is the logic in NOT having the latest software as long as it doesn't break file format compatibility? On windows the user can also install software without having to follow a complex procedure. They can try to grab the firefox source code, manually compile it in a few hours and install it. They can also grab a precompiled binary that may or may not be optimized for their distribution. On Windows its just double click, and on Linux with package management its only a few clicks away too. Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If you want something better than stable for KDE you can one click install the factory KDE repo. You can one click install the trunk repo too. They even have two Chromium branches available for single click install (version 6 and 7). Perhaps a single click or easy method of installing a yum repo could be invented that is similar to the one in openSUSE. That would be a good start. I would personally rather use Fedora and not openSUSE too. Before I receive the cop out one liner 'just use suse then'. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
If someone has enough interest in backporting something from a newer release, we can set up a personal repo on the repos.fedorapeople.org. Just like firefox4 and yum-rawhide repo. Maybe we wait for Copr. Seth Vidal is working on it. We can easily set up and manage a backport or testing repo on Copr. But I have another question. As we know, Fedora is a fast-upgrade Linux distribution. Many new features will be added in every release. If we backport the most desirable features, how should we attract users to upgrade to the latest one? Do we hope that Fedora becomes a rolling upgrade distribution? On Tue, Sep 21, 2010 at 11:22 PM, Bruno Wolff III br...@wolff.to wrote: On Tue, Sep 21, 2010 at 10:59:06 -0400, Brandon Lozza bran...@pwnage.ca wrote: However, if for example Microsoft had a similar system and did package software for it. Their users would be up in arms for the latest firefox too and Microsoft wouldn't keep them on an old firefox version. Where is the logic in NOT having the latest software as long as it doesn't break file format compatibility? On windows the user can Unexpectedly changing the UI is also bad. Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If you want something better than stable for KDE you can one click install the factory KDE repo. You can one click install the trunk repo too. They even have two Chromium branches available for single click install (version 6 and 7). Perhaps a single click or easy method of installing a yum repo could be invented that is similar to the one in openSUSE. That would be a good start. Alternate repos are possible, but take work. Fedora doesn't have spare capacity to be doing this sort of thing right now. If you want to make it happen, you can by leading and working on a project to do that. As long as you are willing to work and can get a at least a few like minded volunteers also willing to work you should have at least some success. People here aren't against having a way to install alternate versions of packagers per se, but are noting that there is a significant amount of work needed. And many of us think there are better ways to be spending our limited time helping Fedora. But if it is a high priority for other people willing to do the work, it's something that could be done. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Fedora Debian User, former Ubuntu User My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager Ambassador https://fedoraproject.org/wiki/User:Liangsuilong -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 21 Sep 2010 10:20:05 -0400, you wrote: One thing I wanted to point out. Windows users get to install the latest Firefox, KDE, and other apps without having to wait for a new Windows release. If users had to wait for Windows 8 to get the latest Firefox, things would be messy. I don't understand what the fear is of doing this on GNU/Linux. The key point of your example is that they have to actually make the effort to go to the appropriate website (or store to buy a physical disc), and specifically install what they want. It doesn't magically appear when they allow Windows to do an update. You can do the same thing on Fedora, you can if you so wish go to the mozilla website and download the latest Firefox. The problem facing Fedora, and Linux in general, is the distributions blur the difference between the OS and apps by providing both. But unless you want to encourage users to not apply security updates or bug fixes you can't combine doing updates with upgrades. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 21 Sep 2010 10:59:06 -0400, you wrote: However, if for example Microsoft had a similar system and did package software for it. Their users would be up in arms for the latest firefox too and Microsoft wouldn't keep them on an old firefox version. You are ignoring the troubles Microsoft has had in trying to get its users to update IE. Where is the logic in NOT having the latest software as long as it doesn't break file format compatibility? On windows the user can I think it wonderful that you always want the latest software, but just ask that you consider the view of other people who are trying to get their job done. Many of the people using Fedora are using it as a tool to get their normal work done. While file format compatibility is one issue, anything that disrupts their ability to get their job done should be avoided mid-release. This can be a changing in the GUI layout, the ability of plugins to work, or a new version having more bugs. Look at openSUSE, GCC 4.5, came out before F13, no banning of LTO. If The decision on gcc would have to have been made around January, to allow time for any bugs to be worked out both in gcc and in any software included in Fedora 13. I would assume that the gcc maintainers felt it wasn't ready at that time, plus most of the useful stuff had already been backported by them into the Fedora version of gcc 4.4. As far as LTO, the Fedora gcc maintainers have decided that it is not yet stable and ready to be used. The fact that you don't believe the issues with LTO are important, or that openSUSE doesn't, isn't relevant to Fedora. What is relevant is that the Fedora expert(s) on gcc have decided that it isn't ready for use yet. you want something better than stable for KDE you can one click install the factory KDE repo. You can one click install the trunk repo too. They even have two Chromium branches available for single click install (version 6 and 7). Perhaps a single click or easy method of installing a yum repo could be invented that is similar to the one in openSUSE. That would be a good start. Like anything else, if it is important to you then you can work on implementing it. Fedora is limited in what can be done by what the volunteers doing the work actually do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, Sep 21, 2010 at 15:45, Gerald Henriksen ghenr...@gmail.com wrote: you want something better than stable for KDE you can one click install the factory KDE repo. You can one click install the trunk repo too. They even have two Chromium branches available for single click install (version 6 and 7). Perhaps a single click or easy method of installing a yum repo could be invented that is similar to the one in openSUSE. That would be a good start. Like anything else, if it is important to you then you can work on implementing it. Fedora is limited in what can be done by what the volunteers doing the work actually do. I think that is a key element here that people should remember: When someone says I want X it can sound a lot like You must do X which always sounds like make-work and demanding another volunteer to do something. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 2010-09-21 at 10:59 -0400, Brandon Lozza wrote: On Tue, Sep 21, 2010 at 7:40 PM, Jesse Keating jkeat...@redhat.com wrote: On 09/21/2010 07:20 AM, Brandon Lozza wrote: One thing I wanted to point out. Windows users get to install the latest Firefox, KDE, and other apps without having to wait for a new Windows release. If users had to wait for Windows 8 to get the latest Firefox, things would be messy. I don't understand what the fear is of doing this on GNU/Linux. In my personal opinion, Windows makes mistakes, but is more enlightened when it comes to embracing users installing stuff they did not get from Microsoft. On non-enterprise Linux systems, the libraries and userland change so often you really do need to either have a third party building for every release, or getting it in the distro (which isn't always practical or possible). I'm sure I'll be told how wrong I am. However, if for example Microsoft had a similar system and did package software for it. Their users would be up in arms for the latest firefox too and Microsoft wouldn't keep them on an old firefox version. Where is the logic in NOT having the latest software as long as it doesn't break file format compatibility? You know what's kinda cool about some other Operating Systems? (Linux, non-Linux, etc.) You install them, then they always work the same way until you decide to upgrade them one day (when you set aside time to fix all the this shouldn't be a problem, but oh yea, there's that corner case that... issues). All the bugs are consistent, if you plug in a gizmo it works or doesn't, but there are few random surprises. I love lack of random surprises. It's not just file formats and the innards. I'd rather see either a backports repo with all the junk, or just no junk and only have new stuff land in the next release. That changes nothing about Fedora releases, other than adding predictability. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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. I'm not a huge fan of huge updates in stable Firefox3-Firefox4, Kde4.5-Kde4.6 etc. In fact I would prefer to avoid them. But sometimes people want this latest and greatest, shiny :) Setting up official backport repo will avoid repos fragmentation. Keeping all cool updates in one place appears to be a reasonable idea. Am I right? Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
2010/9/20 Michał Piotrowski mkkp...@gmail.com: Setting up official backport repo will avoid repos fragmentation. Another repository/branch inside Fedora infrastructure does not automatically avoid the any of the potential problems that you would want to lump into repo fragmentation. You'd have to take great care in crafting packing policy to prevent any repository interaction problems concerning dependency chains, conflicts,obsoletes, parallel installation, upgrade paths, etc. Keeping all cool updates in one place appears to be a reasonable idea. Define cool. Does this mean that uncool updates would be excluded as a matter of policy? I'm not sure we all live in a world where a PostgreSQL 9 backport is _cool_. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
2010/9/21 Jeff Spaleta jspal...@gmail.com: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: Setting up official backport repo will avoid repos fragmentation. Another repository/branch inside Fedora infrastructure does not automatically avoid the any of the potential problems that you would want to lump into repo fragmentation. You'd have to take great care in crafting packing policy to prevent any repository interaction problems concerning dependency chains, conflicts,obsoletes, parallel installation, upgrade paths, etc. Keeping all cool updates in one place appears to be a reasonable idea. Define cool. Firefox 4, Postgres 9, Cherokee 2, OpenOffice 4, Duke Nukem Forever Does this mean that uncool updates would be excluded as a matter of policy? Yes. Most users don't care about libfoo 1.6.54 - libfoo 1.7.0 upgrade. I'm not sure we all live in a world where a PostgreSQL 9 backport is _cool_. It's cool if you have strange problems with PgPool -jef Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
2010/9/20 Michał Piotrowski mkkp...@gmail.com: Yes. Most users don't care about libfoo 1.6.54 - libfoo 1.7.0 upgrade. It's cool if you have strange problems with PgPool You understand that what you have just describe is not easily wrapped into a self-consistent policy right? There are undoubtably strange problems one one sort of another which impact niche users across the existing packagescape and backports to address their problems would not meet any reasonable definition that relied on the anticipated desires of most users. Every conceivable possible update will most likely solve a problem for someone. You haven't really sketched out a policy by which any reasonable person or persons could judge suitability of a particular potential update and exclude it from such a backports repository. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Mon, 2010-09-20 at 16:31 -0800, Jeff Spaleta wrote: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: Yes. Most users don't care about libfoo 1.6.54 - libfoo 1.7.0 upgrade. It's cool if you have strange problems with PgPool You understand that what you have just describe is not easily wrapped into a self-consistent policy right? There are undoubtably strange problems one one sort of another which impact niche users across the existing packagescape and backports to address their problems would not meet any reasonable definition that relied on the anticipated desires of most users. Every conceivable possible update will most likely solve a problem for someone. You haven't really sketched out a policy by which any reasonable person or persons could judge suitability of a particular potential update and exclude it from such a backports repository. The Mandriva policy is a reasonable starting point: http://wiki.mandriva.com/en/Policies/SoftwareMedia#Backports_policy it's sketchy and not greatly written, but the basic idea is that backports should only be 'leaf' packages (things on which nothing else depends) and libs required _only_ by the packages that are being backported. Packages on which other, unrelated packages depend shouldn't be backported. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
2010/9/20 Michał Piotrowski mkkp...@gmail.com: 2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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? -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, Sep 21, 2010 at 01:51:03 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Setting up official backport repo will avoid repos fragmentation. Keeping all cool updates in one place appears to be a reasonable idea. Am I right? If we had infinite manpower this might be doable on request. As things are, the people that want to do this need to volunteer to do work to make it happen. A good start would be setting up external repos and try to maintain some group of rawhide packages for the in support releases. If this was succesful, I expect getting Fedora infrastructure to make it more official would be possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Mon, Sep 20, 2010 at 10:35:47PM -0500, Bruno Wolff III wrote: On Tue, Sep 21, 2010 at 01:51:03 +0200, Michał Piotrowski mkkp...@gmail.com wrote: Setting up official backport repo will avoid repos fragmentation. Keeping all cool updates in one place appears to be a reasonable idea. Am I right? If we had infinite manpower this might be doable on request. As things are, the people that want to do this need to volunteer to do work to make it happen. A good start would be setting up external repos and try to maintain some group of rawhide packages for the in support releases. If this was succesful, I expect getting Fedora infrastructure to make it more official would be possible. Yeah, I'd leverage this: https://fedoraproject.org/wiki/Fedorapeople_Repos set up a repo; use fs acls to let a group of people manage it together. See how it goes. -Toshio pgpp2i3mHXYp4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Mon, 2010-09-20 at 21:58 -0400, Arthur Pemberton wrote: 2010/9/20 Michał Piotrowski mkkp...@gmail.com: 2010/9/21 Toshio Kuratomi a.bad...@gmail.com: 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? That they sometimes horribly break, change behavior (in any way), or otherwise affect the smooth consistency of using a system and upgrading daily, without actively discouraging upgrades for fear of breakage (which is what Fedora has been doing for me, as an example). The fear is also that people are not comprehending the difference between a released Operating System Platform and a random collection of moving targets. Are there many desktop users who do NOT want the latest released Firefox? Yup. I don't want it. I don't care about it and I'm uninterested in having the latest version. I'd like the version I have currently installed to get security fixes, but I don't want Firefox 4 on my desktop system right now. I'll leave it on my development box running rawhide and poke at it for testing, but I *DO NOT* want it released. Are there many people using Fedora as their OS for their database server? If you mean does postgres matter, I've got an old non-Fedora box I'd love to replace with Fedora, and it runs MySQL (amongst other things). I can't replace it (using either database) until such time as Fedora has a decent update policy though. So saying nobody uses Fedora on the server is a sure fire way of perpetuating that sad reality. I also care far more about server bits than I care about Firefox or my desktop in general. I want a web browser, but I'll take any web browser that works reasonably well enough. Similarly, I want a GUI of some kind, but I don't care if it's enlightenment 0.17 if need be so long as it doesn't ever change from one day to the next. I love the backports repo idea. Ubuntu has been doing this for ages with their LTS releases, and it's a nice way to pull in stuff like a more recent spamassassin without having to upgrade the rest of the operating system, or change what works out of the box in the default install path. So +1 to the idea in Fedora. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Mon, 20 Sep 2010 21:58:53 -0400, you wrote: 2010/9/20 Micha? Piotrowski mkkp...@gmail.com: 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? What if you are using a Firefox extension that hasn't been ported to the latest release yet? What if you have decided that Fedora is an easier path to a server rather than attempting to backport a lot of packages because the current release of RHEL/CentOS is 3 years old and doesn't have what you need in term of framework or language? What if you are a college that has deployed Fedora to use for your students coursework, and an upgrade to a language/database/etc breaks things mid-semester? Fedora is used in a lot of different ways. Gerald -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, Sep 21, 2010 at 12:29 AM, Gerald Henriksen ghenr...@gmail.com wrote: On Mon, 20 Sep 2010 21:58:53 -0400, you wrote: 2010/9/20 Micha? Piotrowski mkkp...@gmail.com: 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? What if you are using a Firefox extension that hasn't been ported to the latest release yet? You don't update Firefox till the extension comes out. What if you have decided that Fedora is an easier path to a server rather than attempting to backport a lot of packages because the current release of RHEL/CentOS is 3 years old and doesn't have what you need in term of framework or language? The same thing suggested here for new packages. What if you are a college that has deployed Fedora to use for your students coursework, and an upgrade to a language/database/etc breaks things mid-semester? You test updates before you deploy them. Fedora is used in a lot of different ways. Sure, but I thought Fedora was all about pushing new, free software. -- Fedora 13 (www.pembo13.com) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
On Tue, 2010-09-21 at 00:29 -0400, Gerald Henriksen wrote: On Mon, 20 Sep 2010 21:58:53 -0400, you wrote: 2010/9/20 Micha? Piotrowski mkkp...@gmail.com: 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? What if you are using a Firefox extension that hasn't been ported to the latest release yet? What if you have decided that Fedora is an easier path to a server rather than attempting to backport a lot of packages because the current release of RHEL/CentOS is 3 years old and doesn't have what you need in term of framework or language? What if you are a college that has deployed Fedora to use for your students coursework, and an upgrade to a language/database/etc breaks things mid-semester? Also... What if you have a life outside computing and would like to run Fedora at home but don't want to fix breakage on the weekend (because that ceased to be fun after ten years, and once college was over with)? Fedora is used in a lot of different ways. Yes, it is, and it should be. Fixing updates is the number one problem, right behind having a long term strategy. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora backports repo? (Was Re: PostgreSQL 9 for F14?)
I apologize for interrupting this tread. I shall take my leave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
