test August 2012

test@lists.fedoraproject.org

85 participants
283 discussions

[Fedora QA] #305: Abrt test day request for 2012-09-27
by fedora-badges 25 Feb '13

25 Feb '13

#305: Abrt test day request for 2012-09-27 ----------------------+------------------ Reporter: dkutalek | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------ I would like to allocate a test day slot for 2012-09-27. This will be my first Test day as organizer, so I am just finding out how things works and how it should look like. Seems like I have folks happy to help around me in Brno, so hope everything will go fine. I should bring in details in next weeks and expect having everything ready by the end of August. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/305> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 12

[Fedora QA] #312: OpenStack test day request for Aug 30th
by fedora-badges 25 Feb '13

25 Feb '13

#312: OpenStack test day request for Aug 30th ----------------------+------------------ Reporter: pbrady | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------ Following on from the previous 2 successful test days, the openstack team would like to have a test day for the openstack Folsom (milestone 3) release. Probably included also in the test cases will be tests for the new Heat component listed as a Fedora 18 feature: https://fedoraproject.org/wiki/Features/Heat -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/312> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 19

[Fedora QA] #308: Request for Fedora Networking Test Week
by fedora-badges 25 Feb '13

25 Feb '13

#308: Request for Fedora Networking Test Week ----------------------+------------------ Reporter: martix | Owner: Type: task | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------ We want to do Networking Test Week on 24.-26. October 2012. We will focus our testing on Network Manager, dnssec-trigger, firewalld new functionality, interactions between them and their integration in Gnome and KDE desktops. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/308> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 5

[Fedora QA] #304: Request for F18 Power Management test day
by fedora-badges 25 Feb '13

25 Feb '13

#304: Request for F18 Power Management test day -----------------------------------------+------------------ Reporter: jskarvad | Owner: Type: task | Status: new Priority: major | Milestone: Component: Proventester Mentor Request | Version: Keywords: | Blocked By: Blocking: | -----------------------------------------+------------------ We would like to run F18 Power Management test day. We expect it to be similar to our previous F17 Power Management test day. We will try to prepare Live CDs for this event (as for F17). We suggest 2012-10-11 but probably any date would fit to us. We would probably also try to hold this on-site in Red Hat Brno office (as for f17). -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/304> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

[Test-Announce] Call for Test Days for Fedora 18
by Adam Williamson 20 Feb '13

20 Feb '13

Hey, folks. It's that time again - time to start thinking about Test Days for Fedora 18. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization, or any combination of the two. To propose a Test Day, just file a ticket in QA trac - full details are at https://fedoraproject.org/wiki/QA/Test_Days/Create . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://fedoraproject.org/wiki/QA/Fedora_18_test_days . There are many slots open right now, with the earliest on 2012-08-09 and the latest 2012-11-01. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Alpha release or the time after the feature freeze or the Final freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific timeframe due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or timeframe you'd like, and we'll figure it out from there. If you have any questions about the Test Day process, please don't hesitate to contact me or any other member of the QA team on test@ or in #fedora-qa on IRC. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ test-announce mailing list test-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce

2 1

[Fedora QA] #151: Tests consistent with Criterion
by fedora-badges 13 Feb '13

13 Feb '13

#151: Tests consistent with Criterion ---------------------------+------------------------------------------------ Reporter: rhe | Owner: rhe Type: enhancement | Status: new Priority: major | Milestone: Fedora 15 Component: Wiki | Version: Keywords: retrospective | ---------------------------+------------------------------------------------ = problem = Criteria was kept changing during F-14 test cycle, but some installation tests didn't update accordingly. On the other hand, the criterion should be modified to include preupgrade_from_older_release test and new tests created for F-15. = enhancement recommendation = Installation tests need be reviewed and updated to fit for the criterion. Criterion for preupgrade_from_older_release test is required. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/151> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 26

Final Criterion for working built-in mediacheck
by Andre Robatino 23 Oct '12

23 Oct '12

At the moment, there is a Final Criterion that states "If there is an embedded checksum on any release medium, it must be correct", which means that in this case you can run checkisomd5 externally and have it work. There is nothing that ensures that the built-in mediacheck should work, even if it appears on the boot menu (which it now does in F18). In fact, at the moment it doesn't - see https://bugzilla.redhat.com/show_bug.cgi?id=848764 . So I'd suggest adding something like requiring that if there is an embedded checksum, then the built-in mediacheck (corresponding to the rd.live.check boot option) should work. Perhaps the embedded checksum should also be required, since all the Install and Live images currently have them. Thoughts?

4 6

[Fedora QA] #306: Blockers that move to 'CLOSED' are not removed from the tracker page
by fedora-badges 16 Oct '12

16 Oct '12

#306: Blockers that move to 'CLOSED' are not removed from the tracker page --------------------------------------+------------------------ Reporter: tflink | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Fedora 18 Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+------------------------ = bug description = Blockers that move to 'CLOSED' are not moved from the tracker page = bug analysis = The bugzilla sync algorithm isn't updating the 'active' field to false when a bug is closed = fix recommendation = Write a new test case to capture the behavior and update the syncronization algorithm accordingly -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/306> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 1

[Fedora QA] #289: Howto: debug kernel
by fedora-badges 20 Sep '12

20 Sep '12

#289: Howto: debug kernel --------------------+------------------------ Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 17 Component: Wiki | Version: Keywords: | Blocked By: Blocking: | --------------------+------------------------ I have seen a lot of discussions about kernel with debugging options enabled in this cycle. The questions repeat itself and I have them sometimes as well (I tend to forget these information). I think we should create a wiki page describing: 1. That our current policy is to use debug kernels in all composes prior to Branched Beta (is that true? maybe just Beta RC1?). 2. The problems that debug kernels may cause (mainly performance problems). 3. The exceptions in this process (regularly there is a non-debug kernel built). 4. How to know whether you are currently running a debug kernel (I never remember this one). 5. How to find latest debug/non-debug kernel in Koji. 6. How to install this kernel from Koji. Then we can link this page e.g. in our Alpha announcements, so that we save a lot of question for many people (and maybe a lot of troubles as well, if they have some troubles and they just don't know about debug kernels at all). Good idea? Volunteer? -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/289> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

Proposed release criteria and test case adjustments relating to artwork and self-identification
by Adam Williamson 04 Sep '12

04 Sep '12

Hey, folks. So discussion around https://bugzilla.redhat.com/show_bug.cgi?id=849982 rather indicates that our existing release criteria relating to artwork are problematic. I talked to the design team on IRC this morning, looking at the criteria in their initial context (see http://meetbot.fedoraproject.org/fedora-bugzappers/2010-09-03/fedora-bugzap… around 16:25 and https://lists.fedoraproject.org/pipermail/test/2010-September/093476.html if you're interested), and how artwork requirements have changed since then. The current criteria are: Alpha - "The default Fedora artwork must either refer to the current Fedora release under development (Fedora 18), or reference an interim release milestone (e.g. Alpha or Beta). If a release version number is used, it must match the current Fedora release under development. This includes artwork used in the installer, graphical bootloader menu, firstboot, graphical boot, graphical login and desktop background." Final - "The proposed final Fedora artwork must be included and enabled by default for the installer, graphical boot, firstboot, graphical login and desktop background. All Fedora artwork must be consistent with the proposed final theme, and if any artwork contains a graphical version number, the version number used must match the Fedora release number. Generic release artwork (e.g. Alpha, Beta, Development) must not be used for the final release" There are several problems with these, now: 1) The use of 'refer to' is somewhat ambiguous and creates confusion - I'd been reading it as meaning 'explicitly specify', but the artwork team have been reading it as meaning 'specify or reference in some way' (so they consider the desktop backgrounds as 'referring to' specific releases by association with their codenames, even though the backgrounds don't state a version number). 2) They're probably over-strict for their real intent. The intent of the Alpha criterion, especially, is really only that no-one should mistake an Alpha release for the previous stable release or anything like that. It's about avoiding confusion. 3) The space for artwork in current Fedora is much more limited than it was when we wrote those criteria. Lots of the things that were previously explicitly themed per release now have either generic artwork or no 'artwork' to speak of at all. anaconda doesn't really have 'artwork' any more. The bootsplash has been the Fedora logo on a blue blackground for several releases. firstboot is not themed any more, it's just solid grey and blue with the Fedora logo. From Fedora 18 onwards, even gdm will not be themed any more, it will not feature a background image. We're not sure of the status of kdm, but design team considers KDE SIG responsible for that, it's not part of the 'official' artwork stuff. So basically, we're down to bootloaders and the desktop background, when it comes to 'artwork'. With all those factors in mind, here's what we boiled it down to. I propose we replace the Alpha criterion with this one: * The default desktop background must be different from that of the two previous stable releases and add a new Alpha criterion: * Any component which prominently identifies a Fedora release version number or phase (Alpha, Beta, Final) must do so correctly The first of these might be a bit over-clever - we could just say "must be different from any previous release", but, perhaps over-thinking things, I wondered if maybe at some point in the future we'll want to use a 'retro' wallpaper for some reason, revive the Fedora Core 1 artwork or something. Which, with enough of a time gap, obviously wouldn't create any confusion. So I tried to allow for the possibility. The second one, I think, frames the confusion problem better: it's not only artwork that can create confusion. The new anaconda UI identifies the Fedora version and phase with a text string - that's not 'artwork', but if it's wrong, it could certainly confuse things. plymouth in text mode also specifies the Fedora release. There are probably others I'm not thinking of right now. I don't see why the 'confusion' criterion shouldn't cover _anything_ that could plausibly cause confusion, there's no reason to restrict it to artwork. The 'prominently' weasel-word gives us an out to avoid slipping the release just because it's wrong in some obscure text file somewhere that no-one ever reads. I propose we modify the Final criterion a bit, just to update it for the more restricted modern artwork era: * The proposed final Fedora artwork must be included and enabled by default for all graphical bootloaders and the desktop background. All Fedora artwork must be consistent with the proposed final theme 'all graphical bootloaders' is phrased that way because we use multiple bootloaders - grub2 for installed systems and EFI boots of installer discs, syslinux for BIOS boots of installer discs - and sometimes these aren't graphical, we have to be allowed to not include *any* artwork in a bootloader if that seems necessary/unavoidable. We can drop the 'version number must match' sentence entirely, if we adopt the proposed new Alpha criterion which would subsume it. We would also have to modify some test cases slightly, the changes just follow from the above. In https://fedoraproject.org/wiki/QA:Testcase_base_startup , the result "If the artwork used at the bootloader screen, during graphical boot, on the login manager, or the desktop background references a release number and/or pre-release phase (Alpha, Beta etc), it must be the current number and/or phase for the release or pre-release under test" would be changed to "If the bootloader screen, graphical bootsplash, login manager, desktop background or any other prominent part of the start process references a release number and/or pre-release phase (Alpha, Beta etc), it must be the current number and/or phase for the release or pre-release under test". Similarly, the phrase "the artwork used in the login manager and on the default desktop (particularly the background) must be the correct and current artwork" proposed for the release in question by the design team" would be changed to "the artwork used on the default desktop (particularly the background) must be the correct and current artwork". In https://fedoraproject.org/wiki/QA:Testcase_base_firstboot, the expected result relating to artwork would simply be removed. In https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Graphical, "used in the boot menu and installer" would be changed to just "used in the boot menu". "If a release version number is used" could be clarified to "If the boot menu and/or installer specify a release version number". Sorry for the essay, hope it all makes sense! Comments, suggestions, improvements, complaints welcome. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

6 7

← Newer
1
2
3
4
5
6
7
8
...
29
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test August 2012