My name is David and my name on the wiki Kausdev
I'm just in insccrito list discuções QA and tried to do some tests and I
think it is already time to go to Time and work.
I appreciate friends and hope to do a good job.
Davi t.de Souza
Bacharel em sistemas de informaçao e segurança de dados
Embaixador do Projeto Fedora Brasil.
Seja Livre - Use Linux !
If there are any people here trying to get started with QA, please give
me a shout! As you'll see below, there's plenty of work to be done, even
when we're no terribly busy!
-------- Forwarded Message --------
> From: Adam Williamson <awilliam(a)redhat.com>
> Reply-to: For testing and quality assurance of Fedora releases
> To: test(a)lists.fedoraproject.org
> Subject: Suggested activities during the pre-F21 lull
> Date: Mon, 20 Jan 2014 17:49:43 -0800
> 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
> - 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
> test mailing list
> To unsubscribe:
Join Fedora! Come talk to us!
My name is Santosh Kumar, final year Computer Science Engineer and a FOSS
enthusiast. I'm very much interested in contributing fedora project.
I have worked upon flask and Django framework, so basically a python
programmer and have contributed to few of other open-source projects.
If there are beginner bugs which i can work upon to get started in
contributing to the community, it will be great!!