May be I didn't understand you right or I don't understand the whole point of FE so tell me if I'm wrong.
As I understand it your proposal is that a bug that no one is willing to fix can't be a FE, right?
If that's the case then I think it's wrong, since there are bugs that can be important enough for FE even if there is no one that is willing to fix it.
And one more thing, what is SOP? is there a wiki for the acronyms that are used so I won't have to bother you with those questions too often?
Moshe
As I understand it your proposal is that a bug that no one is willing to fix can't be a FE, right?
If that's the case then I think it's wrong, since there are bugs that can be important enough for FE even if there is no one that is willing to fix it.
And one more thing, what is SOP? is there a wiki for the acronyms that are used so I won't have to bother you with those questions too often?
Moshe
On Fri, Mar 8, 2013 at 2:19 PM, Kamil Paral <kparal@xxxxxxxxxx> wrote:
> I can see where you're going with this, but I do have a few concerns.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.
>
> 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.
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).
Sorry, I don't follow you here. What exactly is hand-wavy and how is it connected to priorities?
>
> 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.
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.
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?
>
> 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, 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").
Keep the critique coming :)
>
> 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.
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?
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
