Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Kevin Kofler wrote: as long as you require only a few 32-bit packages, requesting them explicitly is not the end of the world. So if we were to drop support for that always install all libs as multilibs option Eh? I didn't even know there was such an option. And I agree, /that/ should be dropped. and require explicitly picking the wanted 32-bit stuff from the 32-bit repo, that shouldn't be a real issue for you. As long as I can still install libs to build i*86 on my mostly-x86_64 system, without yum getting confused and broken, then I'm okay. My concern is really just the yum getting confused and broken part. (I would prefer to not have to jump through hoops to get i*86 stuff, though, i.e. having to manually set up a repo would make me unhappy.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Oops. -- Shannon Foraker (David Weber, Ashes of Victory) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
On Thu, 11 Mar 2010, Matthew Woehlke wrote: Kevin Kofler wrote: as long as you require only a few 32-bit packages, requesting them explicitly is not the end of the world. So if we were to drop support for that always install all libs as multilibs option Eh? I didn't even know there was such an option. And I agree, /that/ should be dropped. man yum.conf; /multilib_policy it is set to best in fedora. and require explicitly picking the wanted 32-bit stuff from the 32-bit repo, that shouldn't be a real issue for you. As long as I can still install libs to build i*86 on my mostly-x86_64 system, without yum getting confused and broken, then I'm okay. My concern is really just the yum getting confused and broken part. (I would prefer to not have to jump through hoops to get i*86 stuff, though, i.e. having to manually set up a repo would make me unhappy.) the issue is not yum getting confused but really there being some interesting conflicting files.. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Kevin Kofler wrote: Matthew Woehlke wrote: You forget people developing proprietary software... Why would we want to encourage or even support that? I don't expect Fedora to encourage it (nor should we, IMO)... but that doesn't change the reality of $DAYJOB. If Fedora drops multilib, I will be forced to drop Fedora. Not out of spite, but because it will no longer be able to do my job. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- . . . . . #...@no CARRIER -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Matthew Woehlke wrote: Kevin Kofler wrote: Matthew Woehlke wrote: You forget people developing proprietary software... Why would we want to encourage or even support that? I don't expect Fedora to encourage it (nor should we, IMO)... but that doesn't change the reality of $DAYJOB. If Fedora drops multilib, I will be forced to drop Fedora. Not out of spite, but because it will no longer be able to do my job. Meh. Should read ...because it will no longer be possible for me to do my job with Fedora. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- . . . . . #...@no CARRIER -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Michael Schwendt wrote: On Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote: There are just too many -devel packages and their dependencies to be ever relevant to someone for multi-arch installs. Far more users install i686 on 64-bit CPUs, and I have doubts that x86_64 installation users do much development with i686 packages. At most they install 32-bit apps where 64-bit builds aren't available or less good. You forget people developing proprietary software... Why would development of proprietary software have different requirements with regard to multilib installations? ...because said developers are more likely to be developing i686 packages on x86_64. Mostly, I disagree with your ratio of people who need multilib versus people for whom multilib causes problems differently. Probably because I need multilib and have never experienced multilib-related problems (or if I have, they were so trivial as to be thoroughly forgettable). Multilib is useful if you want to build the 32-bit version of something on an x86_64 box (and don't want to set up a full chroot / VM). The don't want to is questionable. Development of the 32-bit version would still need a full 32-bit test installation. A test installation of /what you built/, yes. And you have that, since you just built it. (From that, I guess that you consider testing of a 32-bit program invalid unless done on a pure 32-bit kernel? I sure don't.) It need not be the x86_64 box to do full multi-booting instead of VM, but even multi-booting would be convenient enough, considering how quickly something like Fedora can be installed. Typical development is not trial-and-error compilation of both 64-bit and 32-bit and alternating, but rather development on either arch till something is ready to be built for and to be tested on a different arch. You obviously have a different definition of typical than I do. For $DAYJOB we build both 32- and 64-bit at the same time and test both within the same test suite. That's my typical. Given that Windows (go figure) is the only platform for which we consider 32- versus 64-bit to be different ports, that's not likely to change. Multi-booting is not only inconvenient, it isn't an option. Multilib *is* the method we use to build and test. End of story. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Sorry, fresh out of .sigs. Maybe tomorrow. (paraphrased German saying) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Michael Schwendt wrote: On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote: Probably because I need multilib and have never experienced multilib-related problems (or if I have, they were so trivial as to be thoroughly forgettable). Just out of interest, does enabling a separate 32-bit repository on a 64-bit installation lead to more/severe problems than using a multiarch repo? I haven't tried it, but it at least introduces the question 'what coreutils/X/KDE do you want?'. Of course, I'd say that if that works decently, you're still providing functional multilib. So I don't really care about how it happens under the hood, as long as it works. (From that, I guess that you consider testing of a 32-bit program invalid unless done on a pure 32-bit kernel? No. I think it depends on what sort of program would be tested. A 32-bit multlib development environment on a 64-bit installation does not add a full 32-bit run-time environment. Hmm, maybe then you are thinking of things that are far less stand-alone. The only run-time environment we care about is that the program can be executed (so, kernel can load it, glibc.i?86 exists, etc.). We tend to have very few if any dependencies beyond libc (and even then, beyond libc/libm/libpthread, we usually provide our own). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- . . . . . #...@no CARRIER -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Matthew Woehlke wrote: Hmm, maybe then you are thinking of things that are far less stand-alone. The only run-time environment we care about is that the program can be executed (so, kernel can load it, glibc.i?86 exists, etc.). We tend to have very few if any dependencies beyond libc (and even then, beyond libc/libm/libpthread, we usually provide our own). Then all you really need is: * the 32-bit repository enabled, * yum.conf set up not to install matching i686 packages for all x86_64 packages (which would cause file conflicts when using the full 32-bit repository), but only those explicitly requested or required by dependencies (This has now been the default for several Fedora releases anyway.), * yum install glibc.i686. You don't actually need multilibbed x86_64 repositories. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
I wrote: * yum install glibc.i686. Actually, you probably want glibc-devel.i686. But my point still stands, as long as you require only a few 32-bit packages, requesting them explicitly is not the end of the world. So if we were to drop support for that always install all libs as multilibs option and require explicitly picking the wanted 32-bit stuff from the 32-bit repo, that shouldn't be a real issue for you. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Matthew Woehlke wrote: You forget people developing proprietary software... Why would we want to encourage or even support that? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Michael Schwendt wrote: There are just too many -devel packages and their dependencies to be ever relevant to someone for multi-arch installs. Far more users install i686 on 64-bit CPUs, and I have doubts that x86_64 installation users do much development with i686 packages. At most they install 32-bit apps where 64-bit builds aren't available or less good. You forget people developing proprietary software... or even just multilib apps. Multilib is useful if you want to build the 32-bit version of something on an x86_64 box (and don't want to set up a full chroot / VM). (Doubly so for proprietary stuff that may need to build both 32- and 64-bit in the same build tree.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Lions and tigers and HIPPOS! Everyone needs a hippo! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Mar 5, 2010 at 2:11 AM, James Antill ja...@fedoraproject.org wrote: On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote: On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote: Extras had significantly fewer packages, Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html *sigh*, I almost managed to not respond to any of these threads today. Anyway (trying to say just the facts): % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates 9,390 repolist: 9,390 ...and it's only ~65% done. That also doesn't take into account the fact that we've released ~17k F11 updates, which I'm pretty sure didn't happen for F6 extras. I wouldn't count new packages as updates, because that are _added_ packages not _updated_ ones. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Thu, 04 Mar 2010 20:11:47 -0500, James wrote: On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote: On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote: Extras had significantly fewer packages, Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html *sigh* No need to do that. I almost managed to not respond to any of these threads today. Anyway (trying to say just the facts): % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates9,390 repolist: 9,390 So what? That's not twice as much as FE6, which would not have taken several hours to push into such a repo. Not even when running repoclosure on the needsign repo prior to pushing and when updating repoview pages afterwards. Simply because the code that was used worked very differently than mash. ...and it's only ~65% done. That also doesn't take into account the fact that we've released ~17k F11 updates, which I'm pretty sure didn't happen for F6 extras. What are you trying to point out? Not everything is better or more convenient with the current push/compose infrastructure. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, 05 Mar 2010 02:41:46 -0500, James wrote: % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates9,390 ... This probably won't go well unless you two are talking about the right terms. I believe that Michael was talking srpm numbers, where you appear to be talking binary numbers. The Michael gave was for binary packages in FC 6 x86_64 extras: % GET http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/ | \ fgrep '.rpm' | \ wc -l 5129 ...maybe he thought that was srpms though. No, I compared that number to those displayed in bodhi, assuming they would be the updates count instead of the tickets count. What is being displayed in bodhi is inconsistent and misleading, as it says 3 pending for EPEL 4 in one place, but 7 pending in another place. I just didn't want to compare with F12 updates, which has a much lower package count than FE6. Or F13, which is one arch less than FE6. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
(Starting a new thread because this hardly has anything to do with the original infamous thread. Dear hall monitors: I hope I won't get put on moderation for posting this, but this subthread didn't have much to do with the original subject. If you also want me to stop posting to this split thread, please tell me and I will refrain from posting further replies to it. Thanks for your understanding and I apologize if I'm offending anybody by replying.) Michael Schwendt wrote: So what? That's not twice as much as FE6, which would not have taken several hours to push into such a repo. Not even when running repoclosure on the needsign repo prior to pushing and when updating repoview pages afterwards. Simply because the code that was used worked very differently than mash. Yeah, basically mash is a really brute force solution, I think directly writing out only the new updates as the first prototypes of Bodhi did and as the Extras scripts also did/do is a much smarter solution. Always recomputing everything sucks. It was claimed that recomputing is necessary for some obscure multilib corner cases. Let me suggest a radical solution for that: drop multilib repos! If users really want 32-bit packages, they should enable the 32-bit repo. Yes, this will cause file conflicts if you configure yum to always drag in both versions by default (exactarch=0). So don't do that. Maybe even remove that feature from yum altogether. Yum already knows how to fetch those 32-bit libs that are actually needed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
On Fri, 05 Mar 2010 11:03:12 +0100, Kevin wrote: Yeah, basically mash is a really brute force solution, I think directly writing out only the new updates as the first prototypes of Bodhi did and as the Extras scripts also did/do is a much smarter solution. Always recomputing everything sucks. It can be beneficial. Also the tagging in koji adds possibilities that are nice. Such as optional reconstruction of repositories with builds stored elsewhere. However, if there are resource constraints, such as slow NFS access to the packages and repos, rebuilding less sounds more appropriate. It was claimed that recomputing is necessary for some obscure multilib corner cases. What might those be? I could imagine obsolete multilib packages. They have been pulled in previously and later become unnecessary for an update and its changed dep-chain. Old RepoPrune kills them whenever the src.rpm is updated for the primary arch (= old multilib pkgs would refer to a src.rpm that isn't the newest one = prune those). And recomputing the full multilib dep-chain on demand could still be possible. Deleting packages, which have been published before, is dangerous, though. Users may have installed those packages (even if just as automatic dependencies). Let me suggest a radical solution for that: drop multilib repos! Or return to white-listing only a small selection of packages. There are just too many -devel packages and their dependencies to be ever relevant to someone for multi-arch installs. Far more users install i686 on 64-bit CPUs, and I have doubts that x86_64 installation users do much development with i686 packages. At most they install 32-bit apps where 64-bit builds aren't available or less good. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Kevin Kofler (kevin.kof...@chello.at) said: So what? That's not twice as much as FE6, which would not have taken several hours to push into such a repo. Not even when running repoclosure on the needsign repo prior to pushing and when updating repoview pages afterwards. Simply because the code that was used worked very differently than mash. Yeah, basically mash is a really brute force solution, I think directly writing out only the new updates as the first prototypes of Bodhi did and as the Extras scripts also did/do is a much smarter solution. Always recomputing everything sucks. The issue there is then you have to properly determine what packages to remove from the repo (unless you just keep everything, which has its own problems); in this case, recomputing actually makes the code simpler. It was claimed that recomputing is necessary for some obscure multilib corner cases. Let me suggest a radical solution for that: drop multilib repos! While that would make things simpler and shorter, I doubt it's really practical. Enough people use and want multilib that I don't think we can just unilaterally remove it. Moreover, the multilib portion of the compose isn't the primary time eater. I certianly don't want to go back to the whitelist case where every time someone needed a new multilib package we had to update a static whitelist in the update push tool. That's just silly. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Bill Nottingham wrote: The issue there is then you have to properly determine what packages to remove from the repo (unless you just keep everything, which has its own problems); in this case, recomputing actually makes the code simpler. Sure, it makes the code simpler, but a lot slower! Often, performance optimizations require more complex code. While that would make things simpler and shorter, I doubt it's really practical. Enough people use and want multilib that I don't think we can just unilaterally remove it. Moreover, the multilib portion of the compose isn't the primary time eater. I certianly don't want to go back to the whitelist case where every time someone needed a new multilib package we had to update a static whitelist in the update push tool. That's just silly. Why can't we just tell them to add the 32-bit repo to their configuration? Possibly even ship fedora-32bit and fedora-updates-32bit configs (disabled by default)? With the exactarch=1 setting (the current default), this shouldn't be a big problem. The only problem I see is that people would run into file conflicts if they use exactarch=0 or yum install someapplication.i686, but it's easy to close those as NOTABUG (sorry, multilib is not supported for this package, just use the 64-bit version). If those reports become a big problem, isa-based Conflicts tags could be added. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Push scripts, mash (was: Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback))
Bill Nottingham wrote: Off the top of my head, it would break the install DVD usage case The install DVD wouldn't have 32-bit baggage. So what? It's not installed by default anyway. (At least the live images don't contain ANY multilib stuff. I'm not sure what the DVD does these days.) and the wine usage case. They'd just have to enable the 32bit repos and install wine.i686. (And W64 binaries would even work with the default wine, but I realize those are not the common case.) It would also make multilib_policy as a configuration option meaningless, as you couldn't ever set it to anything other than 'best' and expect it to work. So drop that option. I never understood the point of installing 32-bit versions of EVERYTHING as opposed to just the 32-bit stuff that's actually needed anyway. And in this case removing the option would actually allow us to improve things (less duplication in the repos, smaller metadata for those of us with pure 64-bit systems etc.), unlike some gratuitously removed options in e.g. GNOME. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote: Extras had significantly fewer packages, Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html no multilib, Just want to correct you here as no multilib isn't true. It implemented a whitelist, a blacklist and a multiarch depsolver, but it was decided to turn on full *-devel multiarch pushing no earlier than during Fedora 7 development. Previously (up to and including Fedora Extras 6), only some packages (like wine) were pulled in via the whitelist. no deltarpms, no update metadata, These two features predate the Fedora Extras era. The post-Fedora Extras pushscripts have been enhanced to create deltarpms ( http://download1.rpmfusion.org/free/fedora/updates/11/i386/drpms/ ) including basic repo inheritance. fewer arches i386, x86_64 and ppc and was ran on different hardware. It's an apples vs. oranges comparison anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote: On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote: Extras had significantly fewer packages, Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html *sigh*, I almost managed to not respond to any of these threads today. Anyway (trying to say just the facts): % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates9,390 repolist: 9,390 ...and it's only ~65% done. That also doesn't take into account the fact that we've released ~17k F11 updates, which I'm pretty sure didn't happen for F6 extras. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote: On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote: On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote: Extras had significantly fewer packages, Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html *sigh*, I almost managed to not respond to any of these threads today. Anyway (trying to say just the facts): % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates9,390 repolist: 9,390 ...and it's only ~65% done. That also doesn't take into account the fact that we've released ~17k F11 updates, which I'm pretty sure didn't happen for F6 extras. This probably won't go well unless you two are talking about the right terms. I believe that Michael was talking srpm numbers, where you appear to be talking binary numbers. Those are obviously not going to match up. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Thu, 2010-03-04 at 18:30 -0800, Jesse Keating wrote: On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote: On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote: Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less than F11 stable updates. http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html % yum repolist --releasever=11 updates repo id repo name status updates Fedora 11 - x86_64 - Updates9,390 ... This probably won't go well unless you two are talking about the right terms. I believe that Michael was talking srpm numbers, where you appear to be talking binary numbers. The Michael gave was for binary packages in FC 6 x86_64 extras: % GET http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/ | \ fgrep '.rpm' | \ wc -l 5129 ...maybe he thought that was srpms though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 02 Mar 2010 17:53:40 -0800, Jesse wrote: On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote: Jesse Keating wrote: That's a fair point, but there are significantly fewer people around to fix critical issues should they arise on a weekend, and after working 5 weekdays, some of us like taking the weekend off. Well, I'm around on the weekends and the lack of update pushes for the whole weekend has irked me more than once. My intention is not to force you or Josh Boyer to work on weekends, but maybe we can find a new volunteer to do weekend pushes (and only weekend pushes, so they wouldn't be doing Fedora work the full week)? And ideally, update pushes should eventually be automatic, just like the Rawhide composes. Kevin Kofler Except there aren't enough key people available on the weekend to clean up the crap if something goes wrong. What sort of crap? And what precautions could be added to avoid producing such crap that requires someone to clean it up (manually)? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Le Mer 3 mars 2010 05:49, Kevin Kofler a écrit : Jesse Keating wrote: did a poor job in stating our goals for the operating system, and just hoped that our maintainers would see things the way we saw them. Why should they see them that way rather than the right way? ;-) Please stop claiming the right way. Every Fedora packager does not share your opinion on rolling stable releases, despite all your repeated claims. If KDE wants to be on an equal footing with GNOME (another of your repeated complains) it needs to learn synchronizing with distro releases like GNOME (and kernel, and xorg did). You're distorting the Fedora model to accommodate KDE roadmaps. Granted, KDE is not something I'd want badly supported in Fedora, but this is reaching ridiculous levels. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, Mar 01, 2010 at 01:46:20PM -0500, Seth Vidal wrote: On Mon, 1 Mar 2010, Till Maas wrote: What kind of tests need to be done always manually? The only ones I can think are tests for the appearance of applications or tests that require specific hardware. But in the general case, I do not think that for every package manual testing will always be required, except while creating new automatic tests. E.g. if you have a library package with good unit test and behaviour test coverage and tests for RPM metadata, what do you want to test manually? I have a series of basic functionality tests that I run before each yum release to make sure that there is nothing unforeseen in an update. I don't think such a set of tests is ridiculous, but I do admit it is complicated. I assume that you have a checklist of tests and run them manually. Is it not possible to run the tests automatically because of there nature? Or is it only because the framework is missing? The advantage of automated tests would be, that together with rpm VCS support (scripts), you could even run after each commit to even faster spot bugs: 1) commit upstream 2) build new rpm 3) apply AutoQA to the rpm Regards Till pgpmqAMLwuH6n.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, Mar 03, 2010 at 12:33:40AM -0500, James Antill wrote: You keep saying that 7 days is enough but I haven't seen you provide _any_ evidence to support it. Noting that it will often take 3-4 days before a package in testing can be seen by all users. So maybe you are So there is an easy way to get around 25% (two week stay in testing) to 50% (one week stay in testing) more time to test packages without negative impact: make them faster available to the users. Regards Till pgp7EJcFZLn9K.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/03/2010 08:38 AM, Kevin Kofler wrote: So maybe you are under the impression that all the users who would test your package are anxiously waiting for your packages to be available? For those packages where regressions actually matter to people, they definitely are. People keep asking us: when will KDE x.y.z finally be available? They ask it even before upstream officially announces the release! Thanks for the concern, Kevin. When will KDE 4.4.2 be available? I've skipped all updates on my mother's computer since you pushed 4.4.0 to updates-stable. With 4.4.2 I might finally consider applying updates again. P.S. If you didn't notice the sarcasm, then I'm not supporting major updates in the so-called stable branches. Such updates are probably fun for people who want to have shiny toys to play with, but some people want to get work done. Using Fedora. List Troll -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
2010/3/3 Josh Boyer jwbo...@gmail.com: On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote: On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote: We've made a mess and as a member of fesco I'd expect you to be helping in cleaning up the mess, not making it worse b/c fesco HAS to be about the long term growth and sustainability of fedora. I'm starting to think this thread needs a hall monitor. Unfortunately half of them seem to be in it, swinging away. Why? Other than one instance, which was my own, there hasn't been anything in this thread that I would consider hall monitor worthy. Wording starts to get near to unacceptable imho. People not sharing the view that there are to many updates to so-called stable releases (a 'fire-hose' of a 'horrendous' and 'insane' amount of updates) are denoted not being normal. - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, Mar 03, 2010 at 10:54:57AM +0100, Michael Schwendt wrote: On Tue, 02 Mar 2010 17:53:40 -0800, Jesse wrote: On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote: Jesse Keating wrote: That's a fair point, but there are significantly fewer people around to fix critical issues should they arise on a weekend, and after working 5 weekdays, some of us like taking the weekend off. Well, I'm around on the weekends and the lack of update pushes for the whole weekend has irked me more than once. My intention is not to force you or Josh Boyer to work on weekends, but maybe we can find a new volunteer to do weekend pushes (and only weekend pushes, so they wouldn't be doing Fedora work the full week)? And ideally, update pushes should eventually be automatic, just like the Rawhide composes. Kevin Kofler Except there aren't enough key people available on the weekend to clean up the crap if something goes wrong. What sort of crap? And what precautions could be added to avoid producing such crap that requires someone to clean it up (manually)? 1) Packages need to be signed. To do this, you need access to the signing keys. This is a rather large hurdle to get over, but we're trying to make sure that sigul lowers it a bit. It's not quite ready for more use yet, as we're currently hitting issues with it crashing under load. This will be looked at soon. The end goal is probably to have koji sign the RPMs right after build and just use a single build gpg-key to sign everything. However I'm not sure how close we are to that. 2) Bodhi failures. These come in a variety of flavors. The most common is that it goes to mash an updates-testing repo and koji has nicely pruned the signed copies of the RPMs and mash can't download them. Fixing requires koji admin access, again not something given out lightly. We are taking some precautions on this by essentially re-writing the signed copies for anything left in the various f1x-updates-testing tags on a daily basis. That works well enough for us to actually get about a push-per day done, but it certainly has races. Other failures of the more bizarre nature happen as well, such as koji tag moves failing, or bodhi getting turned off in the middle of a push, or people editing updates mid-push and bodhi freaking out about that. These are more rare, but do happen and often require lots of head scratching and admin-level access to fix. At times, a new bodhi needs to be rolled out to fix it and only one person can do that right now. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 3 Mar 2010, Thomas Moschny wrote: 2010/3/3 Josh Boyer jwbo...@gmail.com: On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote: On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote: We've made a mess and as a member of fesco I'd expect you to be helping in cleaning up the mess, not making it worse b/c fesco HAS to be about the long term growth and sustainability of fedora. I'm starting to think this thread needs a hall monitor. Unfortunately half of them seem to be in it, swinging away. Why? Other than one instance, which was my own, there hasn't been anything in this thread that I would consider hall monitor worthy. Wording starts to get near to unacceptable imho. People not sharing the view that there are to many updates to so-called stable releases (a 'fire-hose' of a 'horrendous' and 'insane' amount of updates) are denoted not being normal. I think we've always referred to the stream of updates as 'the fire-hose'. It's an expression from a movie called UHF. A character in the movie says You win the prize you get to drink from mr. firehose! Then proceeds to spray a firehose at a child who is excited to drink from the firehose. in the context it is really funny. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 07:52 +0100, Kevin Kofler wrote: James Antill wrote: This isn't a hard problem, 3.0 should then be marked as a security update. But the case we're discussing is that 3.0 was pushed long before it was known that it happens to fix a security vulnerability. We're not going to arbitrarily push another update and call it security when it doesn't fix any security issue that's not already fixed. I would assume you could just change the updateinfo for the the current update to mark it as security, this is a tiny amount of extra work on the packager side ... but without it all the work to create the security types on updates is worthless. This is just another failure point of yum-security. This would be the _only_ failure point, if in fact it is policy (and isn't going to be fixed). Of course it's such a huge issue I'll have to make the --security option a noop in Fedora if true, no arguments there the option would be worthless. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 23:57 -0800, Adam Williamson wrote: I wasn't suggesting that's what happens in Fedora at present, just that - given a single update stream in which it's perfectly fine for 'security' updates to build on 'feature' updates - it's impossible to cherry pick only security updates. This is Fedora. Security updates can come with new features, that's life. You can have zero updates for a package, and then do a rebase to fix a security problem and also Require: the latest versions of everything else in updates for all I care. The security problem is _fixed_ though, so your system is secure, and that's all that --security guarantees (and it has made minimal updates, it's just that minimal is bigger than with say RHEL/CentOS). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/02/2010 08:42 PM, Kevin Kofler wrote: Peter Jones wrote: On 03/02/2010 06:15 AM, Kevin Kofler wrote: X11 is particularly dangerous for this kind of changes, given how low it is in the software stack and how some code necessarily looks like (hardware drivers in particular are always scary stuff). The average leaf package is much less propice to breakage induced by minimal changes. This is just plain bull. High level packages also have one line fixes that are simple, elegant, and wrong. They are much less likely though. Please provide data to support this bullshit assertion. Changing the bytes which get sent to some piece of hardware you have no or only inaccurate documentation on is much more likely to cause breakage than some of the simple changes which are done at application level, like removing a hardcoded call to setCheckSpellingEnabled(true) to make it default to the system default instead. That isn't data. It isn't even a particularly good anecdote. -- Peter Space, is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. I mean you may think it's a long way down the road to the chemist, but that's just peanuts to space. -- The Hitchhiker's Guide to the Galaxy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 17:09 +0100, Till Maas wrote: On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote: If we had less updates, that changed less things and required more testing before pushing them to users ... this would be entirely possible. Less updates mean more changes per update or you have more buggy packages, because updates usually fix bugs. As I would assume any programmer knows: Not all bugs are created equal. Trading no regressions for some minor bugs still remain is a trade lots of users are happy to make (see: every customer of every piece of commercial software, ever). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: I would assume you could just change the updateinfo for the the current update to mark it as security, this is a tiny amount of extra work on the packager side ... but without it all the work to create the security types on updates is worthless. We can't change Bodhi metadata after the fact at this time. Bodhi admins might be able to do it, but maintainers definitely aren't. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, Mar 3, 2010 at 18:27, Kevin Kofler kevin.kof...@chello.at wrote: James Antill wrote: I would assume you could just change the updateinfo for the the current update to mark it as security, this is a tiny amount of extra work on the packager side ... but without it all the work to create the security types on updates is worthless. We can't change Bodhi metadata after the fact at this time. Bodhi admins might be able to do it, but maintainers definitely aren't. Where's the RFE ticket? -- Mathieu Bridon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote: People who use updates-testing under the current system are signing up to doing testing. Under your proposal, they'd be forced to sign up to get any current updates. Get current updates = so they can be tested! But what if I want already tested (for a reasonable period, like 1-2 weeks, not months!) current updates? I am not alone in that! No, because updates may depend on previous updates to work properly. We can't possibly test or support all possible combinations of updates. We can't _now_ ... because of packagers like you who want to release lots of updates with no or almost no testing! If we had less updates, that changed less things and required more testing before pushing them to users ... this would be entirely possible. No. For n updates, there are 2^n possible combinations, even with critical security updates alone, this would not scale. RHL update announcements used to include this notice: | Before applying this update, make sure all previously released errata | relevant to your system have been applied. IMHO we should add the same disclaimer to Fedora update announcements. The same reasons which were valid back then still are. No, there's suffering because you are breaking their computers with your updates (which has been pointed out to you many times in this thread). Nonsense. The bugs being fixed by new KDE releases are often bugs which have been there all the time, not caused by an update. No, I for one will not be just enabling updates-testing if my proposal is passed. Again, I imagine that the major of users will not do this ... and will be happier to have a smaller number of tested updates. I think you're illuding yourself. Mainly because updates under your proposal would not just be tested, but arbitrarily delayed to penalize frequently- updated packages. That has nothing to do with testing at all. The time required to test an update does NOT depend on previous updates having been issued for the same package! It is only a function of the changes in THAT PARTICULAR update. You are _forcing_ people to use updates-testing because there is nothing else ... things can't be tested by the time they hit updates, so updates is de. facto. updates-testing. This is complete and utter nonsense. Updates ARE being tested in updates- testing. (In fact that's why some people want to ban direct stable pushes, they want to make sure everything gets testing.) And you still don't justify why the second update to a package would need more testing than the first one etc., this makes absolutely no sense to me. They're not testing it, they're receiving it already tested. Except that it breaks ... but of course that's their problem, not yours ... right? What breaks? I think I'm starting to see a pattern here: . Kevin doesn't use DVD updates, so anything that needlessly breaks DVD updates is fine because DVD updates are worthless. Wrong. DVD updates are broken by design. It's impossible to support them in its current state and it's unreasonable to expect Fedora to radically change (we couldn't even do version bumps to fix security issues anymore!) to accomodate this usecase. The proper solution is to fix Anaconda to include the updates repository for upgrades. That I happen not to use this broken feature is entirely irrelevant. . Kevin doesn't use selective updates, so packagers doing less work and not testing for selective updates is fine because selective updates are worthless. Wrong. Selective updates are broken by design. It's impossible to support them because the exponential amount of testing will never be achievable, even if Fedora were to radically minimize its updates. They will always be something that may or may not work and is not recommended. That I happen not to use this broken feature is entirely irrelevant. . Kevin doesn't use --security, so packagers ignoring security issues is fine because --security is worthless. Wrong. --security is broken by design. It's impossible to support it because it is just a special case of selective updates above. There are also other technical issues with it (like upgrades which happen to fix security issues, but this is discovered or announced only after they already got pushed as non-security). That I happen not to use this broken feature is entirely irrelevant. . Kevin doesn't mind restarting KDE after updates, so any users complaining their desktop doesn't work after an update can be ignored. Wrong. KDE upstream requires restarting KDE after upgrading, there is nothing Fedora can do about it, and not pushing any KDE bugfixes just to prevent this minor inconvenience would be a disservice to many more users. For the vast majority of our users, restarting KDE is not a big deal at all (in fact I don't remember having received more than that one single complaint about it, out of thousands of
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Le mercredi 03 mars 2010 à 16:32 +0100, Kevin Kofler a écrit : Nicolas Mailhot wrote: If KDE wants to be on an equal footing with GNOME (another of your repeated complains) it needs to learn synchronizing with distro releases like GNOME (and kernel, and xorg did). I don't see this as being practical at all. Not all distros even release at the same time as Fedora and Ubuntu in the first place. And that does not matter, because you can not synchronize with everyone, so you'd better synchronize with major distros, and other major software packages. You're distorting the Fedora model to accommodate KDE roadmaps. No, this goes far beyond KDE. KDE roadmaps are just one strong argument for doing things this way. Many more packages benefit or would benefit from version upgrades during a release. This is only working for you because KDE is a high-visibility project and can mobilize resources even outside the distro normal schedule. The other packages you talk of could benefit if QA was cheap and plentiful but QA is not cheap and plentiful and pretending we do not have resource constrains and can afford no to forget about planification will not change this fact. I'm sure there are *many* Fedora SIGs that would dearly love to have a tenth of the resources you squander on semi-rolling KDE releases so they can hit their own 6-month target releases (yes the very period you find too short). Every effort you make to destabilize the normal six-month cycle because you can afford to hurts those packagers. -- 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Mathieu Bridon wrote: On Wed, Mar 3, 2010 at 18:27, Kevin Kofler kevin.kof...@chello.at wrote: We can't change Bodhi metadata after the fact at this time. Bodhi admins might be able to do it, but maintainers definitely aren't. Where's the RFE ticket? I've never felt the need. This is the first time somebody brings up a strong legitimate reason why we'd want to. On the other hand, implementing that may lead to people editing metadata for pushed updates for all sorts of reasons, even bad ones. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Nicolas Mailhot wrote: This is only working for you because KDE is a high-visibility project and can mobilize resources even outside the distro normal schedule. The other packages you talk of could benefit if QA was cheap and plentiful but QA is not cheap and plentiful and pretending we do not have resource constrains and can afford no to forget about planification will not change this fact. Those packages which can't drum up as much QA are niche packages where usually you can get away with just pushing whatever you want whenever you want. Extras worked like that all the time, it didn't even have a testing repo at all (!), but it still worked. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Juha Tuomala wrote: On Wed, 3 Mar 2010, Kevin Kofler wrote: You're distorting the Fedora model to accommodate KDE roadmaps. No, this goes far beyond KDE. KDE roadmaps are just one strong argument for doing things this way. Many more packages benefit or would benefit from version upgrades during a release. In my undestanding, KDE makes new feature releases (b releases) and bug fix releases (c releases), where versions are kde-a.b.c. How is that 'one strong argument for doing things this way' in fedora where new features are added into new Fn releases? The strong argument is that KDE and Fedora release cycles are not in sync and our users would thus have to wait months for the new KDE. I talked to rdieter about this and said that part of the problem is that not all of the bug fixes end to bugfix releases and would be thus ommitted from stable fedora releases. Being a pure KDE upstream problem, it should be solved there and would certainly get more focus if fedora would start enforcing it. I doubt it. Other distros are already much more conservative than we are, that doesn't prevent this from happening. So that's another argument for the upgrades. In fact, KDE upstream doesn't even provide any further bugfix releases for the old branch after releasing the new one, they just don't have the resources to do that. So upgrading is the only way to continue picking up fixes. Your current proposal: http://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal still fails in that part. It's a compromise. Under that proposal, we'd push only one KDE upgrade per release instead of 2, and you'd have to upgrade to the latest released Fedora to get the latest KDE. (And FWIW, I prefer the current system where we also upgrade the previous Fedora, for the reasons outlined in that proposal under The cons – and yes, I know the points about KDE 4.4 and Qt 4.6 are outdated.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 3 Mar 2010, Chris Adams wrote: By the same token, if you want rolling update releases, feel free to do it in your own private repo. See how well that argument works? No i don't. I'm using a mainstream distribution and thus I expect to get them. Just like the upstream has intended them to happen. Tuju -- Ajatteleva ihminen tarvitsee unta. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 3 Mar 2010, Kevin Kofler wrote: The strong argument is that KDE and Fedora release cycles are not in sync and our users would thus have to wait months for the new KDE. As many have stated, not all people *want* those feature updates to stable release. By pushing them by force, you remove the user's choice to do as (s)he wishes. From those zillion posts past days I see that this is impossible to understand. I talked to rdieter about this and said that part of the problem is that not all of the bug fixes end to bugfix releases and would be thus ommitted from stable fedora releases. Being a pure KDE upstream problem, it should be solved there and would certainly get more focus if fedora would start enforcing it. I doubt it. Other distros are already much more conservative than we are, that doesn't prevent this from happening. So that's another argument for the upgrades. Upstream has written their own policy. It's their problem to follow it. In fact, KDE upstream doesn't even provide any further bugfix releases for the old branch after releasing the new one, they just don't have the resources to do that. So upgrading is the only way to continue picking up fixes. Which is good reason to upgrade the Fedora release if those still open issues really bother the enduser. It's a compromise. Under that proposal, we'd push only one KDE upgrade per release instead of 2, and you'd have to upgrade to the latest released Fedora to get the latest KDE. Pushing even one single feature release breaks the thing that fesco's new proposal is trying to achive. Nuff said from my part on this topic. Tuju -- Ajatteleva ihminen tarvitsee unta. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Chris Adams wrote: Once upon a time, Kevin Koflerkevin.kof...@chello.at said: Such as? We're filling a niche, this is one of our unique selling points, you want to throw out the baby with the bathwater! Who is this we you keep speaking of? When did huge dumps of updates in supposedly stable releases become an official selling point of Fedora? Since at least Fedora 8, when I switched from RHEL for exactly this reason! I use Fedora *because* new things show up quickly... yes, even in released versions. If I didn't want that, I'd use something else. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Joe: This is a big deal, because now some tiny minority has lobbied for changes that end up hurting everyone else. Bob: Yeah, I know. Par for the course. I hate the American government. Joe: Actually, I was talking about X.org... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: You can put free text in a bodhi comment without giving positive or negative karma. Seems we already have what you want to replace it with. But his point (which I agree with, FWIW) is that those arbitrary numbers are meaningless and thus it makes no sense to count them. Having the comments have that :-) or :-( icon is even fine, but counting them often leads to nonsense. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Tom spot Callaway wrote: * Has ABI/API change (and is a Critical Path package) Wrong criterion, sorry. Has ABI/API change and fails to include rebuilds of the affected packages should be the criterion, critical path or not is irrelevant. But this is basically covered by causes broken deps already. AutoQA has the potential to do this. I'd rather see energy and effort spent on taking out these low hanging fruit. But yes, implementing automatic QA checks first and only considering more drastic measures if they don't help is the right approach. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: So I did my proposal, which I think will motivate packagers to do the right thing (giving lots of choice to the users and a reasonable number of packages to test) and not removing the ability of packagers to do what they want (and have the stable firehose): https://fedoraproject.org/wiki/Release_Lifecycle(draft)#Choice_.28james.29 This is now at: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 I don't really see how this is adding any kind of choice. In particular, it doesn't address the but they have almost no options if they are happy to stay with the software that they have problem you're presenting in your introduction at all. FWIW, I don't see that as a problem anyway, but that has been discussed elsewhere in this thread already. I'm just noting that your proposal is addressing something entirely different. The other proposals are for the what kind of updates do we allow subthread, yours is for the when do we allow the push to hit stable as opposed to testing thread. So I think both the naming (Choice) and the location (Release Lifecycle) of your proposal are misleading. I think your proposal makes sense as a purely informative guideline, at most as SHOULD, but NOT as something to be enforced. It is very hard to enforce something like this (who would classify the updates into those categories?) and it would be extremely excessive bureaucracy. But on the other hand, providing such a list to maintainers on an indicative basis makes a lot of sense. In fact, we already do have such an indicative list internally in KDE SIG, the approximate numbers we use: * regression fixes, security updates, trivial bugfixes, new packages (*): may be queued directly to stable, 0 DSUT otherwise * other small bugfixes: 0 DSUT (but should be allowed to hit testing before being queued to stable, and it depends on feedback how long to wait in testing, up to about a week) * upstream bugfix releases or other large bugfixes: 7 DSUT * upstream feature releases of individual applications (where suitable for an update): 7 DSUT * upstream grouped feature releases, e.g. all of KDE (where suitable for an update): 14 DSUT (where those are minimum numbers, usually n DSUT minimum means somewhere between n and n+7 DSUT in practice depending on feedback, also note that days here include weekends, i.e. 7 = 1 week, 14 = 2 weeks). Occasionally we push something out faster due to overwhelmingly positive feedback, but usually this is how we work, and it has worked pretty well for us so far. So having that as a general Fedora guideline makes sense to me, but only with SHOULD or indicative status, NOT as an enforced policy! (*) without Obsoletes. A new package which Obsoletes something else is effectively an upgrade for another package and it needs to be handled the same way as if the name were the same. If it's completely different code, it's a feature release. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Peter Jones wrote: This is the plan that already isn't working. Is it really not working? Or are we overblowing a minor incident which didn't even cause all that much trouble and trying to swallow a cure which is worse than the disease? I think it's really the latter. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Peter Jones wrote: When you're at the circus watching the clown ride a bicycle across a high-wire, he's got a safety net. It's not because the circus thinks he's an incompetent high-wire cyclist - it's because people occasionally make mistakes, and the circus would rather have him around to do his act again when he falls. Yet some people do fune-walking or even fune-cycling without a safety net, for various reasons (e.g. the place they're doing their exercises in is such that mounting a safety net would be highly impractical there) and are still alive. Your proposal is akin to passing a law which bans fune-walking without a safety net. It'd have made some world records impossible. But the analogy isn't that great anyway (e.g. because a regression doesn't kill anybody! And it's usually trivial to revert to the last working version). Fedora is no different; there are many very competent maintainers out there, and all of us will eventually make a mistake. These mistakes sometimes have repercussions that are fairly serious, and when they do, it's important that the safety net is already there. The question is: Are those mistakes worse than the issues caused by NOT pushing updates directly to stable? For example, some regressions slip through testing (this will ALWAYS happen, testing is not and CANNOT be perfect), why should our users have to suffer through them for several days instead of getting them fixed in the next update push (i.e. as soon as possible)? So my answer is: no, banning direct stable pushes will not improve things: for any issue it will prevent, there will be several it will introduce! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: We do pushes daily, No we don't. There are usually no pushes on weekends. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: It's still not really usable by normal users, but people on this list can install yum-plugin-local ... which will make sure you can do downgrades like this. Isn't keepcache=yes sufficient? IMHO that should really be the default, I really don't understand why we default to throwing away the cache. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Adam Jackson wrote: If it's ready on Tuesday afternoon, what makes you think anyone's going to have time to read it thoroughly enough to be able to vote on it? Are you implying you're the only one on fesco that actually considers the proposal they're asked to vote on? Considering that this proposed change was almost voted into law WITHOUT an actual proposal, is it really that unreasonable of me to think that? Uh, why do we even allow triggers without explicit FESCo approval (including notification to the maintainers of the packages being triggered on)? They're much more dangerous than linking a static library or bundling a library! No disagreement here. But that's sort of my point. Packaging is subtle, and putting controls in place to minimize disruption for consumers is a broadly positive thing. We should be monitoring for new scriptlets and reviewing suspicious ones. We should also not skip updates-testing just because we think we're not going to break anything. I think these 2 things have nothing to do with each other. Scrutinizing specfile changes which do very rarely needed and dangerous things specially makes sense, preventing critical bugfixes from reaching their users as quickly as possible doesn't. I mean, your argument here is it doesn't matter how good our infrastructure for testing fixes is, it'll still not catch everything; therefore we should allow people to bypass it if they want. No, that's not my argument. While your summary is quite close, it misses the important point. My argument is actually: It doesn't matter how good our infrastructure for testing fixes is, it'll still not catch everything. Therefore, some regressions make it into stable anyway, and we want them to get fixed (in the stable updates) as quickly as possible to minimize their impact on users. Therefore we should allow people to bypass updates-testing if they feel a need for it. (And this just one of the reasons brought up for bypassing updates-testing.) (And it's also not a matter of wanting to bypass testing, but a matter of feeling that doing so for a given particular update is really the right thing to do to provide the best possible service to our users!) By that argument, no prophylactic is 100% effective against diseases, therefore people should be free to not use them if they don't want to. Therefore, this analogy is a strawman … You're positing A = B here. A might be true. B might be true. They might both be true! But it's not at all clear that A implies B. … and this logical fallacy you're accusing me of committing is not in my argument at all. While I understand the temptation to rank package importance and fragility by position in the dependency tree, remember that leaf packages are why people use the OS in the first place. No one runs Fedora just because they think coreutils is really neat. But leaf packages aren't that likely to break from a small change. And X11 breaking affects our users just as much as KDE or their favorite KDE application breaking. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Peter Jones wrote: Other corner cases where your case was wrong include new packages that Obsolete existing packages. Nonsense. I wrote new package which doesn't replace anything. Obsoletes = replacing. Even if you fix all the fixable problems, testing will still not be a silver bullet! Nobody is saying that it is! Merely that it's better than not having testing! I'm not suggesting we should not have testing, I'm suggesting we should be able to skip it for urgent fixes, such as regressions which slipped through testing (because testing is not a silver bullet)! X11 is particularly dangerous for this kind of changes, given how low it is in the software stack and how some code necessarily looks like (hardware drivers in particular are always scary stuff). The average leaf package is much less propice to breakage induced by minimal changes. This is just plain bull. High level packages also have one line fixes that are simple, elegant, and wrong. They are much less likely though. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 11:22 +0100, Kevin Kofler wrote: James Antill wrote: It's still not really usable by normal users, but people on this list can install yum-plugin-local ... which will make sure you can do downgrades like this. Isn't keepcache=yes sufficient? IMHO that should really be the default, I really don't understand why we default to throwing away the cache. Again, diskspace is the primary concern. However the yum-plugin-local package needs to do a bit more than that, because the metadata goes away from the remote repo. as well as the packages ... so we need to create our own local repo. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote: I didn't bring up the fun argument. My point is that banning direct stable pushes prevents us from fixing things for our users ASAP when needed. This is all part of duty, not fun. And it prevents us from breaking things, with no warning (around and around we go). In addition, in practice, it's quite likely that bugs will often be answered with it's too hard to backport that particular fix, upgrade to the current version from backports (or even Cooker/Rawhide/whatever) if you need it. There's no way you can really force maintainers to provide an update stream which is stable under that definition (no upgrades, only backported fixes). I know you aren't talking specifically of my proposal here: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 ...but it has the same problem. But IMNSHO this isn't a problem, you are arguing that people specifically hit by problem X can goto the updates-testing (or whatever it's called) repo. and get a fix for it. Anyone not affected doesn't have to risk that update breaking anything else they do care about (and for the people affected, if the cure is worse than the disease they can easily backout). And that's only until the new version has been tested enough that it's a lot more safe to give it to everyone. How is this not the best of all solutions? (for the users) Many instances have shown that it does not give us the bugfixes 'for free'. It comes with the cost of causing regressions. That may be a cost which we decide we want to bear, but portraying things in a Panglossian manner doesn't help your cause, as it just makes you look like you're denying there could ever possibly be any problems with your method. But that's not a cost for the maintainer (unless the regression breaks his/her own system). :-) Indeed, this comment does seem to epitomize your argument. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 10:59 +0100, Kevin Kofler wrote: James Antill wrote: So I did my proposal, which I think will motivate packagers to do the right thing (giving lots of choice to the users and a reasonable number of packages to test) and not removing the ability of packagers to do what they want (and have the stable firehose): https://fedoraproject.org/wiki/Release_Lifecycle(draft)#Choice_.28james.29 This is now at: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 I don't really see how this is adding any kind of choice. In particular, it doesn't address the but they have almost no options if they are happy to stay with the software that they have problem you're presenting in your introduction at all. Users don't get a constant firehose of updates they are basically forced to install, a lot more packages should spend a lot more time in testing (thus. the user can choose to get the updates or updates-testing versions). How is that not more choice than here's rawhide-12, you are now forced to test it for me? The other proposals are for the what kind of updates do we allow subthread, yours is for the when do we allow the push to hit stable as opposed to testing thread. So I think both the naming (Choice) and the location (Release Lifecycle) of your proposal are misleading. I read them all as trying to solve the what do we do in the lifecycle of a release, to make it suck less for users problem and general stop users saying Well I use Fedora in spite of the number/size of updates. One way is to just outright ban a lot of updates, but this then becomes subjective and I'm not sure rel-eng is setup to do that. So I proposed something that could be objectively implemented, and would give the packagers the freedom to do the updates the think are best. I think your proposal makes sense as a purely informative guideline, at most as SHOULD, but NOT as something to be enforced. It is very hard to enforce something like this (who would classify the updates into those categories?) The packagers would classify their bugs, in make update mostly as the do now (although there are more categories). I don't think anyone is arguing that packagers are actively trying to harm anybody, so I'd assume they would classify them correctly in the vast majority of cases. The problem with leaving it as a SHOULD is the tendency for packagers to be significant users of their packages, so they tend to be affected more by bugs and tend to want features ASAP. The desire to say well this isn't _that_ big a change, and it's been in testing a couple of days so it's probably fine is very big. I think may have also missed the fact that DSUT _increases_ (to stop the practice of having 1 update a month for a package, so the user is forced to get them all or none) with each push from updates-testing to updates. I find it less believable that packagers will follow that (esp. considering the above). In fact, we already do have such an indicative list internally in KDE SIG, the approximate numbers we use: * regression fixes, security updates, trivial bugfixes, new packages (*): may be queued directly to stable, 0 DSUT otherwise * other small bugfixes: 0 DSUT (but should be allowed to hit testing before being queued to stable, and it depends on feedback how long to wait in testing, up to about a week) While I admit that I made the numbers up, and so am happy to discuss changing them slightly ... your opinion that there should be a large class of updates which go directly to stable, with no testing, is IMNSHO insane. * upstream bugfix releases or other large bugfixes: 7 DSUT * upstream feature releases of individual applications (where suitable for an update): 7 DSUT You have 21 days of testing for the first update, and over a month for the second ... really? * upstream grouped feature releases, e.g. all of KDE (where suitable for an update): 14 DSUT Again, that's over a month for the first update and about 3 months for the second ... I find it hard to believe you are willingly that conservative. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 11:06 +0100, Kevin Kofler wrote: Peter Jones wrote: This is the plan that already isn't working. Is it really not working? Or are we overblowing a minor incident which didn't even cause all that much trouble and trying to swallow a cure which is worse than the disease? I think it's really the latter. The one minor incident being where the project leader had to post to the world that we'd screwed it up, and got covered in LWN etc. I don't think I'd like to wait for something you'd class as a non-minor incident. I probably spend at least an hour a week updating, and current have over 220 packages available to update (a significant part of which are shared libraries linked against most of the distro.). Download size for everything is just over 330MB. History summary since GA shows over 1,100 Erases, Installs, Obsoletes and Updates. Probably when I next reboot, I'll just do a giant yum update -y and hope for the best ... which is what I assume most of our users do. If you think there's nothing wrong with that, and even more so if you think updates-testing should be bypassed in a significant number of cases, well then rawhide is that = way. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote: James Antill ja...@fedoraproject.org writes: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 Regarding this, I don't understand this part: The idea behind this proposal is that a Fedora user installing a release N has a lot of choice if they wish to get newer packages: * They can move to rawhide. * [...] * If they are on an older Fedora release, they can update to the latest Fedora release. ...but they have almost no options if they are happy to stay with the software that they have. Doesn't just not running random/unrestricted yum update exactly encode that option? No, for two reasons: 1. The user is often informed, from various sources, that they should apply updates. We even want users to do that. Of course the assumption with that advise is that there aren't that many updates, and they will mainly be severe bug fixes and security fixes ... and they will have gone through a lot of testing. 2. If you have 10 updates available, you can realistically look at what the updates do and even pick and choose what to install. Maybe with fixes to the PK GUI that might be close to reasonable for 100 updates. But if you have 1,000 updates, the choice is roughly run yum update -y or do nothing. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 09:45 +0100, Kevin Kofler wrote: Yet, in practice, I still think a lot more stuff gets backported in our updates repository than in those backports repositories of other distros. Probably true (though in the case of Mandriva, maybe less than you'd expect; it's nothing like the wasteland that is Ubuntu backports). What's your point? That your model would lead to fewer backport type updates and thus be further away from what I and several others would like to see than what we have now! Oh, I see. You're inferring a cause where there's no reason to. I didn't realize that. You admitting this point also directly contradicts your claims elsewhere that it wouldn't lead to fewer backport type updates being provided. I wasn't admitting any point. The fact that less stuff gets backported in MDV is more or less a direct function of a) whether anyone actually wants it to be backported and b) the number of maintainers. (By the way, the backports term is unfortunate, because it's misleading, as the backports are actually version upgrades whereas the conservative updates are the ones getting backported fixes. It's looking at it from the other end: it's new versions being 'backported' to a stable distribution release. That's precisely what Mandriva has - twin streams, one stable update stream, one backport stream. All maintainers are required to provide stable updates for packages in /main. They can *choose* to provide /backports upgrades too, but that doesn't absolve them of doing a safe /updates stream. That was exactly my point. This removes the option to only provide the new versions (which also fix bugs, often more than bugfixes conservatively backported to the old version would ever fix because maintainers cannot be expected to backport each and every bugfix for big upstream projects, and if they did, they'd essentially ship the new version disguised as backported bugfixes) and will lead many maintainers to choose to only provide the conservative option. With our policy, they're encouraged to just drop the legacy crap and ship the current version. We're back to the same question, where what you describe as 'legacy crap' is what many people would describe as 'their nicely working system'. :) -- 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote: Doesn't just not running random/unrestricted yum update exactly encode that option? If you're happy to live with unsecure software, certainly =) you can try and cherry-pick security updates, but then you get the problem where initial release has Foobar 1.0, then Foobar 3.5 gets shipped in updates, then a security problem emerges and Foobar 3.5-2 with the security fix gets shipped in updates. You now have a choice of unsecure Foobar 1.0, or completely new version Foobar 3.6. -- 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill ja...@fedoraproject.org writes: [...] ...but they have almost no options if they are happy to stay with the software that they have. Doesn't just not running random/unrestricted yum update exactly encode that option? No, for two reasons: 1. The user is often informed, from various sources, that they should apply updates. We even want users to do that. OK, but then we're not talking about the person who's happy to stay with the software they have, but about a more typical person who is not too risk-averse and is willing to consider unsolicited updates. Those are different dudes. Of course the assumption with that advise is that there aren't that many updates, and they will mainly be severe bug fixes and security fixes ... Fedora updates may be classified, but perhaps not granularly enough. An update can include a mixture of security fixes, serious bug fixes, minor bug fixes, new features, and of course risks such as changed configuration files, new known bugs. Perhaps a new update could be scored by the maintainer on all these scales, so that the client update interface can easily filter/sort to the preferred top few. and they will have gone through a lot of testing. Well, this being Fedora, a lot of testing is always a matter of faith. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
2010/3/2 Adam Williamson awill...@redhat.com: On Tue, 2010-03-02 at 10:57 -0500, Frank Ch. Eigler wrote: Doesn't just not running random/unrestricted yum update exactly encode that option? If you're happy to live with unsecure software, certainly =) you can try and cherry-pick security updates, but then you get the problem where initial release has Foobar 1.0, then Foobar 3.5 gets shipped in updates, then a security problem emerges and Foobar 3.5-2 with the security fix gets shipped in updates. You now have a choice of unsecure Foobar 1.0, or completely new version Foobar 3.6. Yes, and that will always be the case unless you are hiring a lot of developers to backport security fixes. Oh wait ... isn't that what RHEL is about? - Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 11:17 +0100, Kevin Kofler wrote: No we don't. There are usually no pushes on weekends. That's a fair point, but there are significantly fewer people around to fix critical issues should they arise on a weekend, and after working 5 weekdays, some of us like taking the weekend off. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 11:55 +0100, Kevin Kofler wrote: My argument is actually: It doesn't matter how good our infrastructure for testing fixes is, it'll still not catch everything. Therefore, some regressions make it into stable anyway, and we want them to get fixed (in the stable updates) as quickly as possible to minimize their impact on users. Therefore we should allow people to bypass updates-testing if they feel a need for it. By-pass updates testing, sure. By-pass it without any karma votes, I don't think so. If you've pushed a regression, and you want it fixed as soon as possible, then it should be quite easy to find a couple people to test the build and give karma status before it gets pushed to -testing (once a dayish remember?) and thus it could go directly to stable. This is the problem with arguing about a proposal that hasn't even been written yet. You latch onto the one part you assume will be there that is the most unreasonable, and use that as a tool to bash the entire concept of the proposal (which hasn't been written yet). I'm sure there is a Latin phrase for this, I just don't know it. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2 Mar 2010, Jesse Keating wrote: This is the problem with arguing about a proposal that hasn't even been written yet. You latch onto the one part you assume will be there that is the most unreasonable, and use that as a tool to bash the entire concept of the proposal (which hasn't been written yet). I'm sure there is a Latin phrase for this, I just don't know it. He's created a strawman and is arguing against it. that's the logical fallacy. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 18:08 +0100, Thomas Moschny wrote: you can try and cherry-pick security updates, but then you get the problem where initial release has Foobar 1.0, then Foobar 3.5 gets shipped in updates, then a security problem emerges and Foobar 3.5-2 with the security fix gets shipped in updates. You now have a choice of unsecure Foobar 1.0, or completely new version Foobar 3.6. Yes, and that will always be the case unless you are hiring a lot of developers to backport security fixes. Oh wait ... isn't that what RHEL is about? Other distributions manage this perfectly well without egregious version bumps. -- 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 07:46 +0100, Kevin Kofler wrote: I just disagree with the claim that ALL updates are susceptible of breaking things. Until such time that every update goes through without any breakage, I'm going to keep on assuming that all updates are susceptible to breaking things, and should get a couple pairs of eyes/systems on them to double check. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2010-03-02 at 12:08 -0500, Frank Ch. Eigler wrote: James Antill ja...@fedoraproject.org writes: [...] ...but they have almost no options if they are happy to stay with the software that they have. Doesn't just not running random/unrestricted yum update exactly encode that option? No, for two reasons: 1. The user is often informed, from various sources, that they should apply updates. We even want users to do that. OK, but then we're not talking about the person who's happy to stay with the software they have, but about a more typical person who is not too risk-averse and is willing to consider unsolicited updates. Those are different dudes. Right, I figured that was implied. If I'm happy with, say, named as it came in F12 ... that implies I don't want any updates for new features which might break my nameserver, but I'd still want any high exposure security fixes _quickly_ ... and I'd be happy to see significant bugfixes for existing problems (but, again, I don't want to see 1 update a month to fix small problems). Could you suggest better wording (that's smaller than the above paragraph :). Of course the assumption with that advise is that there aren't that many updates, and they will mainly be severe bug fixes and security fixes ... Fedora updates may be classified, but perhaps not granularly enough. An update can include a mixture of security fixes, serious bug fixes, minor bug fixes, new features, and of course risks such as changed configuration files, new known bugs. Perhaps a new update could be scored by the maintainer on all these scales, so that the client update interface can easily filter/sort to the preferred top few. I think it's understood that you can just take one and classify the bundle as that. Obviously there is still some leeway here, and we might need more policies but starting by asking the packagers to DTRT doesn't seem like a terrible idea. and they will have gone through a lot of testing. Well, this being Fedora, a lot of testing is always a matter of faith. Sure, we don't guarantee it and we still won't be able to ... but there's a big difference between this has been in updates-testing for 3 days (or less!), has 10 bug fixes and 10 new features compared with this has been in updates-testing for a month, been updated twice to fix minor problems found in testing and has 10 bug fixes and 2 new features. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/02/2010 04:23 AM, Kevin Kofler wrote: Tom spot Callaway wrote: * Has ABI/API change (and is a Critical Path package) Wrong criterion, sorry. Has ABI/API change and fails to include rebuilds of the affected packages should be the criterion, critical path or not is irrelevant. But this is basically covered by causes broken deps already. It means we have to update even more software seems like a reason /not/ to ship an update that isn't a bugfix or security fix. Not a reason it *should* be done. -- Peter I hope you know that this will go down on your permanent record. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/02/2010 06:15 AM, Kevin Kofler wrote: X11 is particularly dangerous for this kind of changes, given how low it is in the software stack and how some code necessarily looks like (hardware drivers in particular are always scary stuff). The average leaf package is much less propice to breakage induced by minimal changes. This is just plain bull. High level packages also have one line fixes that are simple, elegant, and wrong. They are much less likely though. Please provide data to support this bullshit assertion. -- Peter I hope you know that this will go down on your permanent record. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/02/2010 05:15 AM, Kevin Kofler wrote: Peter Jones wrote: When you're at the circus watching the clown ride a bicycle across a high-wire, he's got a safety net. It's not because the circus thinks he's an incompetent high-wire cyclist - it's because people occasionally make mistakes, and the circus would rather have him around to do his act again when he falls. Yet some people do fune-walking or even fune-cycling without a safety net, for various reasons (e.g. the place they're doing their exercises in is such that mounting a safety net would be highly impractical there) and are still alive. Your proposal is akin to passing a law which bans fune-walking without a safety net. It'd have made some world records impossible. But the analogy isn't that great anyway (e.g. because a regression doesn't kill anybody! And it's usually trivial to revert to the last working version). You're right about my analogy not being perfect, but it doesn't really need to be. You seem to be trying to miss the point here. The analogy was not to people doing crazy things, it was to people doing seemingly crazy things in a circus act. Let me be a bit more explicit. The difference between our analogies is that in the former (your fune-cycling example), the people doing the crazy thing face all of the consequences. In the latter (my original circus analogy), the circus is also hurt when a performer goes splat in front of the audience. In the circus analogy, the ringmaster wants the net there - because he needs his good (but mortal) performers to survive to do the act again, or else eventually there won't be any circus. To categorize our analogies, mine is an analogy for Fedora, yours is an analogy for your desktop machine. If you feel like running new untested packages on your desktop machine, that's fine, we've got rawhide (and updates-testing) for that. You can also feel free to participate in life-threatening activities that you find challenging and beneficial to your own well being and try to establish records for not dying on the highest high-wire or whatnot. Running untested packages may toast your desktop machine, but doing so also has inherent benefit to the greater group. But putting those packages in Fedora without going through updates-testing or rawhide first is effectively doing the high-wire without a net /in the circus/, not in your back yard or the alps or wherever on your own. Fedora is no different; there are many very competent maintainers out there, and all of us will eventually make a mistake. These mistakes sometimes have repercussions that are fairly serious, and when they do, it's important that the safety net is already there. The question is: Are those mistakes worse than the issues caused by NOT pushing updates directly to stable? For example, some regressions slip through testing (this will ALWAYS happen, testing is not and CANNOT be perfect) Perfect is the enemy of good. Our testing will never be perfect, but requiring that it happen is better than allowing it not to. If it isn't, the answer is to make the testing better - not to skip it entirely! why should our users have to suffer through them for several days instead of getting them fixed in the next update push (i.e. as soon as possible)? This is a logically callow statement. Our users do not *suffer* from non-critical updates being delayed for a short time, nor do they *suffer* from critical updates getting sufficient testing so as not to immediately require *another* critical update. At no point in the scenario you paint is there any actual suffering. So my answer is: no, banning direct stable pushes will not improve things: for any issue it will prevent, there will be several it will introduce! You haven't actually demonstrated any real problems it will introduce; just the same (rather thin) strawman over and over. Given a lack of actual, real problems demonstrated with the bizarro concept of actually requiring that updates go through our QA infrastructure, the answer certainly seems to be: yes, absolutely. -- Peter I hope you know that this will go down on your permanent record. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Frank Ch. Eigler wrote: OK, but then we're not talking about the person who's happy to stay with the software they have, but about a more typical person who is not too risk-averse and is willing to consider unsolicited updates. Those are different dudes. The person who's not willing to do any updates is a very dangerous person (think security updates, and also consider the fact that we don't really support selective updates, so pulling only security updates isn't that good a plan either; I know we technically have yum-security, but if somebody files a bug about my security update not working with some ancient version of some other package, I'll just file it away as NOTABUG with the comment yum update, and I know I'm not alone in that). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: ...but it has the same problem. But IMNSHO this isn't a problem, you are arguing that people specifically hit by problem X can goto the updates-testing (or whatever it's called) repo. and get a fix for it. Anyone not affected doesn't have to risk that update breaking anything else they do care about (and for the people affected, if the cure is worse than the disease they can easily backout). And that's only until the new version has been tested enough that it's a lot more safe to give it to everyone. How is this not the best of all solutions? (for the users) Because this codifies selective updates as a recommendation when actually it's a quite dangerous thing to do. (Stuff in testing may depend on or only be tested with other stuff in testing, especially if stuff sits in testing for ages.) And because many of the affected users won't even go as far as tracking down the Bugzilla entry for the bug and finding the testing/backport/whatever update to upgrade to. Users should get bugfixes by default, not be told to pull fixed packages from the please-fedora-pretty- please-work repo. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Adam Williamson wrote: Oh, I see. You're inferring a cause where there's no reason to. I didn't realize that. What other reasons do you consider then? Pure chance? Doesn't look very likely to me. It's much more likely the reason Mandriva provides fewer new versions is because of the split update streams and the default being the conservative one. Restrictive policies such as no system library backports (even where backwards-compatible) (which in turn precludes some application updates, e.g. it's quite common for packages to require a new Qt) may also be part of the reason. I wasn't admitting any point. The fact that less stuff gets backported in MDV is more or less a direct function of a) whether anyone actually wants it to be backported and b) the number of maintainers. So you want me to file bugs asking Please dear maintainer, pretty please, would you please be so kind as to please provide a backport for this package, I really need the new version, please! I supplicate you! for every single package I'd like updated? Huh? It's the maintainer's job to realize the package needs updating, nobody should have to request it. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Kevin Kofler wrote: Even bugfix releases of KDE require a session restart to fully work. I consider that a serious design flaw in KDE and a strong argument against releasing any KDE updates to stable releases other than fixes for serious bugs. The only practical way to keep up with the Fedora update firehose is to update every day and let the update run in the background while I'm working. If I put it off until I'm about to turn the computer off, then the updates will accumulate and updating will take a long time when I finally do it. I might not have the time to sit around and wait for the update to finish so that I can turn the computer off, so I'll put it off again, and when the next opportunity comes the list of updates will have grown even more. That's a vicious circle I don't want to get into. Björn Persson 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Adam Williamson wrote: you can try and cherry-pick security updates, but then you get the problem where initial release has Foobar 1.0, then Foobar 3.5 gets shipped in updates, then a security problem emerges and Foobar 3.5-2 with the security fix gets shipped in updates. You now have a choice of unsecure Foobar 1.0, or completely new version Foobar 3.6. There's also the other variant where a security problem is found in Foobar 1.0 but the problem isn't present in Foobar 3.0 and later. Upstream still supports the 1.0 branch and releases Foobar 1.0.4 to fix the problem, but no security update is released for Fedora since there is no problem in the latest Fedora package. The Fedora user who chose not to upgrade Foobar won't even know that there is a security problem. Björn Persson 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Mike McGrath wrote: You can't assume that people are only using software we ship. If someone is using software they've custom developed (think a webapp). We've now forced them to do work. There's several use cases here, people building and shipping appliances, webapps, etc. Why would anyone agree to do development and choose Fedora if the target they're building for can change without notice? They already do. Our ABIs can already change without notice, and our policy is to only require a rebuild of the stuff in Fedora (and third-party repositories are expected to rebuild their stuff, for RPM Fusion we normally warn the affected maintainers beforehand). For custom-built stuff, whoever builds it is responsible for rebuilding it for dependency changes. It would be impossible to do even Firefox security updates (and many other important updates) otherwise! I don't see this as a problem at all. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Peter Jones wrote: It means we have to update even more software seems like a reason /not/ to ship an update that isn't a bugfix or security fix. Not a reason it *should* be done. 1. Nowhere was it said the ABI change is NOT a bugfix or security fix. Even security fixes can require ABI bumps, see xulrunner. 2. Sometimes even feature updates to libraries are important, because some important new or updated application requires the new library to work. I don't see why we should ban it just because 2-3 other leaf packages need a rebuild. That's what grouped updates are for. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote: Kevin Kofler wrote: Even bugfix releases of KDE require a session restart to fully work. I consider that a serious design flaw in KDE and a strong argument against releasing any KDE updates to stable releases other than fixes for serious bugs. The only practical way to keep up with the Fedora update firehose is to update every day and let the update run in the background while I'm working. If I put it off until I'm about to turn the computer off, then the updates will accumulate and updating will take a long time when I finally do it. I might not have the time to sit around and wait for the update to finish so that I can turn the computer off, so I'll put it off again, and when the next opportunity comes the list of updates will have grown even more. That's a vicious circle I don't want to get into. We do need a apply all updates and shut down option. That doesn't help much if I'm going to pack the laptop up in a bag and take it with me. I'll still have to sit there and twiddle my thumbs while it updates. Björn Persson 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
James Antill wrote: The one minor incident being where the project leader had to post to the world that we'd screwed it up, Well, I think he overblew it too. ;-) But he just wanted to get the message out so people can fix it more easily. Still, I don't see how it's a major issue. The vast majority of Fedora users didn't even notice this at all as they don't run a bind server. and got covered in LWN etc. The press always overblows stuff, that's not news. I don't think I'd like to wait for something you'd class as a non-minor incident. That D-Bus security update applications were not prepared for was a much bigger fiasco, many more users were hit. I probably spend at least an hour a week updating, and current have over 220 packages available to update (a significant part of which are shared libraries linked against most of the distro.). Download size for everything is just over 330MB. History summary since GA shows over 1,100 Erases, Installs, Obsoletes and Updates. And where's the problem? That's 330 MB worth of improvements, bug fixes etc. It shows that we're all busy making Fedora better. Probably when I next reboot, I'll just do a giant yum update -y and hope for the best ... which is what I assume most of our users do. Well, nobody forces you to read update details. If you think there's nothing wrong with that, and even more so if you think updates-testing should be bypassed in a significant number of cases, well then rawhide is that = way. No, Rawhide is completely different, it also contains disruptive updates (by design, not just in extremely rare cases and by mistake) and there is no testing repository at all for it (so if something breaks, it always hits you, not just in the rare event the update bypassed testing despite being risky or the breakage slipped through testing). You and everyone else, please stop proposing Rawhide as the solution for me and people who want the same update everything that doesn't break things policy, it does NOT fit our usecase at all! On the other hand, your usecase has a solution, it's called CentOS. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote: You and everyone else, please stop proposing Rawhide as the solution for me and people who want the same update everything that doesn't break things policy, it does NOT fit our usecase at all! If you don't like rawhide for that use case, find another operating system. I'm tired of our stable releases getting tonnes of updates. I'm tired of what F11 shipped like being completely different today. I'm tired of waiting for many many hours while we try to compose out the 3444 individual updates in F11 stable. (that's right, 3444 srpms worth of updates. F11 only had 7446 srpms to begin with!!). This is not the style of distribution I wish to produce or consume. If this is the style of distribution you wish to produce or consume, then I encourage you to go find another distribution or start your own. On the other hand, your usecase has a solution, it's called CentOS. Wrong answer. Fedora can provide rapid adoption of new technology in it's 6 month release cycle. It can provide stability for those releases with a more conservative update style, focusing more on bugfixes and less on new features/packages. We can give users the confidence that when they install a Fedora release, we won't screw it up with irresponsible updates, or by changing the look/feel of their system midstream. We can do all of this at the rapid pace that puts Fedora in a vastly different world than CentOS or even Ubuntu. This is the kind of operating system I wish to produce, and I wish to consume. So again, if you want something different, perhaps /you/ are using the wrong operating system. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Peter Jones wrote: To categorize our analogies, mine is an analogy for Fedora, yours is an analogy for your desktop machine. If you feel like running new untested packages on your desktop machine, that's fine, we've got rawhide (and updates-testing) for that. You can also feel free to participate in life-threatening activities that you find challenging and beneficial to your own well being and try to establish records for not dying on the highest high-wire or whatnot. Running untested packages may toast your desktop machine, but doing so also has inherent benefit to the greater group. But putting those packages in Fedora without going through updates-testing or rawhide first is effectively doing the high-wire without a net /in the circus/, not in your back yard or the alps or wherever on your own. Your analogy still misses the point, see below. For example, some regressions slip through testing (this will ALWAYS happen, testing is not and CANNOT be perfect) Perfect is the enemy of good. Our testing will never be perfect, but requiring that it happen is better than allowing it not to. If it isn't, the answer is to make the testing better - not to skip it entirely! But the problem is what to do if the testing ALREADY failed. Then the best strategy is to fix the problem ASAP, bypassing testing this time, to get the regression out of the way. why should our users have to suffer through them for several days instead of getting them fixed in the next update push (i.e. as soon as possible)? This is a logically callow statement. Our users do not *suffer* from non-critical updates being delayed for a short time, An update fixing a regression from the previous update is not really non- critical. Users will definitely suffer if their package is broken when it used to work. The sooner you fix it, the better. nor do they *suffer* from critical updates getting sufficient testing Most users are not going to manually pull updates from testing, nor to use testing wholesale. So they WILL suffer the effects of the bug for a longer time if the update is being held in testing rather than pushed to stable. so as not to immediately require *another* critical update. The point is to do direct stable pushes only where this is very unlikely (e.g. because the fix for the regression is a one-line or otherwise trivial fix). I know the likelihood can never be 0, but if you can choose between a likelihood of .001% of the package being broken (due to another, unforeseen regression) or a likelihood of 100% of the package being broken (because the regression fix is not in stable yet), why choose the 100%? In the worst case you push another update directly to stable to fix the second regression, but the chance of this being necessary is extremely low. At no point in the scenario you paint is there any actual suffering. Sorry, but a user sitting in front of a broken application definitely qualifies as suffering under my definition. You haven't actually demonstrated any real problems it will introduce; just the same (rather thin) strawman over and over. I have, you keep either ignoring or failing to understand my arguments! (There is even more than one, but regression fixes are something I care particularly about, I feel very strongly that direct stable pushes are often the best approach for those.) Given a lack of actual, real problems demonstrated with the bizarro concept of actually requiring that updates go through our QA infrastructure, the answer certainly seems to be: yes, absolutely. Actual, real problem: * update X gets created * update X sits in testing for 1 or 2 weeks, either no regressions are found or all those that are found get fixed * due to the positive feedback, update X gets pushed to stable * within a day of the stable push, a regression is found in update X (as by design, many more people run stable than testing) * update X' gets created to fix the regression in update X Now we have 2 options: a) let X' sit in testing for a week. Users are affected by the regression in X for a full week. b) push X' directly to stable. Users are only affected by the regression for the time it takes to process the push containing X', which is the minimum possible response time. How is option b not more desirable than option a? And this is NOT a fictive example, it has happened many times with real updates. (I'll also note that James Antill's poorly-named Choice proposal would suck particularly in that it'd especially penalize followup updates like X', making it basically impossible to fix regressions in a timely manner. The testing time for X' must be decided ONLY based on the changes between X and X', not based on past history nor on the mere fact that X' is a followup.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: That's a fair point, but there are significantly fewer people around to fix critical issues should they arise on a weekend, and after working 5 weekdays, some of us like taking the weekend off. Well, I'm around on the weekends and the lack of update pushes for the whole weekend has irked me more than once. My intention is not to force you or Josh Boyer to work on weekends, but maybe we can find a new volunteer to do weekend pushes (and only weekend pushes, so they wouldn't be doing Fedora work the full week)? And ideally, update pushes should eventually be automatic, just like the Rawhide composes. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Peter Jones wrote: On 03/02/2010 06:15 AM, Kevin Kofler wrote: X11 is particularly dangerous for this kind of changes, given how low it is in the software stack and how some code necessarily looks like (hardware drivers in particular are always scary stuff). The average leaf package is much less propice to breakage induced by minimal changes. This is just plain bull. High level packages also have one line fixes that are simple, elegant, and wrong. They are much less likely though. Please provide data to support this bullshit assertion. Changing the bytes which get sent to some piece of hardware you have no or only inaccurate documentation on is much more likely to cause breakage than some of the simple changes which are done at application level, like removing a hardcoded call to setCheckSpellingEnabled(true) to make it default to the system default instead. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: If you don't like rawhide for that use case, find another operating system. Such as? We're filling a niche, this is one of our unique selling points, you want to throw out the baby with the bathwater! I'm tired of waiting for many many hours while we try to compose out the 3444 individual updates in F11 stable. The fact that it takes hours is really a failure of our mash process. Extras managed to deal with this in a much more efficient way: they pushed only the new stuff and then had scripts to clean out the old stuff (and a process to request manual deletion if old stuff was not being cleaned out for some reason). How much old stuff was in the repo was mostly irrelevant for the time a push took. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote: But the problem is what to do if the testing ALREADY failed. Then the best strategy is to fix the problem ASAP, bypassing testing this time, to get the regression out of the way. So testing failed, ergo the best way to fix it is to bypass the testing all together? Really? If you failed that badly the first time, there should be lots of people lined up to make sure you don't fail the second time. You should be able to get positive karma votes within a few hours of the bodhi update being filed, which should be plenty of time before the next updates push. why should our users have to suffer through them for several days instead of getting them fixed in the next update push (i.e. as soon as possible)? This is a logically callow statement. Our users do not *suffer* from non-critical updates being delayed for a short time, An update fixing a regression from the previous update is not really non- critical. Users will definitely suffer if their package is broken when it used to work. The sooner you fix it, the better. nor do they *suffer* from critical updates getting sufficient testing Most users are not going to manually pull updates from testing, nor to use testing wholesale. So they WILL suffer the effects of the bug for a longer time if the update is being held in testing rather than pushed to stable. so as not to immediately require *another* critical update. The point is to do direct stable pushes only where this is very unlikely (e.g. because the fix for the regression is a one-line or otherwise trivial fix). I know the likelihood can never be 0, but if you can choose between a likelihood of .001% of the package being broken (due to another, unforeseen regression) or a likelihood of 100% of the package being broken (because the regression fix is not in stable yet), why choose the 100%? In the worst case you push another update directly to stable to fix the second regression, but the chance of this being necessary is extremely low. At no point in the scenario you paint is there any actual suffering. Sorry, but a user sitting in front of a broken application definitely qualifies as suffering under my definition. You haven't actually demonstrated any real problems it will introduce; just the same (rather thin) strawman over and over. I have, you keep either ignoring or failing to understand my arguments! (There is even more than one, but regression fixes are something I care particularly about, I feel very strongly that direct stable pushes are often the best approach for those.) Given a lack of actual, real problems demonstrated with the bizarro concept of actually requiring that updates go through our QA infrastructure, the answer certainly seems to be: yes, absolutely. Actual, real problem: * update X gets created * update X sits in testing for 1 or 2 weeks, either no regressions are found or all those that are found get fixed * due to the positive feedback, update X gets pushed to stable * within a day of the stable push, a regression is found in update X (as by design, many more people run stable than testing) * update X' gets created to fix the regression in update X Now we have 2 options: a) let X' sit in testing for a week. Users are affected by the regression in X for a full week. b) push X' directly to stable. Users are only affected by the regression for the time it takes to process the push containing X', which is the minimum possible response time. How is option b not more desirable than option a? Strawman. You've completely missed option c. Submit update to bodhi, get a few people to test the update direct from bodhi links (hey look, bugzilla has those links!) and provide karma feedback. Update gets to skip updates-testing and go directly to stable, due to karma feedback. And this is NOT a fictive example, it has happened many times with real updates. Option C isn't fictive either, it happens many times with real updates. So yeah, you can create a strawman where you are handcuffed to somebody, and you decide between chopping your hand off vs chopping their hand off. Makes chopping their hand off look like the best option, only if you ignore the key to the handcuffs sitting on the counter. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote: Jesse Keating wrote: That's a fair point, but there are significantly fewer people around to fix critical issues should they arise on a weekend, and after working 5 weekdays, some of us like taking the weekend off. Well, I'm around on the weekends and the lack of update pushes for the whole weekend has irked me more than once. My intention is not to force you or Josh Boyer to work on weekends, but maybe we can find a new volunteer to do weekend pushes (and only weekend pushes, so they wouldn't be doing Fedora work the full week)? And ideally, update pushes should eventually be automatic, just like the Rawhide composes. Kevin Kofler Except there aren't enough key people available on the weekend to clean up the crap if something goes wrong. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating 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: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, Mar 02, 2010 at 05:19:03PM -0800, Jesse Keating wrote: On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote: On the other hand, your usecase has a solution, it's called CentOS. Wrong answer. Fedora can provide rapid adoption of new technology in it's 6 month release cycle. It can provide stability for those releases with a more conservative update style, focusing more on bugfixes and less on new features/packages. We can give users the confidence that when they install a Fedora release, we won't screw it up with irresponsible updates, or by changing the look/feel of their system midstream. We can do all of this at the rapid pace that puts Fedora in a vastly different world than CentOS or even Ubuntu. This is the kind of operating system I wish to produce, and I wish to consume. So again, I personally agree. I would love to work on a distro like that again. We used to be pretty close to this, and over time I think Fedora has drifted away from that into something entirely different. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Tue, 2 Mar 2010, Matthew Woehlke wrote: Jesse Keating wrote: On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote: You and everyone else, please stop proposing Rawhide as the solution for me and people who want the same update everything that doesn't break things policy, it does NOT fit our usecase at all! If you don't like rawhide for that use case, find another operating system. I'm tired of our stable releases getting tonnes of updates. I'm tired of what F11 shipped like being completely different today. I'm tired of waiting for many many hours while we try to compose out the 3444 individual updates in F11 stable. (that's right, 3444 srpms worth of updates. F11 only had 7446 srpms to begin with!!). This is not the style of distribution I wish to produce or consume. If this is the style of distribution you wish to produce or consume, then I encourage you to go find another distribution or start your own. Okay, I have to ask: why are you right and Kevin is wrong? What makes your vision of Fedora more worthy than his? (Especially when his is the apparent incumbent?) I do not agree Kevin's view is incumbent. I think what's happened is we exploded in size when extras came in and when we merged core and extras and we lost control over the process and over assimilating what was the CORE process onto extras. When we had 200 pkgs updated for 2100 pkgs in the distro it didn't look too bad - but we're at half the number of updates as original pkgs. It doesn't work very well anymore. This is about scale and about managing our expectations. It's not about radically altering anything. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Such as? We're filling a niche, this is one of our unique selling points, you want to throw out the baby with the bathwater! Who is this we you keep speaking of? When did huge dumps of updates in supposedly stable releases become an official selling point of Fedora? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/02/2010 06:06 PM, Björn Persson wrote: Jesse Keating wrote: On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote: Kevin Kofler wrote: Even bugfix releases of KDE require a session restart to fully work. I consider that a serious design flaw in KDE and a strong argument against releasing any KDE updates to stable releases other than fixes for serious bugs. The only practical way to keep up with the Fedora update firehose is to update every day and let the update run in the background while I'm working. If I put it off until I'm about to turn the computer off, then the updates will accumulate and updating will take a long time when I finally do it. I might not have the time to sit around and wait for the update to finish so that I can turn the computer off, so I'll put it off again, and when the next opportunity comes the list of updates will have grown even more. That's a vicious circle I don't want to get into. We do need a apply all updates and shut down option. That doesn't help much if I'm going to pack the laptop up in a bag and take it with me. I'll still have to sit there and twiddle my thumbs while it updates. I wonder if something like the windows download updates and inform me when you've downloaded them crossed with the pre-upgrade type system could solve your use case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Chris Adams wrote: Who is this we you keep speaking of? When did huge dumps of updates in supposedly stable releases become an official selling point of Fedora? It just happened, de facto. Probably because it's filling a niche other distros are ignoring. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Chris Adams wrote: Who is this we you keep speaking of? When did huge dumps of updates in supposedly stable releases become an official selling point of Fedora? It just happened, de facto. Probably because it's filling a niche other distros are ignoring. Who is the we? There are a number of people objecting to your interpretation that are not happy with the current situation. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Seth Vidal wrote: I do not agree Kevin's view is incumbent. I think what's happened is we exploded in size when extras came in and when we merged core and extras and we lost control over the process and over assimilating what was the CORE process onto extras. But the Core process wasn't as conservative as you seem to think. KDE updates have always been pushed, e.g. FC4 was upgraded from 3.4 to 3.5, and bugfix updates have also always been pushed. But even assuming the Extras process won over the Core one, that just shows that the Extras process was better. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On 03/02/2010 08:55 PM, Matthew Woehlke wrote: Jesse Keating wrote: On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote: You and everyone else, please stop proposing Rawhide as the solution for me and people who want the same update everything that doesn't break things policy, it does NOT fit our usecase at all! If you don't like rawhide for that use case, find another operating system. I'm tired of our stable releases getting tonnes of updates. I'm tired of what F11 shipped like being completely different today. I'm tired of waiting for many many hours while we try to compose out the 3444 individual updates in F11 stable. (that's right, 3444 srpms worth of updates. F11 only had 7446 srpms to begin with!!). This is not the style of distribution I wish to produce or consume. If this is the style of distribution you wish to produce or consume, then I encourage you to go find another distribution or start your own. Okay, I have to ask: why are you right and Kevin is wrong? What makes your vision of Fedora more worthy than his? (Especially when his is the apparent incumbent?) And especially given that he cited as many things as he did in Fedora docs about doing things the way he does. Unfortunately, there are people on both sides of this fence and making Fedora a one size fits all distribution will necessarily piss off one group or the other. Which is why I said in a previous email that I would prefer the bugfixes/backports split that Mandriva has because that allows you to satisfy both sides of the fence. I saw this train a comin'. We might could compromise along the lines of what I wrote in that email in terms of splitting which packages are update happy and which are considered stable among some line that would satisfy the majority of people, but I really think you need two update streams to fully satisfy people. That or we would have to go with another alternative entirely. People have (well, to be fair mainly James, but he's right I think) pointed Kevin at rawhide time and time again. And Kevin has pointed out (also rightly) that rawhide isn't really consumable. So, we fix that. We make rawhide consumable, you make rawhide the thing that people track if they want continuous rolling updates, and you make the actual releases more stable. How would you make rawhide consumable you ask? Ah, well, I'll make the following, totally out of my ass and probably not feasible proposal: Along the lines of no frozen rawhide, a new rawhide-testing repo is created. By default, all builds from devel go into rawhide (gothca didn't I, you thought I was going to send them to rawhide-testing but I'm not ;-). However, we have a set of automated tools that check for things like dependency breakage, API changes, etc. (maybe using rpmdiff or the like). If those tests trip positive, then the package is moved from rawhide to rawhide-testing. Alternatively, a developer can build directly into rawhide-testing for known disruptive changes like soname bumps and the like. That way rawhide-testing becomes a staging area. We both encourage maintainers pushing changes they know to be disruptive to build there, plus we have tools that will catch some classes of disruption and move them there. Once a package gets caught up in rawhide-testing, the way to get back out and into rawhide is to fix the disruptive change. If the change was an sobump, then in addition to the package itself, we would need rebuilds of all the dependent packages in rawhide-testing so that they can be pushed en masse. The solution would be dependent on the type of breakage the package was found to cause, but the general idea is to stage the changes here until they are ready to hit rawhide all at once and in a way that doesn't break the consumability of rawhide. I would maintain nightly pushes of rawhide packages, but might make the rawhide-testing - rawhide thing only happen on an as-needed basis (and hopefully that won't be too often, maybe no more than once a week on the high side I would guess, but that number's totally out of my ass). Then there are the releases. You wean back the updates in stable releases to things that are actually necessary. I admit I have filed updates myself that weren't really necessary except they helped me keep everything straight in my head. So, what does actually necessary mean? I guess that's up to discussion, but I would throw in my points: 1) Bug fixes and security updates (no one would argue these shouldn't be sent out) 2) Enhancements? Dunno...are people requesting the enhancement, or are you just throwing it in to keep F-11/F-12/F-13 the same so you don't have to think about what's different between them like I sometimes do? I think there's a bit of wiggle room here. Some things I could see saying yes to, others no. 3) Wholesale upstream updates? Dunno, see #2. Some of us like Fedora just fine the way it is, and don't want to see it change to match your vision. Fair
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Jesse Keating wrote: Except there aren't enough key people available on the weekend to clean up the crap if something goes wrong. On the other hand, several of our volunteer packagers are more likely to be around and have time to fix things on the weekend than during workdays. (I was one of those too when I was still having busy weeks of studying at the university. These days I'm on a flexible work schedule and there's hardly any difference between weekdays and weekends for me.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Chris Adams wrote: Who is the we? What I said was We're filling a niche as in Fedora is filling a niche. This is not saying who is behind that (I'd say it just de facto happened, without anybody in particular initiating the process) nor whose niche is being filled (which shouldn't matter, as long as it's SOMEBODY's niche we're filling). There are a number of people objecting to your interpretation that are not happy with the current situation. That doesn't change the fact that we're filling a unique niche and that we'd be throwing away that unique strength by chaning our position on this point. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 3 Mar 2010, Kevin Kofler wrote: Seth Vidal wrote: Again, I fail to see that mess. To me we're actually doing a great job! We've made a mess and as a member of fesco I'd expect you to be helping in cleaning up the mess, not making it worse b/c fesco HAS to be about the long term growth and sustainability of fedora. Sorry, but I don't see how the current situation would not be sustainable or would impede growth in the long term, it has worked perfectly fine for years. On the contrary, I think losing one of our biggest points of distinction from other distributions would be a serious impediment to long term growth and sustainability of Fedora. Take a look at our trajectory package-wise and updates-wise. Good luck with your belief we can sustain this path for very long. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: What I said was We're filling a niche as in Fedora is filling a niche. This is not saying who is behind that (I'd say it just de facto happened, without anybody in particular initiating the process) nor whose niche is being filled (which shouldn't matter, as long as it's SOMEBODY's niche we're filling). There seem to be a number of users that don't like the rapidly multiplying updates; it would appear that Fedora's success is in spite of this, not because of it. But hey, if KDE is going to continue to get multiple major updates per release, then KDE updates shouldn't be listed as a release feature or in the release notes. If you install with a network connection and the updates repo enabled, there's apparently no telling what KDE version you'll end up with. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, 2010-03-03 at 02:52 +0100, Kevin Kofler wrote: Such as? We're filling a niche, this is one of our unique selling points, you want to throw out the baby with the bathwater! Your baby is my bathwater. I don't want the operating system you're trying to build. If you feel that there is a niche here for what you're trying to build, then it shouldn't be hard for you to find like minded people to stake out your own piece of the linux user pie. I wish you luck with that. I'm tired of waiting for many many hours while we try to compose out the 3444 individual updates in F11 stable. The fact that it takes hours is really a failure of our mash process. Extras managed to deal with this in a much more efficient way: they pushed only the new stuff and then had scripts to clean out the old stuff (and a process to request manual deletion if old stuff was not being cleaned out for some reason). How much old stuff was in the repo was mostly irrelevant for the time a push took. Extras had significantly fewer packages, no multilib, no deltarpms, no update metadata, fewer arches, and was ran on different hardware. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
