[Fedora QA] #305: Abrt test day request for 2012-09-27
by fedora-badges
#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
11 years, 2 months
[Fedora QA] #308: Request for Fedora Networking Test Week
by fedora-badges
#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
11 years, 2 months
[Fedora QA] #304: Request for F18 Power Management test day
by fedora-badges
#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
11 years, 2 months
[Test-Announce] Call for Test Days for Fedora 18
by Adam Williamson
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
11 years, 2 months
[Fedora QA] #151: Tests consistent with Criterion
by fedora-badges
#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
11 years, 2 months
Final Criterion for working built-in mediacheck
by Andre Robatino
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?
11 years, 6 months
[Fedora QA] #306: Blockers that move to 'CLOSED' are not removed from the tracker page
by fedora-badges
#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
11 years, 6 months
[Fedora QA] #289: Howto: debug kernel
by fedora-badges
#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
11 years, 7 months
Proposed release criteria and test case adjustments relating to artwork and self-identification
by Adam Williamson
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-bugz...
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
11 years, 7 months