Re: Release criterion proposal: betanag removal
A straightforward release criterion proposal: we should have a criterion just to specify that the anaconda betanag screen (and any others we put in) should be removed for final. Right now this is one of those things that's just obvious but that we ought to write down somewhere. How about, in the Final criteria, simply: * No notices or alerts about pre-release status should be present Comments, suggestions, etc? Thanks! I thought we had it, but we don't! ACKed -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: proposal for naming blocker and NTH bugs
On Wed, Nov 30, 2011 at 02:51, Andre Robatino robat...@fedoraproject.org wrote: 17Alpha 17AlphaNTH 17Beta 17BetaNTH 17Final (or alternatively 17) 17FinalNTH (or alternatively 17NTH) Why not: 17AlphaBlocker 17AlphaNTH 17BetaBlocker 17BetaNTH 17FinalBlocker 17FinalNTH ... verbosity can be such a great thing! ;) Maybe even consider expanding NTH, i.e. 17FinalNiceToHave. The more people understand without looking things up, the better. Personally, I'd stick with F17 instead of 17, but can't find any very good reason (either way) :) They field is called Blocks:, so there doesn't need to be Blocker suffix. I think this is pretty self-explanatory: Blocks: F17Beta I would also add F-prefix, it just looks better. Whether to use Andre's or Sandro's proposal, I don't care. But I agree they are more obvious than current naming scheme. The -accepted word makes you think those blockers were accepted, and it's not the case. They are just NTH. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Release criterion proposal: betanag removal
On Tue, 2011-11-29 at 18:21 -0800, Adam Williamson wrote: A straightforward release criterion proposal: we should have a criterion just to specify that the anaconda betanag screen (and any others we put in) should be removed for final. Right now this is one of those things that's just obvious but that we ought to write down somewhere. How about, in the Final criteria, simply: * No notices or alerts about pre-release status should be present Yea that might be one of those last step things that needs to be on the list before going final or at least the final spins are created. Hell, just to give it a little more time, could do it before the RC's are created since they are pretty much final. -- Mike Chambers Madisonville, KY The best town on Earth! -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Todays yum dependency update issues....
Skipped (dependency problems): boost-serializationx86_64 1.48.0-2.fc17 rawhide 158 k gvfs x86_64 1.11.0-4.fc17 fedora991 k gvfs-afp x86_64 1.11.0-4.fc17 fedora107 k kernel-debuginfo x86_64 3.2.0-0.rc3.git1.1.fc17 rawhide-debuginfo 280 M kernel-debuginfo-common-x86_64 x86_64 3.2.0-0.rc3.git1.1.fc17 rawhide-debuginfo 39 M kernel-tools-debuginfo x86_64 3.2.0-0.rc3.git1.1.fc17 rawhide-debuginfo 83 k libcddbx86_64 1.3.2-6.fc17 fedora 66 k libcdiox86_64 0.83-1.fc17 fedora252 k startup-notification x86_64 0.12-2.fc17 rawhide36 k xcb-util x86_64 0.3.8-1.fc17 rawhide13 k xorg-x11-drv-apm x86_64 1.2.3-10.fc17 fedora 56 k xorg-x11-drv-ast x86_64 0.93.9-2.fc17 fedora 36 k xorg-x11-drv-ati x86_64 6.14.3-3.2025git534fb6e41.fc17 rawhide 393 k xorg-x11-drv-cirrusx86_64 1.3.2-13.fc17 rawhide36 k xorg-x11-drv-dummy x86_64 0.3.4-9.fc17 fedora 12 k xorg-x11-drv-evdev x86_64 2.6.99-4.2010gita9cdb6590.fc17 fedora 35 k xorg-x11-drv-fbdev x86_64 0.4.2-4.fc17 fedora 16 k xorg-x11-drv-glint x86_64 1.2.6-3.fc17 fedora 78 k xorg-x11-drv-i128 x86_64 1.3.4-12.fc17 fedora 28 k xorg-x11-drv-i740 x86_64 1.3.2-11.fc17 fedora 26 k xorg-x11-drv-intel x86_64 2.17.0-3.fc17 rawhide 198 k xorg-x11-drv-keyboard x86_64 1.6.0-4.fc17 fedora 16 k xorg-x11-drv-mach64x86_64 6.9.0-4.fc17 fedora 86 k xorg-x11-drv-mga x86_64 1.4.13-11.fc17 fedora 81 k xorg-x11-drv-mouse x86_64 1.7.1-4.fc17 fedora 31 k xorg-x11-drv-nouveau x86_64 1:0.0.16-29.20110720gitb806e3f.fc17 fedora 96 k xorg-x11-drv-openchromex86_64 0.2.904-18.fc17 fedora149 k xorg-x11-drv-qxl x86_64 0.0.21-11.fc17 fedora 93 k xorg-x11-drv-r128 x86_64 6.8.1-13.fc17 fedora 50 k xorg-x11-drv-rendition x86_64 4.2.4-9.fc17 fedora 25 k xorg-x11-drv-s3virge x86_64 1.10.4-10.fc17 fedora 39 k xorg-x11-drv-savagex86_64 2.3.3-3.fc17 fedora 68 k xorg-x11-drv-siliconmotion x86_64 1.7.5-4.fc17 fedora 54 k xorg-x11-drv-sis
Re: Todays yum dependency update issues....
On Wed, 2011-11-30 at 10:37 -0600, Kevin Martin wrote: What's with the xserver-abi dependency problem (ie: xorg-x11-drv-vesa-2.3.0-11.fc17.x86_64 requires: xserver-abi(ansic-2009) = 0 -- Processing Dependency: xserver-abi(ansic-2009) = 0 for package: xorg-x11-drv-vesa-2.3.0-11.fc17.x86_64 Searching pkgSack for dep: xserver-abi(ansic-2009) I suspect I may have gotten some Obsoletes slightly wrong in the X server. rpm -qa xorg-x11-drv-\* please? - ajax 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
[Test-Announce] AutoQA Upgrade to 0.7
As a heads up, we're updating AutoQA to 0.7 today. I'm not expecting any issues during the update process but no new jobs will be run while we're updating the production systems. The update process shouldn't take much more than an hour, maybe two if we hit problems. If all goes well, you might notice a delay in results being posted to bodhi. If all doesn't go well, you'll see another email from me. Tim signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is there a need for more Xen test cases for Fedora?
On Tue, Nov 29, 2011 at 04:54:05PM -0800, Adam Williamson wrote: On Tue, 2011-11-29 at 17:47 -0700, Stephen John Smoogen wrote: On 29 November 2011 17:40, Adam Williamson awill...@redhat.com wrote: Hey, folks. I'm working through the f16 QA retrospective, and one of the suggestions is: might need improved / more Xen test cases Does this mean various DomU tests or Dom0 tests? That's sort of the question, I'm asking, really! It would be nice to expand the tests, and it kind of boils down to: 1) Does it boot 2) Does it work The complexity is that there are three modes of this: HVM (so similar to the KVM test-case), PV (we got that covered now), and the Dom0 (which is mostly - does it boot and you kind of implicitly need to do this before you can do the other two). So I think it makes sense to add the HVM case in the test-matrix - it is pretty simple and similar to the KVM one. The dom0 is a bit more complex, but we already have it outlined in the http://fedoraproject.org/wiki/Features/XenPvopsDom0 in the Documentation part - so it should be fairly easy to lift it out of there. (adn the stuff about the bridge is not needed anymore). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- 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
[Test-Announce] Very belated 2011-09 Graphics Test Week recap
I know this is horribly late, but I just worked my way around to it! Sorry for that. Here's the recap of the Fedora 16 Graphics Test Week. The overall numbers of tests done and bugs filed are down significantly, because I was very busy and did not do a great job of arranging and promoting the events this cycle. I hope we'll be able to do a better job for the Fedora 17 graphics test week. Here's the numbers on tests conducted and bugs filed. I counted each non-example line in the main results matrix as a 'test conducted'. I didn't count the runs in the 'bonus' 3D matrix, in order to provide a more fair comparison with previous releases. This might affect the bugs-to-tests ratio somewhat. f11 nouveau: 104 tests, 42 bugs - ratio 0.40 f12 nouveau: 53 tests, 34 bugs - ratio 0.64 f13 nouveau: 78 tests, 26 bugs - ratio 0.33 f14 nouveau: 39 tests, 8 bugs - ratio 0.21 f15 nouveau: 83 tests, 55 bugs - ratio 0.66 f16 nouveau: 16 tests, 8 bugs - ratio 0.50 f11 radeon: 55 tests, 46 bugs - ratio 0.84 f12 radeon: 61 tests, 81 bugs - ratio 1.33 f13 radeon: 48 tests, 33 bugs - ratio 0.69 f14 radeon: 32 tests, 18 bugs - ratio 0.56 f15 radeon: 66 tests, 38 bugs - ratio 0.58 f16 radeon: 12 tests, 8 bugs - ratio 0.67 f11 intel: 23 tests, 21 bugs - ratio 0.91 f12 intel: 29 tests, 31 bugs - ratio 1.07 f13 intel: 38 tests, 38 bugs - ratio 1.00 f14 intel: 33 tests, 28 bugs - ratio 0.84 f15 intel: 37 tests, 25 bugs - ratio 0.68 f16 intel: 10 tests, 7 bugs - ratio 0.70 It's hard to draw any conclusions from such small numbers, but really, none of them are far out of line with previous events. Here's the chart for how reported bugs are handled, adding the results from the F15 events (this chart gets updated on a one-cycle delay, because it's concerned with how the bugs filed are handled after a reasonable amount of time for the developers to look at them). A full explanation of what this tracks and how it's calculated in the F13 recap at https://lists.fedoraproject.org/pipermail/test/2010-April/090271.html . Some resolutions showed up this time that didn't before. I counted 'WORKSFORME' in with 'closeddupe' - i.e. as part of the set of bugs that should just be completed discarded from consideration. I handled 'UPSTREAM' bugs on a case-by-case basis, going in and look at whether they'd actually been fixed upstream or what, and putting them in the most appropriate group. Also, if you try to reproduce these numbers, note that you'll want to remove the bugs 123456 and 234567 from the lists - they're used in the 'example' entries in the results matrix. The bug totals are slightly different from the above chart because I copy/pasted the F15 numbers in the above chart from the last recap, but the numbers in this chart are newly generated, and so a few bugs that were filed and added to the Wiki pages *after* the last recap went out have been added to the numbers in this chart. f11 nouveau: 42 bugs, 4 open, 8 closeddupe, 24 closedfixed, 6 closedunfixed - 70.59% f12 nouveau: 34 bugs, 11 open, 8 closeddupe, 14 closedfixed, 1 closedunfixed - 53.85% f13 nouveau: 27 bugs, 17 open, 6 closeddupe, 3 closedfixed, 1 closedunfixed - 14.29% f14 nouveau: 8 bugs, 5 open, 3 closeddupe - 0% (small sample) f15 nouveau: 58 bugs, 27 open, 13 closeddupe, 13 closedfixed, 5 closedunfixed - 28.89% f11 radeon: 46 bugs, 14 open, 10 closeddupe, 19 closedfixed, 3 closedunfixed - 52.78% f12 radeon: 81 bugs, 19 open, 32 closeddupe, 28 closedfixed, 2 closedunfixed - 57.14% f13 radeon: 36 bugs, 28 open, 3 closeddupe, 5 closedfixed, 0 closedunfixed - 15.15% f14 radeon: 18 bugs, 13 open, 0 closeddupe, 3 closedfixed, 2 closedunfixed - 16.67% f15 radeon: 38 bugs, 17 open, 10 closeddupe, 9 closedfixed, 2 closedunfixed - 32.14% f11 intel: 21 bugs, 7 open, 1 closeddupe, 12 closedfixed, 1 closedunfixed - 60% f12 intel: 31 bugs, 7 open, 12 closeddupe, 12 closedfixed, 0 closedunfixed - 63.16% f13 intel: 42 bugs, 26 open, 4 closeddupe, 11 closedfixed, 1 closedunfixed - 28.95% f14 intel: 28 bugs, 21 open, 4 closeddupe, 1 closedfixed, 2 closedunfixed - 4.17% f15 intel: 27 bugs, 8 open, 7 closeddupe, 12 closedfixed, 0 closedunfixed - 60% There's definitely good news here - as noted in the last recap, we had a good crop of reports from the F15 event, so there's no reason we shouldn't be able to get back up to this level with better organization and promotion for F17. Also, the number of bugs actually getting *fixed* - which is the ultimate goal of the event - was significantly higher than F13 and F14, not quite back to F11/F12 levels, but a lot better. So the trend of fewer bugs getting fixed seems to have been stopped during F15 cycle. Intel showed a particularly marked improvement here. (It's worth noting that some of the bugs filed and fixed were actually on GNOME rather than the X drivers; I didn't compare the level of non-X bugs in the results in other releases, so that is an untracked variable. If anyone wants to look into that, please do!) Many thanks as
Re: Release criterion proposal: betanag removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Wed, 30 Nov 2011 09:01:03 -0800 Adam Williamson awill...@redhat.com escribió: On Wed, 2011-11-30 at 10:03 -0600, Mike Chambers wrote: On Tue, 2011-11-29 at 18:21 -0800, Adam Williamson wrote: A straightforward release criterion proposal: we should have a criterion just to specify that the anaconda betanag screen (and any others we put in) should be removed for final. Right now this is one of those things that's just obvious but that we ought to write down somewhere. How about, in the Final criteria, simply: * No notices or alerts about pre-release status should be present Yea that might be one of those last step things that needs to be on the list before going final or at least the final spins are created. Hell, just to give it a little more time, could do it before the RC's are created since they are pretty much final. It's changed for Final TC1, IIRC. actually i leave the beatnag on for final TC's as they are never intended to be final releases, but RC1 on its turned off. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk7Wx7cACgkQkSxm47BaWfestQCgvxKDSTI/SwM+pviQ7dneSIQp 1LsAn3mWHG3sFCTQKVbN/9DOIS6T+lq4 =T/xW -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] AutoQA Upgrade to 0.7
As a heads up, we're updating AutoQA to 0.7 today. I'm not expecting any issues during the update process but no new jobs will be run while we're updating the production systems. The update process shouldn't take much more than an hour, maybe two if we hit problems. If all goes well, you might notice a delay in results being posted to bodhi. If all doesn't go well, you'll see another email from me. Tim signature.asc Description: PGP signature ___ test-announce mailing list test-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce
