7:54 p.m.
# Fedora Quality Assurance Meeting
# Date: 2015-01-05
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
Hope everyone had a happy and safe winter solstice event of their
choice. Now it's time for the most significant and exciting happening
of all: the first QA meeting of a new Gregorian calendar year! I know,
I'm excited too.
roshi and I had a quick chat about the idea of starting up blocker bug
review for the F22 cycle this week, in the interests of reducing the
number of long meetings later in the cycle by starting earlier - so
let's see what folks think of that. I don't have any other specific
topics for the agenda - please reply to this mail if you do! Thanks.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Blocker bug review planning
3. Open floor
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
7:36 a.m.
On 01/05/2015 07:24 AM, Adam Williamson wrote:
roshi and I had a quick chat about the idea of starting up blocker bug
review for the F22 cycle this week, in the interests of reducing the
number of long meetings later in the cycle by starting earlier - so
let's see what folks think of that. I don't have any other specific
topics for the agenda - please reply to this mail if you do! Thanks.
That is a great idea. Probably start with the list of bugs that were
proposed blockers for Fedora 21 but got kicked from the blocker
category, would be a good list to start with?
Regards,
Sudhir
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Blocker bug review planning
3. Open floor
10:48 a.m.
On Mon, 2015-01-05 at 19:06 +0530, Sudhir Dharanendraiah wrote:
On 01/05/2015 07:24 AM, Adam Williamson wrote:
>
> roshi and I had a quick chat about the idea of starting up blocker
> bug review for the F22 cycle this week, in the interests of
> reducing the number of long meetings later in the cycle by
> starting earlier - so let's see what folks think of that. I don't
> have any other specific topics for the agenda - please reply to
> this mail if you do! Thanks.
That is a great idea. Probably start with the list of bugs that were
proposed blockers for Fedora 21 but got kicked from the blocker
category, would be a good list to start with?
In *theory*, if a bug's rejected as a blocker for one release it won't
be a blocker for the next release either - remember Fedora doesn't use
the RHEL system where bugs can be dropped as blockers for time
reasons, in the Fedora system blockers are supposed to be
unconditional. In practice we handwave a bit, but it's still generally
the case that rejected blockers for one release won't be accepted for
the next.
The exception is when we decide to change the release criteria, based
on something that happened during blocker review; in that case someone
will usually transfer the proposal.
Right now we have 8 proposed blockers for F22 (Alpha, Beta and Final)
so we'll probably start with that list at the meeting roshi is going
to schedule.
Bugzilla doesn't make it super easy to find rejected blockers for a
specific release, as you can't search for bugs which *once* blocked
another bug but don't any more (bit of a shame) - but here's an
approximate search, for open bugs filed in 2014 that have the
'RejectedBlocker' whiteboard:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
01&classification=Fedora&list_id=3125416&query_format=advanced&status_whiteboard=RejectedBlocker&status_whiteboard_type=allwordssubstr
if someone wanted to poke through and see if any of those should be 22
blockers, that'd be great of course!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:17 a.m.
On 01/05/2015 10:18 PM, Adam Williamson wrote:
In*theory*, if a bug's rejected as a blocker for one release it
won't
be a blocker for the next release either - remember Fedora doesn't use
the RHEL system where bugs can be dropped as blockers for time
reasons, in the Fedora system blockers are supposed to be
unconditional. In practice we handwave a bit, but it's still generally
the case that rejected blockers for one release won't be accepted for
the next.
Ah.. understood. thanks :)
Bugzilla doesn't make it super easy to find rejected blockers for
a
specific release, as you can't search for bugs which*once* blocked
another bug but don't any more (bit of a shame) - but here's an
approximate search, for open bugs filed in 2014 that have the
'RejectedBlocker' whiteboard:
Yeah, dependent on whiteboard. Alternatively,
we can use tracker bugs
for the various stages (Alpha/Beta/Final) of release. That can provide a
tree view of bugs (can be blocker bugs in this case) targeted for that
specific milestone and the ones closed will strike out leaving the ones
that got dropped.
Regards,
Sudhir
11:39 a.m.
On Mon, 2015-01-05 at 22:47 +0530, Sudhir Dharanendraiah wrote:
On 01/05/2015 10:18 PM, Adam Williamson wrote:
> In*theory*, if a bug's rejected as a blocker for one release it
> won't be a blocker for the next release either - remember Fedora
> doesn't use the RHEL system where bugs can be dropped as blockers
> for time reasons, in the Fedora system blockers are supposed to be
> unconditional. In practice we handwave a bit, but it's still
> generally the case that rejected blockers for one release won't be
> accepted for the next.
Ah.. understood. thanks :)
> Bugzilla doesn't make it super easy to find rejected blockers for a
> specific release, as you can't search for bugs which*once*
> blocked another bug but don't any more (bit of a shame) - but
> here's an approximate search, for open bugs filed in 2014 that
> have the 'RejectedBlocker' whiteboard:
Yeah, dependent on whiteboard. Alternatively, we can use tracker
bugs for the various stages (Alpha/Beta/Final) of release. That can
provide a
tree view of bugs (can be blocker bugs in this case) targeted for
that specific milestone and the ones closed will strike out leaving
the ones that got dropped.
That's the system we do use, but the problem is that when we reject a
bug as a blocker, we do it by making it not block the tracker bug any
more. So to find those bugs, you'd need to do a search for 'bugs which
blocked F21AlphaBlocker / F21BetaBlocker / F21FinalBlocker once, but
don't any more', but Bugzilla doesn't have that option.
We *could* make it so bugs that are rejected as blockers still block
the tracking bug (but just have the 'RejectedBlocker' whiteboard field
added), but I think that'd be confusing and a bad idea.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:19 p.m.
----- Adam Williamson <adamwill(a)fedoraproject.org> wrote:
| On Mon, 2015-01-05 at 22:47 +0530, Sudhir Dharanendraiah wrote:
| > On 01/05/2015 10:18 PM, Adam Williamson wrote:
| > > In*theory*, if a bug's rejected as a blocker for one release it
| > > won't be a blocker for the next release either - remember Fedora
| > > doesn't use the RHEL system where bugs can be dropped as blockers
| > > for time reasons, in the Fedora system blockers are supposed to be
| > > unconditional. In practice we handwave a bit, but it's still
| > > generally the case that rejected blockers for one release won't be
| > > accepted for the next.
| >
| > Ah.. understood. thanks :)
| >
| > > Bugzilla doesn't make it super easy to find rejected blockers for a
| > > specific release, as you can't search for bugs which*once*
| > > blocked another bug but don't any more (bit of a shame) - but
| > > here's an approximate search, for open bugs filed in 2014 that
| > > have the 'RejectedBlocker' whiteboard:
| >
|
| > Yeah, dependent on whiteboard. Alternatively, we can use tracker
| > bugs for the various stages (Alpha/Beta/Final) of release. That can
| > provide a
| > tree view of bugs (can be blocker bugs in this case) targeted for
| > that specific milestone and the ones closed will strike out leaving
| > the ones that got dropped.
| >
|
| That's the system we do use, but the problem is that when we reject a
| bug as a blocker, we do it by making it not block the tracker bug any
| more. So to find those bugs, you'd need to do a search for 'bugs which
| blocked F21AlphaBlocker / F21BetaBlocker / F21FinalBlocker once, but
| don't any more', but Bugzilla doesn't have that option.
|
| We *could* make it so bugs that are rejected as blockers still block
| the tracking bug (but just have the 'RejectedBlocker' whiteboard field
| added), but I think that'd be confusing and a bad idea.
Oh yes, its a bad idea to keep them in that state forever :). I was only suggesting to
keep the bugs till it is reviewed. But anyway, since blockers are not pushed because of
time constraint, that would make no difference either.
Regards,
Sudhir
| --
| Adam Williamson
| Fedora QA Community Monkey
| IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
| http://www.happyassassin.net
|
| --
| test mailing list
| test(a)lists.fedoraproject.org
| To unsubscribe:
| https://admin.fedoraproject.org/mailman/listinfo/test
12:57 p.m.
On Mon, 2015-01-05 at 13:19 -0500, Sudhir Dharanendraiah wrote:
----- Adam Williamson <adamwill(a)fedoraproject.org> wrote:
> On Mon, 2015-01-05 at 22:47 +0530, Sudhir Dharanendraiah wrote:
> > On 01/05/2015 10:18 PM, Adam Williamson wrote:
> > > In*theory*, if a bug's rejected as a blocker for one release
> > > it won't be a blocker for the next release either - remember
> > > Fedora doesn't use the RHEL system where bugs can be dropped
> > > as blockers for time reasons, in the Fedora system blockers
> > > are supposed to be unconditional. In practice we handwave a
> > > bit, but it's still
> > > generally the case that rejected blockers for one release
> > > won't be accepted for the next.
> >
> > Ah.. understood. thanks :)
> >
> > > Bugzilla doesn't make it super easy to find rejected blockers
> > > for a specific release, as you can't search for bugs
> > > which*once*
> > > blocked another bug but don't any more (bit of a shame) - but
> > > here's an approximate search, for open bugs filed in 2014 that
> > > have the 'RejectedBlocker' whiteboard:
> >
>
> > Yeah, dependent on whiteboard. Alternatively, we can use tracker
> > bugs for the various stages (Alpha/Beta/Final) of release. That
> > can provide a
> > tree view of bugs (can be blocker bugs in this case) targeted
> > for that specific milestone and the ones closed will strike out
> > leaving the ones that got dropped.
> >
>
> That's the system we do use, but the problem is that when we
> reject a bug as a blocker, we do it by making it not block the
> tracker bug any more. So to find those bugs, you'd need to do a
> search for 'bugs which blocked F21AlphaBlocker / F21BetaBlocker /
> F21FinalBlocker once, but don't any more', but Bugzilla doesn't
> have that option.
>
> We *could* make it so bugs that are rejected as blockers still
> block the tracking bug (but just have the 'RejectedBlocker'
> whiteboard field added), but I think that'd be confusing and a bad
> idea.
Oh yes, its a bad idea to keep them in that state forever :). I was
only suggesting to keep the bugs till it is reviewed. But anyway,
since blockers are not pushed because of time constraint, that would
make no difference either.
Yep. As I said the system we have is actually exactly as you describe.
There are tracker bugs for each milestone - you can see them listed at:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
the blockerbugs web app -
http://qa.fedoraproject.org/blockerbugs/current - is handy for several
reasons, but before we had it, we still used the same set of trackers.
At that time we did indeed use the tracker bug tree views as you
suggest, e.g. here's the tree view for 22 Alpha:
https://bugzilla.redhat.com/showdependencytree.cgi?id=1043121&hide_re...
some of the benefits of the blockerbugs app are that it distinguishes
between proposed and accepted blockers (we had custom searches for
this, but custom searches are kind of a pain) and pulls in info from
Bodhi, so we know the status of the updates for each bug. I do
remember back around 16-17, though, I'd just have the tree views open
and keep refreshing them...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3399
days inactive
3399
days old
6 comments
2 participants
participants (2)
-
Adam Williamson -
Sudhir D