We discussed a few possible changes to the blocker bug meeting process
at the QA meeting this week. It was agreed that I'd draft up these
changes for list discussion. So here they are! Sent to test@ and devel@
as QA, devel and releng are the stakeholders in this process: I'm
figuring releng folks are all subscribed to one list or the other.
https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_blocker_bug_meeti…https://fedoraproject.org/wiki/User:Adamwill/Draft_QA_SOP_blocker_bug_proce…
Here are the specific separated proposals:
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_bloc…
Specify a three-hour time limit on blocker review meetings
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_bloc…
Use a dedicated channel (#fedora-blocker-review) for blocker review
meetings instead of #fedora-bugzappers
https://fedoraproject.org/w/index.php?title=User:Adamwill/Draft_QA_SOP_bloc…
Specify that blocker review should not happen in QA meetings
The first change is pretty non-controversial; we started putting a
three-hour cap on review meetings during F18 and carrying over to the
next day, and that seemed to work much better than meetings that dragged
on for six hours where just a couple of people were left at the end.
The second was suggested by Johann, and I support it. Using
#fedora-bugzappers for the meetings is kind of a hack - we just used the
channel as we had it lying around and nothing was happening there any
more. We tried running the meetings in #fedora-qa for a while, but it
didn't work well, as people often want to discuss other stuff there
while meetings are happening (especially in the case of long meetings).
We can't use #fedora-meeting because we tend to run far too long; for
the same reason we can't absolutely rely on meeting-1, meeting-2 etc
being available). So a dedicated channel seems like a sensible option.
It doesn't really result in 'channel proliferation' because after the
change, #fedora-bugzappers won't really be used for anything, so we
could all drop that one.
The third was another thing we did in F18 that seemed to work well;
doing blocker review _during_ QA meetings was something I was always a
bit unhappy with (as it's a bit hard for people to know about or find
logs of after the fact if they don't know about it), and simply
beginning an actual blocker review meeting right after the QA meeting
seemed to work fine. We could actually announce it ahead of time that
way too; we usually know ahead of time when we're going to be doing it.
Thoughts? Improvements? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
There has already been a thread here on this topic [1] but after it came
up in the Fedora QA meeting yesterday, we decided to make an actual
proposal.
[1]http://lists.fedoraproject.org/pipermail/test/2013-February/113898.html
The concern raised is that notifications for development related tickets
for the blocker tracking app are out of place on the Test list.
To solve this, we have a couple of options:
1. Start using the defaultcc plugin for trac such that emails for the
blocker tracking app are directed to a new qa-devel@ list
2. Move all development related tickets out of the Fedora QA trac into
a new trac instance for the blocker tracking app which uses qa-devel@
for notifications.
3. Move all development related tickets to a different existing trac
(probably autoqa)
Personally, I don't have any really strong feelings about (1) or (2).
(1) is probably a little less work in the short term but (2) isn't a
bad idea. I'm somewhat strongly -1 on (3), though - If I need to go
through and do the work of moving tickets and changing settings, I
don't really want to be hacking up another project's trac instance.
I've already started a thread on autoqa-devel@ asking about combining
that list with a new qa-devel@ [2]. The initial response has been
positive - I don't expect that will be a problem.
[2]https://lists.fedorahosted.org/pipermail/autoqa-devel/2013-February/00351…
Anyhow, thoughts on the possible solutions or how much work the problem
is worth?
Tim
#296: Fix blocker bug tracker page and replace it with a static HTML page
----------------------+------------------------
Reporter: adamwill | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: Fedora 18
Component: Wiki | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
https://fedoraproject.org/wiki/Current_Release_Blockers - which generates
a useful view of blocker bugs from Bugzilla - has been broken since the
recent Bugzilla upgrade. At minimum we need to fix up the script that
generates it, and have it run by something other than jlaska's personal
wiki account. We decided the best approach is probably to make it a
standalone page (hosted on fedoraproject somewhere) rather than a wiki
page; being a wiki page isn't giving us any advantages and just makes
things more complicated.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/296>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
#355: System Certificates test day
----------------------+------------------
Reporter: stefw | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Test Day | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------
Would like to request a test day for the shared system certificates
feature:
https://fedoraproject.org/wiki/Features/SharedSystemCertificates
Date: 2013-03-28
Owner: Stef Walter <stefw(a)redhat.com>
Co-owner: Kai Engert <kengert(a)redhat.com>
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/355>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
Hi,
Yesterday I did an update of my x86_64 F18 through updates-testing
repository. Upon reboot, I got a blue background after gdm startup
saying that things are going wrong, contact an administrator.
In dmesg, there is segfaults for gnome-shell:
gnome-shell[1229]: segfault at 88 ip 000000383f63f134 sp
00007fff5866c750 error 4 in libcogl.so.11.0.3[383f600000+8e000]
I downgraded gnome-shell, cairo, xorg-* related updates but nothing
fixed the situation.
I'm using nouveau drm driver but today it happened also on my laptop with i915.
I now distro-sync'ed to updates repository after disabling
updates-testing and everything is OK.
i googled but found nothing so this is really interesting that nobody
encountered this.
Someone in fedora-devel told that reinstalling shared-mime-info fixes
the problem but we have to find the real cause as the issue will be
hitting people once the updates will be merged to stable repository.
One more thing is that upon updating, the logged-in gnome3 desktop
starts to show weird symptoms. icons disappear, evince can't open pdf
files, gtk theme is rendered wrongly, etc.
Attached is the yum transaction that causes the problem.
--
Ozan Çağlayan
Research Assistant
Galatasaray University - Computer Engineering Dept.
http://www.ozancaglayan.com
#331: Update Sync and Variables for new naming conventions
--------------------------------------+------------------------
Reporter: tflink | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone: Fedora 19
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+------------------------
= problem =
The blocker tracking words have changed for F19 and the sync algorithm
needs to be updated
= analysis =
AcceptedNTH -> AcceptedFreezeException
RejectedNTH -> RejectedFreezeException
Unfortunately, there are database fields and variables which reference
'accepted' and 'NTH'. These should probably be changed but that's not
critical.
= enhancement recommendation =
Change the algorithm and related tests, update
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/331>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
#330: Blocker Components are not updated when bug is reassigned
--------------------------------------+---------------------
Reporter: tflink | Owner: tflink
Type: defect | Status: new
Priority: major | Milestone:
Component: Blocker bug tracker page | Version:
Keywords: | Blocked By:
Blocking: |
--------------------------------------+---------------------
= bug description =
When a bug being followed by the blocker tracking app is reassigned to
another component, the component displayed in the tracker is never
updated.
This is a pretty big problem because it causes the current blockers to be
mis-represented if anything is re-assigned after it is proposed as a
blocker.
= bug analysis =
I looked into this a little during F18 and it doesn't appear to be quite
as simple as I was hoping. In theory, a full sync should take care of the
out-of-date data but that didn't fix the problem and I didn't see anything
obviously wrong with the sync code.
It is possible that #325 is interfering with the sync process - even
though the hacky fix made it into production, the sync was still crashing
on a regular basis.
= fix recommendation =
There are two parts to this bug.
* updated information is not being stored in the database
* change in component is not triggering an update
Changing the bugzilla query to pull in bugs when the component is updated
should be pretty easy - it's the part about new information not making it
into the database which is a bigger issue.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/330>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance