Hi folks! As a throwaway at the end of the meeting today I mentioned a few tasks we could be doing during this 'quiet time' between F20 and F21. People seemed interested, and so I promised to send out a more detailed version of the list with links and references and stuff. This (obviously!) isn't a set of orders, and it's not really even a 'top priority' list, just my little list of ideas for things you could work on if you're looking to spend some time on Fedora but aren't sure what to do when we don't have Test Days or validation testing running. * It's not glamorous or exciting, but it always needs doing: test updates-testing on the stable releases (F19 and F20) and file feedback. You can always use a virtual machine to test a release you don't have installed - you can't check everything in a VM, but you can do a lot of things, and sometimes you can test stuff in a VM that you wouldn't want to mess with on your main system. https://fedoraproject.org/wiki/QA:Updates_Testing has all the info you need on doing updates-testing work: if you don't use fedora-easy-karma - https://fedoraproject.org/wiki/Fedora_Easy_Karma - or gooey karma - stuck in package review ATM, but there's a Copr at http://copr.fedoraproject.org/coprs/blaskovic/fedora-gooey-karma/builds/ - consider doing so, it'll really help! * You can always help test Rawhide - the development tree of Fedora, so right now, the current state of Fedora 21. All the details on Rawhide are at https://fedoraproject.org/wiki/Releases/Rawhide . Depending on how brave/experienced you are (and how many forms of backup you have!), you can even run it in production (the machine I'm typing this on has been running Rawhide for several weeks now...but I have backups of everything, webmail to use when Evolution breaks, Xfce to use when GNOME breaks, a Fedora 20 laptop to use if Rawhide breaks and a Fedora 19 laptop to use if Fedora 20 breaks ;>). If that's a bit too much for you, you can test the nightly live images from http://alt.fedoraproject.org/pub/alt/nightly-composes/ , or run it in a VM. Once you're actually running Rawhide, file any significant bugs you encounter just as usual, and if you run into any real showstoppers, you can propose them as Fedora 21 blockers following the usual process ( https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process ) - the blocker bug app has not yet been updated for F21 so you can't use that, but all you have to do is mark the bug as blocking "AlphaBlocker", "BetaBlocker" or "FinalBlocker". If you see any unusual or unexpected changes but you're not sure if they're bugs, post about them here (on test@), it's one of the purposes of the list! * One thing we never seem to quite do enough of is creating package-specific test cases: again this isn't highly visible work, but it is useful to do it. The details on doing it are at https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation (and https://fedoraproject.org/wiki/QA:SOP_test_case_creation explains how to write a test case). If you write some test cases and 'associate' them with a package, as the SOPs explain, they will be attached to every Bodhi update for that package, and people doing updates-testing testing will see your test cases as something they can use to check the package is working properly. If Bodhi 2.0 ever shows up, we'll be able to use these test cases in more concrete ways too - you're building up our resources for the future. * Of course, we have work to do on improving the release criteria and validation test cases. Johann is right that Fedora.next introduces some uncertainty here, but the majority of our validation process covers stuff that's more than likely going to be in the 'shared base' of the new Fedora.next 'products', so I don't expect there'll be *too* much change - we'll probably still be validating the shared base as usual. I'm trying to do some of this, but it always helps to have more folks. We came across several pain points in the criteria and test cases during F20 validation, and it'd be good to resolve some of those. You can always poke through blocker bug meeting logs to remind yourself of the issues we came up against - what I've been doing is browsing through http://meetbot.fedoraproject.org/fedora-blocker-review - the F20 meetings start from 2013-08-21 - and just skim-reading the HTML full logs of each meeting; you can easily see where the discussion of each bug starts from the bolded lines. When the discussion lasts only a few lines and finishes quick, we probably didn't have any trouble deciding the status of that bug, so you don't need to worry about it. If the discussion of a bug goes on for pages and pages, it's a good hint that that bug was a 'pain point': we might be able to improve our criteria and/or test cases to make the situation clearer. We welcome submissions of proposed improvements to the validation process from anyone, there's no secret club you need to be in to submit ideas! Proposing a new release criterion or test case is really as simple as writing it down and mailing it to the list with an explanation - you can do your test case just as plain text if you don't want to deal with all the wiki stuff, or you can create it in your personal space on the wiki and link to it from your proposal email. It's probably a good idea to include the word 'proposal' and/or 'criteria' and/or 'validation' in the subject (I tend to search for those 'magic words' when looking through the list archives for such proposals). Thanks for all your continued work, everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
