[Fedora QA] #90: Make blocker bug nag mails part of the SOP
by fedora-badges
#90: Make blocker bug nag mails part of the SOP
---------------------------+------------------------------------------------
Reporter: jlaska | Owner: poelstra
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
We have a lot of bugs, and the deadlines for resolving bugs (where
resolving == [fixing, documenting]) is not always clear.
= analysis =
During the lead up to F-13-RC, numerous reminder emails were sent to test@
and devel@ mailing lists noting the number and state of remaining blocker
bugs. It is felt that, along with developer time of course, the attention
to the blocker list contributed to the resolution of 67 blocker bugs from
2010-04-30 to 2010-05-06.
Not knowing which bugs were already reviewed, also introduced time wasted
reviewing previously reviewed bugs during blocker review meetings.
= enhancement recommendation =
1. Recommend more frequent blocker status emails leading up to '''each'''
major milestone. Unclear who should be responsible for sending these
mails, QA, rel-eng or program mgmt?
2. Update [https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
QA:SOP_Blocker_Bug_Meeting] with blocker meeting queries or ''python-
bugzilla'' commands and where to send the mails (developers bcc'd?)
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/90>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 4 months
[Fedora QA] #85: Clarify wiki test priority
by fedora-badges
#85: Clarify wiki test priority
---------------------------+------------------------------------------------
Reporter: jlaska | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
There was some confusing around the priority listed in the install and
desktop test matrices. The question was, why do we give the ''go''
decision to release, even when there are test failures from tests with a
matching release level?
= analysis =
Adam pointed out that ''this is because the bugs exposed caused the test
to 'fail', but don't really break the underlying release criteria. I think
we could perhaps track this type of 'failure' specifically in the results
tables).''
= enhancement recommendation =
I ''think'' this is a messaging/education issue. Perhaps we just need to
clarify that the priority listed is the test execution priority. It does
not always mean that a failure identified by those tests will block the
applicable release.
Updates or adjustments may be needed to the
https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event or to
the Fedora 14 test results template (when available --
https://fedoraproject.org/wiki/QA:Fedora_14_Install_Results_Template).
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/85>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 4 months
[Fedora QA] #87: Expand desktop release criteria and validation
by fedora-badges
#87: Expand desktop release criteria and validation
---------------------------+------------------------------------------------
Reporter: jlaska | Owner: adamwill
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
[http://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Desktop
test results] were often not available for non-GNOME desktops. This
leaves a large exposure come release day (for Alpha, Beta or Final).
= analysis =
The desktop release criteria are specific to GNOME. As a result, there is
no incentive to finding bugs in XFCE, LXDE or KDE.
= enhancement recommendation =
This might be too much for once ticket. Feel free to split this out into
more if needed.
Recommend looking for opportunities to improve communication between teams
and increasing non-GNOME desktop testing leading up to milestones.
* The goal is to extend the desktop validation testing introduced in
Fedora 13 to cover the main non-default desktops: KDE, Xfce and LXDE.
* Update appropriate desktop validation content as needed (see
[http://fedoraproject.org/wiki/QA:Desktop_validation_testing desktop
validation testing])
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/87>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 6 months
[Fedora QA] #94: Add several release criteria based on feedback from desktop SIGs
by fedora-badges
#94: Add several release criteria based on feedback from desktop SIGs
-----------------------------------------+----------------------------------
Reporter: adamwill | Owner: adamwill
Type: defect | Status: new
Priority: major | Milestone: Fedora 14
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
Discussing the expansion of desktop validation testing to other major
desktops - https://fedorahosted.org/fedora-qa/ticket/87 - has resulted in
several proposed additional release criteria:
* Saving passwords in the desktop default keyring (if the desktop
implements one), and retrieving passwords from the keyring, must work
* The desktop default update manager must not periodically check for
updates when the system is booted live, but must periodically check for
updates when running on an installed system
* The desktop's offered mechanisms for shutting down, logging out and
rebooting must work
We should consider adding these to the release criteria, and select
appropriate levels for each.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/94>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 6 months
[Fedora QA] #92: Define proventester process
by fedora-badges
#92: Define proventester process
---------------------------+------------------------------------------------
Reporter: jlaska | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
During Fedora 13, karma from members of the FAS 'qa' group was required
for critical path package updates. We don't have a clear process for
joining and contributing to this effort.
= analysis =
Not much else to say here. We have critical path packages that need
testing.
= enhancement recommendation =
Some of this is already complete, or inprogress (thanks dafrito,
maxamillion and adamw)
1. document how people can join -
https://fedoraproject.org/wiki/QA/JoinProvenTesters
2. document what is expected of members -
https://fedoraproject.org/wiki/Proven_tester
3. What else?
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/92>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 6 months
KernelBugTriage wiki page
by Juan P. Daza P.
Hi,
We are creating the Bugzappers Kernel Triage page and want some feedback
about this topic. This theme has many options and posibilites and we want
you to give us some feedback about this important point in the fedora
project.
https://fedoraproject.org/wiki/KernelBugTriage
Any comments are welcome.
--
JP
linux user: 431181
13 years, 7 months
[Fedora QA] #83: Clarify installer test coverage with i18n team
by fedora-badges
#83: Clarify installer test coverage with i18n team
---------------------------+------------------------------------------------
Reporter: jlaska | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
See [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=571900
RHBZ#571900 - Keyboard mapping not correct (USA instead of Belgium) when
first login after install Fedora 13 Alpha]
= analysis =
* RHBZ#571900 pointed out the need for a better understanding of how the
language and keymap installer selections impact the installed system.
* Currently we don't have i18n installation cases, so local language
install is not tested as a demand. Untranslated pages are still existing
after RC test. Such cases needed be added in test as well as release
criteria.
= enhancement recommendation =
* Recommend reviewing methods for incorporating l18n verification into
existing test plans, or coordinating with the
[https://fedoraproject.org/wiki/I18N i18N] team.
* Tests were drafted to capture a representative sample of the language
differences. Those tests are available at
https://fedoraproject.org/wiki/Category:I18n_Installation. The tests may
need to be reviewed and adjusted as needed, and possibly added to the
installation test matrix.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/83>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 8 months
