I can see where you're going with this, but I do have a few
concerns.
I really don't want to rely on the web front end for blocker
proposal.
At least not *yet*. Right now its status is that of an 'experimental
front end to existing processes'. We were pretty solid in discussions
(maybe more in person than on list, I don't recall) that the web app
should just do stuff you can also do manually: it's just a
convenience.
Maybe in future if it works well and people are happy with it we can
start to refine the process in ways where 'manual' submission isn't
plausible and we have to rely on helper frontends like the webapp,
but
I'm not sure we're at the point to start doing that yet. Especially
*now*, for Fedora 19.
I never intended to say that the web app is necessary for the process to work. If it is
down, all of my proposed work-flow can be done by hand. If it is not ready by Fedora 19,
we don't have to use it at all. The bugzilla messages won't be so pretty and
unified, but the core of the proposal was a different nomination process, not directly
tied to the web app.
If we change the SOP and the web app is not ready, it will not be so straightforward, but
hey, that's it. The user can still contact the developer via bugzilla or IRC ask him
to nominate the particular bug for a freeze exception. The developer can still tag the bug
and provide justification in the comment. Just the crutches are not there. (By the way,
the last few sentences was a TL;DR version of my whole proposal, minus the web app
adjustments).
You addressed this to some extent, but I'd like the proposal to be
much
more specific and much less hand-wavy about the 'FreezeException as a
priority list' case. Practically speaking, we do not use the priority
field in Bugzilla at all; FE status does act as a somewhat useful
proxy
for 'this bug is probably pretty important'. It's not meant to do
that,
but it kind of does. We - that is, QA - should definitely be manually
eyeballing proposed FE bugs, even if we aren't formally evaluating
all
of them.
Sorry, I don't follow you here. What exactly is hand-wavy and how is it connected to
priorities?
I'd like to decouple the FE list from the "probably important issue" list.
Currently people go through bugzilla and do: "this seems important - mark; this as
well - mark; mark mark mark". I know it, because I do it too. But this brings us
heavy burden.
That's why in my proposal the FE list is a list of bugs that developers are really
willing to work on in the remaining short timeframe. That trims the list substantially.
In order to still have a list of "good to eyeball" bugs, I proposed a different
QAWatchList tracker. So next time I or anybody else has a tagging frenzy, they will
populate QAWatchList instead of FE list. Because those are decoupled, we won't have a
heap of probably-important-but-incomplete-information bugs to go through on the next
blocker bug meeting.
Finally, I think some of the problems identified in your mail are
more
F18 artifacts than ongoing things. My recollection is that we managed
to
do NTH evaluation pretty well in cycles prior to F18: it was only due
to
the massive blocker load in F18 that we got substantially behind on
NTH
evaluation.
I agree here, because of F18 delays we had much more FE bugs to go through compared to
previous releases. But... this is not strictly relevant to release quality. This is more
relevant to the _people_ evaluating the bugs. If a new person joins Fedora QA and is very
passionate and active, we can have dozens of FE bugs tagged in a single week. Will we
forbid him to do so? Or will we improve the process?
I, personally, often don't tag mildly important bugs as FEs, because I don't want
to increase our load when I know there's 99% chance that no one will fix the issue
anyway. I've nearly given up on nominating FEs in the last cycle. That's a process
failure in my eyes.
To sum up, we fail in the notion what FE-nominated bug really is. Currently we say that
FE-nominated bug is any bug that any single Fedora community person considers as such.
I'm trying to suggest that FE-nominated bug is any bug that has a voiced developer
support (i.e. "I am Chuck and I'm willing to fix this bug, so tell me if you
grant me the freeze exception or not").
Still, I do think the proposal has some merits, but I kinda feel like
it
needs a bit of tuning, and might possibly be more F20 than F19.
Keep the critique coming :)
I have a feeling that I haven't explained properly that the core of the proposal is a
SOP change, and the web app workflow is just a bonus to make it prettier. Is it clearer
now? Do you still have the same concerns?
What other people think?