Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Wed, Sep 8, 2010 at 8:25 PM, Rodd Clarkson r...@clarkson.id.au wrote: I've already tried this kernel and doesn't fix things for me. I'm now having (what I suspect are) the same suspend issues in both f13 and f14. It's being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=628897 I've made a couple of suggestions based on research using google for bugs that look similar to mine, and I'm awaiting some feedback from the kernel guys. I've been trying kernels from other distros and while ubuntu is still using 2.6.32, opensuse 11.3 is using 2.6.34 and this kernel works for me with regard to suspend and resume. How can I compare this kernel with the kernels in fedora13 to see what's different? Or is this to big a job? Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On 09/12/2010 05:00 AM, Adam Williamson wrote: Actually, I suspect it's a result of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=630490 until the fix for that gets pushed, in F14, if you use systemd and 'disable' NetworkManager.service, NM will still get started up by bus activation, hence you'll get the bad behaviour. Well, I reported that bug. In that case, removing NM completely is a workaround. My problem is that I have a specific USB modem (Reliance) which doesn't work with NM. So I have to resort to using wvdial at home but prefer using NM at work and don't want to remove it. If you are not using NM at all, simply removing it is acceptable. Rahul -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On Fri, 2010-09-10 at 23:55 +0530, Rahul Sundaram wrote: On Fri, Sep 10, 2010 at 10:03 AM, Bruno Wolff III wrote: On Thu, Sep 09, 2010 at 16:23:12 -0500, John Morris jmor...@beau.org wrote: On Thu, 2010-09-09 at 00:14 -0500, Bruno Wolff III wrote: On Wed, Sep 08, 2010 at 23:18:00 -0500, John Morris jmor...@beau.org wrote: And of course Network-Manager isn't optional anymore. Oh no, you can't That is not the behavior I see. I run desktops without NetworkManager running (but installed) and there is no problem with firefox. (I don't use evolution or empathy.) Same observation here. I think if you leave NM enabled but it is not connected yet for some reason, you will see the offline behavior reported by John Morris. Otherwise his rant is inaccurate. Actually, I suspect it's a result of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=630490 until the fix for that gets pushed, in F14, if you use systemd and 'disable' NetworkManager.service, NM will still get started up by bus activation, hence you'll get the bad behaviour. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
So now I lost the only kernel package where everything worked. And of course Fedora doesn't have it anymore. You can pick the original package or the current update. Triple crap! If anyone has a pointer to kernel-2.6.31.12-174.222.x86_64.rpm I'd really appreciate it! Google, rpmfind, etc. all come up blank as did manually poking around on the Fedora mirrors. You mean this one: http://koji.fedoraproject.org/koji/buildinfo?buildID=157491 Thanks! Was really hoping those old updates were still somewhere out there. Really hate self inflicted wounds, nice to know it wasn't terminal. Especially since someone else just joined my bug with the bad news that F13 does have the same problem. Looks like I'm going to be stuck with F12 and that one working kernel for a while yet. Not sure what the plan is when the next major security problem pops after F12 goes unsupported but there is still a couple of months until that problem becomes acute. I hoped venting helped you, but this is not the way to move things forward. I'd suggest more help testing, good bug reports.. Dunno, reported this one in March and it is still in NEW state. Reported #563417 in Feb and it is also in the NEW state. Thankfully I could work around it by binding a script to CTRL-F7 to fire blindly that looks at the state of the dock and manually launches some xrandr commands to force things into shape. The panel picks up on dynamic changes in screen geometry just fine so force it down to 1024x768, wait a second or two for it to reappear then resize to the current attached primary panel's size. Not ready for Grandma but that one doesn't bother me as much as some of the things I was ranting about because it is a bug in something that is clearly a new feature. The agility of xrandr has been amazing to watch over the last few years. Hopefully all the other bits like the panel will catch up in another rev or two. And maybe the system will even get smart enough to remember where you put the displays and restore that when the same external monitor is reattached. Closer to my original rant is the snarky observation that the Gnomes probably won't ever get around to fixing such a minor problem because they are too busy ripping and replacing the whole desktop with an entirely new set of bugs to care about fixing the few bugs in the current code that is set to get tossed out anyway. The problem I was ranting about is more about a growing fear of upgrading, or heck, even taking patches for fear the bug being fixed (which most of the time isn't actually biting ya) or feature improvement (which you probably don't need) will also break your system. What if a critical mass of users decide that once they manage to get their system working that the only safe course of action is to then disable all updates. If a bug does start biting hard check to see if that one package can be updated without dragging in lot of deps, otherwise stay put until hardware replacement time. Where does that leave things? If normal users stop taking even the updates how does wide scale testing happen? I have 'beater' machines, I have QEMU, etc. You probably have similar. Most people don't. This isn't just a thought experiment; Microsoft already faced the same problem and got around it by making Windows Update (all but) mandatory. How many people are still on XP? How many IE6 hits are in your server logs? signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On Thu, 2010-09-09 at 00:14 -0500, Bruno Wolff III wrote: On Wed, Sep 08, 2010 at 23:18:00 -0500, John Morris jmor...@beau.org wrote: And of course Network-Manager isn't optional anymore. Oh no, you can't You can still run the network service. You use chkconfig to turn it on. If you don't need wireless, turning off NetworkManager doesn't seem to be a problem, but it's also possible to run both at the same time. No it isn't. If NM isn't managing a connection to the Internet then Firefox (fixable), Evolution, Empathy and almost certainly other apps go into offline mode. You can still run a server without NetworkManager but a desktop install now requires that it be installed and managing your connection. Been there, tried that and have the t-shirt. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On Thu, Sep 09, 2010 at 04:23:12PM -0500, John Morris wrote: On Thu, 2010-09-09 at 00:14 -0500, Bruno Wolff III wrote: On Wed, Sep 08, 2010 at 23:18:00 -0500, John Morris jmor...@beau.org wrote: And of course Network-Manager isn't optional anymore. Oh no, you can't You can still run the network service. You use chkconfig to turn it on. If you don't need wireless, turning off NetworkManager doesn't seem to be a problem, but it's also possible to run both at the same time. No it isn't. If NM isn't managing a connection to the Internet then Firefox (fixable), Evolution, Empathy and almost certainly other apps go into offline mode. Really? I do not know about Evolution or Empathy and surely not about almost certainly other app but this is from two different F13 installations: # chkconfig --list NetworkManager NetworkManager 0:off 1:off 2:off 3:off 4:off 5:off 6:off Both are running desktop and firefox did not require any fixes not to go into offline mode as long as network was active. Nor I have seen so far any other problems. It may help if you will make desired network interfaces explicitely not NM controlled as by default they are. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Tue, Sep 7, 2010 at 10:56 PM, Jan Wildeboer jwild...@redhat.com wrote: On 09/07/2010 02:45 PM, drago01 wrote: http://koji.fedoraproject.org/koji/buildinfo?buildID=193772 This one addresses some suspend issues so it is worth testing. Bingo! Suspend/resume now works again. (Still have to do a service NetworkManager restart after resume some times, minor to me) I've already tried this kernel and doesn't fix things for me. I'm now having (what I suspect are) the same suspend issues in both f13 and f14. It's being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=628897 I've made a couple of suggestions based on research using google for bugs that look similar to mine, and I'm awaiting some feedback from the kernel guys. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On Wed, 2010-09-08 at 23:18 -0500, John Morris wrote: Sorry everyone, time to vent. Bah. This is why I just blocked kernel updates in the first place. Tried updating now things are worse due to a bad combination of Fedora policy multiplied by my own stupidity. I KNEW you were supposed to make darned sure you were running your favorite kernel before letting yum loose. (Don't ask, long story) That was mistake number one. Number two came when I looked to the backup server and found to my horror I fumbled that too, / and /home safely backed up but no /boot! Double crap! So now I lost the only kernel package where everything worked. And of course Fedora doesn't have it anymore. You can pick the original package or the current update. Triple crap! If anyone has a pointer to kernel-2.6.31.12-174.222.x86_64.rpm I'd really appreciate it! Google, rpmfind, etc. all come up blank as did manually poking around on the Fedora mirrors. yum install yum-plugin-local then every pkg you install or update on your system will be saved to a local repo and will be available to you via that repo. it sucks the disk space up, obviously but you can clean it up at your leisure. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. / Every OS sucks!
On Wed, 08 Sep 2010 23:18:00 -0500 John Morris jmor...@beau.org wrote: On Mon, 2010-09-06 at 23:05 -0400, Chuck Ebbert wrote: On Thu, 02 Sep 2010 18:23:01 -0500 John Morris jmor...@beau.org wrote: In my case I reported #573135 back in March and stopped taking kernel updates. In another month or so I'll boot a live USB stick of F14 and see if the bug was fixed and just didn't get closed. Then it is either suck it up and run without security fixes or jump distros. And in the meantime these patches went into the F12 kernel via 2.6.32-stable, but you weren't even checking the updates: Sorry everyone, time to vent. Bah. This is why I just blocked kernel updates in the first place. Tried updating now things are worse due to a bad combination of Fedora policy multiplied by my own stupidity. I KNEW you were supposed to make darned sure you were running your favorite kernel before letting yum loose. (Don't ask, long story) That was mistake number one. Number two came when I looked to the backup server and found to my horror I fumbled that too, / and /home safely backed up but no /boot! Double crap! So now I lost the only kernel package where everything worked. And of course Fedora doesn't have it anymore. You can pick the original package or the current update. Triple crap! If anyone has a pointer to kernel-2.6.31.12-174.222.x86_64.rpm I'd really appreciate it! Google, rpmfind, etc. all come up blank as did manually poking around on the Fedora mirrors. You mean this one: http://koji.fedoraproject.org/koji/buildinfo?buildID=157491 ? ...snip screed... I'm sorry, I hoped venting helped you, but this is not the way to move things forward. I'd suggest more help testing, good bug reports... get involved. Long rambling rant posts are not likely to help... kevin signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Tue, Sep 7, 2010 at 1:20 PM, Rodd Clarkson r...@clarkson.id.au wrote: , there's no way in hell that anything with ~10,000 unreviewed patches Err they aren't unreviewed as upstream did review them, it just does not make sense to review every single patch downstream too (besides obviously there is no man power for that). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Sat, 2010-09-04 at 23:10 -0400, Bill Davidsen wrote: If they don't have time to look at everything, then maybe they should stop shipping kernels they haven't looked at! Really, people who needed 2.6.34 could snip rant this is not on topic for this list. please participate in the existing discussions on -devel, or with the Board and FESCo. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Sun, 2010-09-05 at 13:25 -0400, Jan Wildeboer wrote: In my case (F13, x86_64 on a Lenovo X200) the .34 kernel made suspend fail. On laptops I think working suspend/resume should be blocker for release. It It isn't. We can't possibly guarantee suspend/resume will work on all laptops in anything like a reasonable timeframe. if we set this as a release criterion, we would likely never release. So we don't. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 09/07/2010 02:32 PM, Adam Williamson wrote: It isn't. We can't possibly guarantee suspend/resume will work on all laptops in anything like a reasonable timeframe. if we set this as a release criterion, we would likely never release. So we don't. Understood. It is however a royal PITA ;-) In the beginning, F13 was unable to use the external VGA at all in a decent manner, this started to work after a few kernel updates. So I was a happy camper. The .34 kernel starts to suspends, switches to the spalsh screen and the gets stuck. I didn't notice the first time, so after two hours I had a wonderful sauna in my laptop bag and a broken fan. Now I am back on the previous kernel and can only hope the next update will fix it. Will try once again to catch as many inof as possible and file a BZ. Jan -- Jan H Wildeboer| EMEA Open Source Affairs | Office: +49 (0)89 205071-207 Red Hat GmbH | Mobile: +49 (0)174 33 23 249 Technopark II, Haus C | Fax:+49 (0)89 205071-111 Werner-von-Siemens-Ring 11 -15 | 85630 Grasbrunn| _ Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, Werner-von-Siemens-Ring 11 -15 85630 Grasbrunn, Handelsregister: Amtsgericht Muenchen HRB 153243 Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera _ GPG Key: 3AC3C8AB Fingerprint: 3D1E C4E0 DD67 E16D E47A 9564 A72F 5C39 3AC3 C8AB -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Tue, Sep 7, 2010 at 2:36 PM, Jan Wildeboer jwild...@redhat.com wrote: On 09/07/2010 02:32 PM, Adam Williamson wrote: It isn't. We can't possibly guarantee suspend/resume will work on all laptops in anything like a reasonable timeframe. if we set this as a release criterion, we would likely never release. So we don't. Understood. It is however a royal PITA ;-) In the beginning, F13 was unable to use the external VGA at all in a decent manner, this started to work after a few kernel updates. So I was a happy camper. The .34 kernel starts to suspends, switches to the spalsh screen and the gets stuck. I didn't notice the first time, so after two hours I had a wonderful sauna in my laptop bag and a broken fan. Now I am back on the previous kernel and can only hope the next update will fix it. Will try once again to catch as many inof as possible and file a BZ. http://koji.fedoraproject.org/koji/buildinfo?buildID=193772 This one addresses some suspend issues so it is worth testing. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Tue, 2010-09-07 at 14:36 +0200, Jan Wildeboer wrote: On 09/07/2010 02:32 PM, Adam Williamson wrote: It isn't. We can't possibly guarantee suspend/resume will work on all laptops in anything like a reasonable timeframe. if we set this as a release criterion, we would likely never release. So we don't. Understood. It is however a royal PITA ;-) In the beginning, F13 was I know. It's not a perfect world. :P unable to use the external VGA at all in a decent manner, this started to work after a few kernel updates. So I was a happy camper. The .34 kernel starts to suspends, switches to the spalsh screen and the gets stuck. I didn't notice the first time, so after two hours I had a wonderful sauna in my laptop bag and a broken fan. I have the same problem with this laptop running F14, oddly. Haven't found the exact point at which it broke, yet, I'll have to work back through some old kernels. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
In my case (F13, x86_64 on a Lenovo X200) the .34 kernel made suspend fail. On laptops I think working suspend/resume should be blocker for release. It worked before, hence it is a regression. F13 was released with a .33 kernel, therefore the question of blocking the F13 release for this reason did not arise. I presume you question whether F13's update to kernel .34 should have ocurred. Was the suspend problem recognized before the .34 kernel release? Did this kernel fix other issues that might be judged more important than suspend/resume? Did suspend fail for all equipment? Rare configurations? A different set of machines (yours and others that used to work, failed; different models that used to fail now worked)? Maybe Bugzilla has some data, but it might not be a simple issue. In any case, fallback to an earlier, installed kernel that works is easy. Without the wider testing and QA process that goes into a numbered Fedora release, I am not surprised an incremental kernel broke something. With kernels, and most other packages, I think there is some presumption that upstream testing and development has combined elements in a way that makes sense, that balances benefit against risk, that may mix faults with fixes to achieve a net positive effect. Sometimes this simply is not true, but I doubt the person upstream who decides to release an update believes it is false. It would be nice to not have regressions, but an effort such as Fedora that seeks to deliver quickly the latest software technology cannot, in my opinion, avoid them. If regressions or other faults occur too often, the protocol for distribution of Fedora updates might be improved. Consensus about a precise definition of too often may be difficult. This interest list often contains laments from users that update X, which fixes their problem, is not available in a Fedora repository, often because the update has not acquired sufficient positive test results. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, 2 Sep 2010 15:19:04 +1000 Rodd Clarkson r...@clarkson.id.au wrote: Might I ask what great good has come from this? Here's a list of bugs that were fixed by the 2.6.34 update and not by any specific fixes added by Fedora: 611123 - 2.6.33.5-124 on Dell E521 does not work with OCZ Vertex SSD drive 607851 - No sound in Sony Vaio VPCEB15FM Realtek ALC269, snd-hda-intel driver 581590 - ath9k disconnects frequently with F13 beta on AR5008 623954 - First line of screen remains black except for a few pixels 627664 - Kernel restarts shortly after being suspended 546693 - RTL8101E and RTL8187SE driver incompatibility 570291 - Bluetooth mouse laggy in use 510693 - Unable to use wol (wake on lan) on Marvell Yukon 88E8056 (sky2) 570901 - Failed suspend on 1201n causes severe over-heating, machine cut-off 615689 - Dead Screen after awake from suspend 577464 - pci :00:00.0: address space collision 583223 - network does not work after a reboot -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, 02 Sep 2010 18:23:01 -0500 John Morris jmor...@beau.org wrote: In my case I reported #573135 back in March and stopped taking kernel updates. In another month or so I'll boot a live USB stick of F14 and see if the bug was fixed and just didn't get closed. Then it is either suck it up and run without security fixes or jump distros. And in the meantime these patches went into the F12 kernel via 2.6.32-stable, but you weren't even checking the updates: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.10: commit 6279896e0d676c172f50c046064f889185382eac Author: Henrique de Moraes Holschuh h...@hmh.eng.br Date: Thu Feb 25 21:28:56 2010 -0300 thinkpad-acpi: document HKEY event 3006 http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.12: commit 1b0d63f15fb79d0cb840f8b701f343548b5640e8 Author: Henrique de Moraes Holschuh h...@hmh.eng.br Date: Thu Feb 25 22:22:22 2010 -0300 thinkpad-acpi: lock down video output state access commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream. Given the right combination of ThinkPad and X.org, just reading the video output control state is enough to hard-crash X.org. There really needs to be a change of attitude from Ooh! Shiny! Ship it! to not shipping new until it at least does everything the old did and reverting when serious bugs appear and can't be quickly patched. Yes I realize I'm suggesting something that will result in new stuff taking longer to arrive. You're suggesting something that will result in no kernel update ever being shipped, not even from the -stable kernel series, because even that has caused some regressions. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Sat, 04 Sep 2010 23:10:11 -0400 Bill Davidsen david...@tmr.com wrote: If they don't have time to look at everything, then maybe they should stop shipping kernels they haven't looked at! Really, people who needed 2.6.34 could pull it from updates-untested and the rest of us could have working systems. I'm not sure what you're suggesting here. Should we be reviewing the ~10,000 patches that go into a new kernel? Testing it on thousands of different combinations of hardware? 2.6.34 went through several rounds in updates-testing before being released. And let's face it, suspend has always been a problem and probably always will, given the number of different BIOS and firmware bugs it needs to work around. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
Bill Davidsen david...@tmr.com wrote: If they don't have time to look at everything, then maybe they should stop shipping kernels they haven't looked at! Really, people who needed 2.6.34 could pull it from updates-untested and the rest of us could have working systems. Back in the FC3-4-5-6 days stuff released seemed to work, but in the last two years there have been more and more things shipped which broke existing installations. It feels like there is more effort to get lots of stuff out fast even if it doesn't work, if it breaks things for users, etc. ... This is alpha test, and one objective should be to get wider testing of new kernels (and other software) in order to have experience that directs the choice of what to ship in the scheduled release. However stable they may be, there is a downside to a choice to keep old versions of software: upstream maintenance and testing will focus on the latest code, and users are typically told Upgrade to the latest release, which fixes your bug. If Fedora chooses to keep an old kernel or other component, it incurs what can become a serious maintenance cost to fix problems in what has become the Fedora version of software. Of course, there is a balance here. Fedora intentionally chooses to favor new software and technology, and a very aggressive release schedule. Fedora caters to software developers and users who want the latest code, and provides a vehicle to deliver this technology to a wide community of users. For users who want software where the focus is on stable environment, longevity, and more predictable support, Red Hat offers several products that have been praised by users. Other organizations also offer Linux products that addres these goals. Your question is reasonable: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. but I think it has been answered correctly and well. In the larger sense Does Fedora achieve a good balance between new function and bugs fixed relative to regression problems and old bugs? I think the popularity of Fedora answers that affirmatively. Were more bugs shipped in F13 than with F3-4-5-6? Probably, but the code base is much larger and the release schedule more aggressive. Also, with many more Fedora users, more bugs are likely to be observed. Nevertheless, there is certainly opportunity to ship fewer bugs in a release. We may not be able to do a lot about code quality from upstream (aside from choices about what function to include in Fedora) but release testing is where bugs can be identified, and where your efforts and those of others do improve the quality of a release. And sometimes, however uncomfortable it is, a release schedule forces choices between alternatives that all contain problems. A delay in release date may help sort out critical problems, but is no panacea - it simply changes the problem set. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
In my case (F13, x86_64 on a Lenovo X200) the .34 kernel made suspend fail. On laptops I think working suspend/resume should be blocker for release. It worked before, hence it is a regression. Note that I am not running rawhide. Just plain F13 with its support promise. Suspend/Resume failing is a problem for me. The X200 is not that uncommon (at leat inside Red Hat). I am forec to boot into the older kernel to work. Jan - Original Message - From: test-boun...@lists.fedoraproject.org test-boun...@lists.fedoraproject.org To: For testers of Fedora development releases test@lists.fedoraproject.org Cc: test@lists.fedoraproject.org test@lists.fedoraproject.org Sent: Sun Sep 05 10:24:38 2010 Subject: Re: Why was a kernel-2.6.34 pushed to updates that had un-addressedbugs.Bill Davidsen david...@tmr.com wrote: If they don't have time to look at everything, then maybe they should stop shipping kernels they haven't looked at! Really, people who needed 2.6.34 could pull it from updates-untested and the rest of us could have working systems. Back in the FC3-4-5-6 days stuff released seemed to work, but in the last two years there have been more and more things shipped which broke existing installations. It feels like there is more effort to get lots of stuff out fast even if it doesn't work, if it breaks things for users, etc. ... This is alpha test, and one objective should be to get wider testing of new kernels (and other software) in order to have experience that directs the choice of what to ship in the scheduled release. However stable they may be, there is a downside to a choice to keep old versions of software: upstream maintenance and testing will focus on the latest code, and users are typically told Upgrade to the latest release, which fixes your bug. If Fedora chooses to keep an old kernel or other component, it incurs what can become a serious maintenance cost to fix problems in what has become the Fedora version of software. Of course, there is a balance here. Fedora intentionally chooses to favor new software and technology, and a very aggressive release schedule. Fedora caters to software developers and users who want the latest code, and provides a vehicle to deliver this technology to a wide community of users. For users who want software where the focus is on stable environment, longevity, and more predictable support, Red Hat offers several products that have been praised by users. Other organizations also offer Linux products that addres these goals. Your question is reasonable: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. but I think it has been answered correctly and well. In the larger sense Does Fedora achieve a good balance between new function and bugs fixed relative to regression problems and old bugs? I think the popularity of Fedora answers that affirmatively. Were more bugs shipped in F13 than with F3-4-5-6? Probably, but the code base is much larger and the release schedule more aggressive. Also, with many more Fedora users, more bugs are likely to be observed. Nevertheless, there is certainly opportunity to ship fewer bugs in a release. We may not be able to do a lot about code quality from upstream (aside from choices about what function to include in Fedora) but release testing is where bugs can be identified, and where your efforts and those of others do improve the quality of a release. And sometimes, however uncomfortable it is, a release schedule forces choices between alternatives that all contain problems. A delay in release date may help sort out critical problems, but is no panacea - it simply changes the problem set. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
Adam Williamson wrote: On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote: It is however, perfectly reasonable to expect that having tried a kernel at the request of a fedora developer on fedora-test-list and then having filed a bug against said kernel reporting problems, that someone might actually have a few minutes required to actually ask a few more questions and try and address the problem. Otherwise, why did they ask for feedback if it was just to be ignored? To be frank, they don't have time to look at everything, and suspend is a bit of a way down the list. They are aware of your bug - I know because one of the kernel team asked me if I was aware of any problems with 2.6.34 more serious than suspend issues, so obviously they've seen yours, but haven't had time to respond to it yet. If they don't have time to look at everything, then maybe they should stop shipping kernels they haven't looked at! Really, people who needed 2.6.34 could pull it from updates-untested and the rest of us could have working systems. Back in the FC3-4-5-6 days stuff released seemed to work, but in the last two years there have been more and more things shipped which broke existing installations. It feels like there is more effort to get lots of stuff out fast even if it doesn't work, if it breaks things for users, etc. I doubt many people would lose bladder control if the next release was slipped a month so the regressions in the recent stuff could be fixed. The video drivers are another example, about half the systems which worked on FC9 have broken video on FC13, and the same goes for getting every new this and that in FC14, aren't there responsible adults who either limit the feature set or slip the release? Someone like Linus who is willing to say enough. Remember the old commercial We will ship no wine before its time? FC14 needs to mellow and FC13 is turning to vinegar. At least this time I'm not the first or only unhappy user. -- Bill Davidsen david...@tmr.com We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
- Original Message From: Bill Davidsen david...@tmr.com To: For testers of Fedora development releases test@lists.fedoraproject.org Sent: Sat, September 4, 2010 10:10:11 PM Subject: Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs. Adam Williamson wrote: On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote: It is however, perfectly reasonable to expect that having tried a kernel at the request of a fedora developer on fedora-test-list and then having filed a bug against said kernel reporting problems, that someone might actually have a few minutes required to actually ask a few more questions and try and address the problem. Otherwise, why did they ask for feedback if it was just to be ignored? To be frank, they don't have time to look at everything, and suspend is a bit of a way down the list. They are aware of your bug - I know because one of the kernel team asked me if I was aware of any problems with 2.6.34 more serious than suspend issues, so obviously they've seen yours, but haven't had time to respond to it yet. If they don't have time to look at everything, then maybe they should stop shipping kernels they haven't looked at! Really, people who needed 2.6.34 could pull it from updates-untested and the rest of us could have working systems. Back in the FC3-4-5-6 days stuff released seemed to work, but in the last two years there have been more and more things shipped which broke existing installations. It feels like there is more effort to get lots of stuff out fast even if it doesn't work, if it breaks things for users, etc. I doubt many people would lose bladder control if the next release was slipped a month so the regressions in the recent stuff could be fixed. The video drivers are another example, about half the systems which worked on FC9 have broken video on FC13, and the same goes for getting every new this and that in FC14, aren't there responsible adults who either limit the feature set or slip the release? Someone like Linus who is willing to say enough. Remember the old commercial We will ship no wine before its time? FC14 needs to mellow and FC13 is turning to vinegar. At least this time I'm not the first or only unhappy user. -- - End of Original Message I am actually dissapointed that Fedora which had a reputation of living on the edge is not actually doing so. A 2.6.34 based kernel when 2.6.35.4 is the current kernel? If I want a recent kernel, I have to do so by compiling and installing myself and not depend on Fedora for doing it. I wonder what it is happening and when they release a kernel, it breaks a good deal of things :( *NOTE* On Fedora 13 x86_64 the 2.6.34 based kernel is running OK, but it is a regular desktop, I have yet to install it on a Laptop I have. On Fedora 12, a 2.6.32.X kernel is still being used? No 2.6.34 yet. I am hoping that Fedora will surprise everyone with releasing a 2.6.36 kernel (when it is released), there might be a shortage of testers? I am still a happy Fedora user, but with no internet connection at work, I have not helped in testing Rawhide/Fedora 14 Regards, Antonio -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 02/09/10 03:58, Adam Williamson wrote: Because there are always suspend issues, kernel team doesn't consider suspend problems a blocker for release. This is really sad; just a few Fedora releases suspended and resumed fine right of the box on my T43 Thinkpad, F 13 belonged to them. I really favor suspend/resume over shutdown/reboot esp. on a notebook computer. As you can see, there is some interest in this feature. I'd really appreciate, if suspend/resume could be ranked higher. Matthias -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 3:55 PM, pbrobin...@gmail.com pbrobin...@gmail.comwrote: On Thu, Sep 2, 2010 at 3:12 AM, Rodd Clarkson r...@clarkson.id.au wrote: My system suspends and resumes fine on f13 with the 2.6.33 kernels, so it isn't unreasonable to expect this functionality to continue on a stable release. On the other hand the 2.6.34 kernel has made my F-13 laptop 100% more usable than the entire release. I've been having massive issues and I've been actually meaning to reinstall F-12 but haven't actually had the time to do so. It got pushed from updates-testing to updates very quickly because a lot of people tested it before it even hit updates-testing and hence got the karma required to go through to updates very quickly. Ah, and here I guess lies the problem. The email from the fedora engineers (some weeks ago) quite clearly stated not to give this kernel karma points so that it didn't get pushed until they were sure it wouldn't cause issues, so I haven't been giving it negative karma as a result. I'm really not happy with this entire process. I've also received an email saying that my 99 votes have been removed because someone at fedora decided to change the rules regarding my bug and voting and that my votes don't count any more. What a way to run an election. Anyhow, what a waste of time all around. I spend a couple of painful hours booting and rebooting my system to try and isolate this bug and the developers couldn't take two minutes to mention that they needed to post the kernel and that they would address my bug some time soon. R. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 02/09/10 08:29, Rodd Clarkson wrote: Anyhow, what a waste of time all around. I spend a couple of painful hours booting and rebooting my system to try and isolate this bug and the developers couldn't take two minutes to mention that they needed to post the kernel and that they would address my bug some time soon. Anyhow, enough bitching. It's unlikely to change anything. Could someone tell me what I need to do to get yum to ignore kernel updates for the future. I'll put my efforts into getting f14 to suspend and resume in the hope that this will work. It may not be a high priority for the developers (on I guess desktops), but as a laptop user it's a must. R. Although I think, this is the wrong way, putting exclude=kernel-* in your /etc/yum.conf will exclude the kernel from updating. Matthias -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 4:34 PM, Matthias Runge mru...@matthias-runge.dewrote: Although I think, this is the wrong way, putting exclude=kernel-* in your /etc/yum.conf will exclude the kernel from updating. Thanks Matthias, I don't like excluding kernels either, but I don't need to be adding --exclude=kernel\* to each run of yum update until this is resolved, and since there's an open bug for this, I'll know when it's resolved because I'm following the bug. At this time I can allow the new kernels again. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
Rodd Clarkson rodd at clarkson.id.au writes: Ah, and here I guess lies the problem. The email from the fedora engineers (some weeks ago) quite clearly stated not to give this kernel karma points so that it didn't get pushed until they were sure it wouldn't cause issues, so I haven't been giving it negative karma as a result. The email probably said not to give _positive_ karma (the only kind that triggers a push) immediately, so people with problems would have a chance to provide negative karma first. I doubt there's ever a good reason to delay negative karma, when it's clear that a bug exists. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 09/02/2010 04:18 AM, Adam Williamson wrote: On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote: It is however, perfectly reasonable to expect that having tried a kernel at the request of a fedora developer on fedora-test-list and then having filed a bug against said kernel reporting problems, that someone might actually have a few minutes required to actually ask a few more questions and try and address the problem. Otherwise, why did they ask for feedback if it was just to be ignored? To be frank, they don't have time to look at everything, and suspend is a bit of a way down the list. They are aware of your bug - I know because one of the kernel team asked me if I was aware of any problems with 2.6.34 more serious than suspend issues, so obviously they've seen yours, but haven't had time to respond to it yet. I think the question is how regressions are prioritized. For me the issue is that my Radeon card has been working perfectly on F11 but had a major performance regression with F12 that makes the system too slow for regular use. I filed a bug with lots of information and a sysprof profile that shows extreme differences in behavior between the F11 system and a current F14 build but this hasn't been dealt with since I posted that profile. The result is that I'm pretty much stuck on F11 for now which is frustrating not because I expect any particular fancy features to work but because I bought this card since it was so well supported and working nicely on F11. Also the mobile version of the same gfx-chip doesn't have this issue on my notebook so I have a hunch that this isn't some major problem but something that could potentially be solved relatively quickly. What am I supposed to do in this situation? I guess I could spend another hundred bucks on a new card but then I don't know if that will loose support in the next Fedora release either. I think regressions need to be prioritized. Regards, Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
2010/9/2 Dennis J. denni...@conversis.de On 09/02/2010 04:18 AM, Adam Williamson wrote: On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote: It is however, perfectly reasonable to expect that having tried a kernel at the request of a fedora developer on fedora-test-list and then having filed a bug against said kernel reporting problems, that someone might actually have a few minutes required to actually ask a few more questions and try and address the problem. Otherwise, why did they ask for feedback if it was just to be ignored? To be frank, they don't have time to look at everything, and suspend is a bit of a way down the list. They are aware of your bug - I know because one of the kernel team asked me if I was aware of any problems with 2.6.34 more serious than suspend issues, so obviously they've seen yours, but haven't had time to respond to it yet. I think the question is how regressions are prioritized. For me the issue is that my Radeon card has been working perfectly on F11 but had a major performance regression with F12 that makes the system too slow for regular use. I filed a bug with lots of information and a sysprof profile that shows extreme differences in behavior between the F11 system and a current F14 build but this hasn't been dealt with since I posted that profile. The result is that I'm pretty much stuck on F11 for now which is frustrating not because I expect any particular fancy features to work but because I bought this card since it was so well supported and working nicely on F11. Also the mobile version of the same gfx-chip doesn't have this issue on my notebook so I have a hunch that this isn't some major problem but something that could potentially be solved relatively quickly. What am I supposed to do in this situation? I guess I could spend another hundred bucks on a new card but then I don't know if that will loose support in the next Fedora release either. I think regressions need to be prioritized. Regards, Dennis - imho , regressions should not be tolerated unless there' s a serious reason to. too many times it happened that one thing worked now but no longer worked in the next version, and this scenario keeps repeating. see k3b, qemu and gthumb, for some examples. also there are outstanding bugs, linux kernel related which are simply ignored. (like the inability to read from bios which hard disk is first, or the recently fixed security hole.) of course development means trying new things all the time, but why this is happening on releases labeled as stable, is beyond my ability to understand. -- Among the maxims on Lord Naoshige's wall, there was this one: Matters of great concern should be treated lightly. Master Ittei commented, Matters of small concern should be treated seriously. (Ghost Dog : The Way of The Samurai) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 8:29 AM, Rodd Clarkson r...@clarkson.id.au wrote: Anyhow, what a waste of time all around. I spend a couple of painful hours booting and rebooting my system to try and isolate this bug and the developers couldn't take two minutes to mention that they needed to post the kernel and that they would address my bug some time soon. Anyhow, enough bitching. It's unlikely to change anything. To be a bit more productive than bitching ... the most obvious change in .34 is async suspend/resume does disabling it help your case? echo 0 /sys/power/pm_async (as root). Should disable it. If that makes your laptop suspend/resume again please add this information to the bug. (And you can disable it on your system in lets say rc.local rather than downgrading the kernel). If it isn't that trying to find the offending driver if any using pm_trace would be the next step. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 09/02/2010 09:56 AM, Dennis J. wrote: I think the question is how regressions are prioritized. For me the issue is that my Radeon card has been working perfectly on F11 but had a major performance regression with F12 that makes the system too slow for regular use. I filed a bug with lots of information and a sysprof profile that shows extreme differences in behavior between the F11 system and a current F14 build but this hasn't been dealt with since I posted that profile. The result is that I'm pretty much stuck on F11 for now which is frustrating not because I expect any particular fancy features to work but because I bought this card since it was so well supported and working nicely on F11. Also the mobile version of the same gfx-chip doesn't have this issue on my notebook so I have a hunch that this isn't some major problem but something that could potentially be solved relatively quickly. On bug 617683 is one possible explanation on why users suffer hw regression with the kernel which hopefully will be discussed and dealt with on this years kernel summit. This firmware isn't *in* the upstream linux-firmware tree. The author of the driver in question has made his driver require a new firmware without putting that firmware *anywhere* sensible. No movement on bug reports does not necessary mean that the bugs are not being worked on. Yes in ideal world they would comment on it being looked at or what not and it's frustrated that they dont comment on the status of the bug in question and actually close bugs when they are fixed ( often that's not the case and reports get cleaned up by EOL process instead of being closed as FIXED ) however this problem goes both ways with reporters not responding to et all or do not respond in timely manner to a NEEDINFO request from maintainer, which is real problem because finally when the maintainer has reach your bug on his priority list ( As I have mentioned before reporters and triagers changing priority and severity status on a bug report means nothing to a maintainer ) and has time to look at and fix the issue at hand everything grinds to a halt because the NEEDINFO has not been responded to so he moves on and may or may not put you at the bottom at the stacks of reports to deal with. To actually see the extent and identifying problem(s) and regressions ( you could notice reporting trends with components ) and deal with it accordingly we need to gather and make public bugzilla stats for components. Making those stats public ( pretty sure you can easily gather them in bugzilla ) is more a political issue then technical one. For one we share bugzilla with Red Hat which I like since I'm using both RHEL and Fedora ( I personally would like to keep it that way ) but that sharing limits us a bit for doing things like we want it and then it's the issue with maintainers may not want to make their good or not so good bugzilla stats public.. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 09/02/2010 12:35 PM, Jóhann B. Guðmundsson wrote: To actually see the extent and identifying problem(s) and regressions ( you could notice reporting trends with components ) and deal with it accordingly we need to gather and make public bugzilla stats for components. Making those stats public ( pretty sure you can easily gather them in bugzilla ) is more a political issue then technical one. What I would like to see is a distinction between regressions and other bugs. There are a least two reasons why this might be worthwhile: 1. Regressions break functionality that has been known to work previously and the users already rely on. If new stuff gets added and has bugs that is not as serious because users are not yet relying on this to work. 2. Regressions can be easier to fix because you have a known to work case you can use as a comparison. If bugs could be flagged as regression then developers you potentially look at these first right after the regressions occurred and probably identify the reason for the regression right away. Regards, Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 2:17 PM, Dennis J. denni...@conversis.de wrote: 2. Regressions can be easier to fix because you have a known to work case you can use as a comparison. If bugs could be flagged as regression then developers you potentially look at these first right after the regressions occurred and probably identify the reason for the regression right away. It isn't that easy as you make it sound (especially for the kernel). It can up to need a git bisect but that requires being able to reproduce said bug (which might require hardware that the maintainer does not have). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
2010/9/2 drago01 drag...@gmail.com On Thu, Sep 2, 2010 at 2:17 PM, Dennis J. denni...@conversis.de wrote: 2. Regressions can be easier to fix because you have a known to work case you can use as a comparison. If bugs could be flagged as regression then developers you potentially look at these first right after the regressions occurred and probably identify the reason for the regression right away. It isn't that easy as you make it sound (especially for the kernel). It can up to need a git bisect but that requires being able to reproduce said bug (which might require hardware that the maintainer does not have). that's one of the many reasons testers' work should not just be discarded. they have a lot of hardware and a lot of time the developers can not possibly have. also they are more significant as average users since they are not special persons working for special companies. i assumed here that the average user is important, at least as important as a(ny) company. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 2:27 PM, cornel panceac cpanc...@gmail.com wrote: 2010/9/2 drago01 drag...@gmail.com On Thu, Sep 2, 2010 at 2:17 PM, Dennis J. denni...@conversis.de wrote: 2. Regressions can be easier to fix because you have a known to work case you can use as a comparison. If bugs could be flagged as regression then developers you potentially look at these first right after the regressions occurred and probably identify the reason for the regression right away. It isn't that easy as you make it sound (especially for the kernel). It can up to need a git bisect but that requires being able to reproduce said bug (which might require hardware that the maintainer does not have). that's one of the many reasons testers' work should not just be discarded. Where did I say that? they have a lot of hardware and a lot of time the developers can not possibly have. also they are more significant as average users since they are not special persons working for special companies. i assumed here that the average user is important, at least as important as a(ny) company. Well yeah if a tester actually takes the time and run a bisect and tells the developer this bug is caused by commit foo it would indeed be very helpful. I was just replying to the statement it is a regression and thus easier to fix, which isn't that simply in real world. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 09/02/2010 02:39 PM, drago01 wrote: On Thu, Sep 2, 2010 at 2:27 PM, cornel panceaccpanc...@gmail.com wrote: 2010/9/2 drago01drag...@gmail.com On Thu, Sep 2, 2010 at 2:17 PM, Dennis J.denni...@conversis.de wrote: 2. Regressions can be easier to fix because you have a known to work case you can use as a comparison. If bugs could be flagged as regression then developers you potentially look at these first right after the regressions occurred and probably identify the reason for the regression right away. It isn't that easy as you make it sound (especially for the kernel). It can up to need a git bisect but that requires being able to reproduce said bug (which might require hardware that the maintainer does not have). that's one of the many reasons testers' work should not just be discarded. Where did I say that? they have a lot of hardware and a lot of time the developers can not possibly have. also they are more significant as average users since they are not special persons working for special companies. i assumed here that the average user is important, at least as important as a(ny) company. Well yeah if a tester actually takes the time and run a bisect and tells the developer this bug is caused by commit foo it would indeed be very helpful. I was just replying to the statement it is a regression and thus easier to fix, which isn't that simply in real world. Just to clarify I didn't say that a regression *is* easier to fix but that it *can be* easier to fix due to the fact that a regression can be flagged as such, be pushed to the front of the queue sooner if only for a cursory inspection/early triaging by the developer and potentially be resolved because said developer still has a recent memory of the changes made. You'll not be able to solve the problem of dealing with regressions completely but you can at least try to improve the process. Regards, Dennis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 09/02/2010 11:16 AM, Adam Williamson wrote: There's no guarantee the bug will get closed even if the problem is fixed, unless someone else has the same hardware as you and is testing. A fix may come down from upstream without being recognized specifically as a fix for this particular Fedora bug report - a lot of stuff comes down from upstream, and there's no guarantee the kernel team will match up every upstream change to Fedora bug reports without assistance from testers. How difficult would it be for BZ to implement some kind of federations? Though some projects don't use BZ for bug tracking, I'd hope there would be willingness on maintainers of all bug tracking software to agree on a protocol for updating each other. Simply put, imagine if Alice finds a bug at company X. She files a bug report on her company BZ server. Whoever is handling in-house development sees the bug, sees that it will need an upstream fix, and kicks it upstream. Alternately, she may fix the bug, and could kick _that_ upstream, too. If the fix is made upstream, that info would get passed down to the sub-federated servers that subscribe to that component. Finally -- and this could be postponed until Version 2 ;) -- each component in each distro has it's own newsgroup in a private news hierarchy. This way, if Bob User wants to track the discussion work on a component, he can go read the newsgroup and see all the discussion going on. That's a few rough ideas. But it seems like a win to use known, tried, and true telecommunications protocols to pass discussion traffic around -- expecially if Bob User could use an nnrp client to participate in said discussion! Anyway, I could say more -- but I've probably already shown how bananas my ideas can be. Happy Thursday! :) -Scott -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, 2010-09-02 at 12:09 -0700, Scott Doty wrote: Anyway, I could say more -- but I've probably already shown how bananas my ideas can be. It's not bananas, it's just a lot of work that no-one's done yet - well, actually, it's implemented quite well in Launchpad, but most things don't use Launchpad. Patches are probably welcome ;) It's definitely something I'd like to have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, 2010-09-02 at 14:17 +0200, Dennis J. wrote: What I would like to see is a distinction between regressions and other bugs. There are a least two reasons why this might be worthwhile: 1. Regressions break functionality that has been known to work previously and the users already rely on. If new stuff gets added and has bugs that is not as serious because users are not yet relying on this to work. 2. Regressions can be easier to fix because you have a known to work case you can use as a comparison. If bugs could be flagged as regression then developers you potentially look at these first right after the regressions occurred and probably identify the reason for the regression right away. I'd like to suggest another reason regressions should get higher priority. Regressions hit people who already have Fedora installed and running and puts us in a bad place. Every install is less than a year away from being unsupported and a serious regression leaves us unable to stay on the upgrade treadmill. In my case I reported #573135 back in March and stopped taking kernel updates. In another month or so I'll boot a live USB stick of F14 and see if the bug was fixed and just didn't get closed. Then it is either suck it up and run without security fixes or jump distros. That is the difference, a bug in a bad place might stop a new user from migrating to Fedora while a regression combines with the short support cucle to force an existing user to migrate away if it exists across two releases. There really needs to be a change of attitude from Ooh! Shiny! Ship it! to not shipping new until it at least does everything the old did and reverting when serious bugs appear and can't be quickly patched. Yes I realize I'm suggesting something that will result in new stuff taking longer to arrive. At some point we really need to begin a shift away from furious development of new features into a more quality driven focus. signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On 09/01/2010 09:12 PM, Rodd Clarkson wrote: On Thu, Sep 2, 2010 at 11:58 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2010-09-02 at 11:00 +1000, Rodd Clarkson wrote: Hi all, Why was kernel-2.6.34.x pushed to updates in f13 when three people had reported suspend issues with the kernel and no attempt was made to address these issues. see: https://bugzilla.redhat.com/show_bug.cgi?id=615560 I Rodd Because there are always suspend issues, kernel team doesn't consider suspend problems a blocker for release. Sure, my problem lies not it that fact that there are suspend issues, but in that no attempt was even made to address the suspend issues. My system suspends and resumes fine on f13 with the 2.6.33 kernels, so it isn't unreasonable to expect this functionality to continue on a stable release. It is however, perfectly reasonable to expect that having tried a kernel at the request of a fedora developer on fedora-test-list and then having filed a bug against said kernel reporting problems, that someone might actually have a few minutes required to actually ask a few more questions and try and address the problem. Otherwise, why did they ask for feedback if it was just to be ignored? Rodd Updating to this kernel stops my F13 system from booting. I have had to revert to the former kernel. I have tried it each day it is offered as an update with the same result all three times. If I can provide any particular useful information, let me know. Gerry Tool -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, 2010-09-02 at 12:12 +1000, Rodd Clarkson wrote: It is however, perfectly reasonable to expect that having tried a kernel at the request of a fedora developer on fedora-test-list and then having filed a bug against said kernel reporting problems, that someone might actually have a few minutes required to actually ask a few more questions and try and address the problem. Otherwise, why did they ask for feedback if it was just to be ignored? To be frank, they don't have time to look at everything, and suspend is a bit of a way down the list. They are aware of your bug - I know because one of the kernel team asked me if I was aware of any problems with 2.6.34 more serious than suspend issues, so obviously they've seen yours, but haven't had time to respond to it yet. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 3:12 AM, Rodd Clarkson r...@clarkson.id.au wrote: On Thu, Sep 2, 2010 at 11:58 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2010-09-02 at 11:00 +1000, Rodd Clarkson wrote: Hi all, Why was kernel-2.6.34.x pushed to updates in f13 when three people had reported suspend issues with the kernel and no attempt was made to address these issues. see: https://bugzilla.redhat.com/show_bug.cgi?id=615560 I Rodd Because there are always suspend issues, kernel team doesn't consider suspend problems a blocker for release. Sure, my problem lies not it that fact that there are suspend issues, but in that no attempt was even made to address the suspend issues. My system suspends and resumes fine on f13 with the 2.6.33 kernels, so it isn't unreasonable to expect this functionality to continue on a stable release. On the other hand the 2.6.34 kernel has made my F-13 laptop 100% more usable than the entire release. I've been having massive issues and I've been actually meaning to reinstall F-12 but haven't actually had the time to do so. It got pushed from updates-testing to updates very quickly because a lot of people tested it before it even hit updates-testing and hence got the karma required to go through to updates very quickly. Peter -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
