Greetings.
Per: https://fedorahosted.org/fesco/ticket/1126 I'm sending this here for comment.
Rarely, but from time to time there is some change FESCo has required before they will go at the go/no-go meeting. While we could just leave that to the meeting, it would be better/nicer IMHO if we could track these issues using the same process QA uses for blockers so there's no suprise at the go/no-go meeting and everyone knows some bug needs to be addressed.
So:
Criteria: Any bugs FESCo deems blocking (as voted on by a majority of FESCo members) are added to the the blocker for that milestone.
Happy to have revisions or better ideas...
kevin
On Fri, 2013-06-21 at 11:29 -0600, Kevin Fenzi wrote:
Greetings.
Per: https://fedorahosted.org/fesco/ticket/1126 I'm sending this here for comment.
Rarely, but from time to time there is some change FESCo has required before they will go at the go/no-go meeting. While we could just leave that to the meeting, it would be better/nicer IMHO if we could track these issues using the same process QA uses for blockers so there's no suprise at the go/no-go meeting and everyone knows some bug needs to be addressed.
So:
Criteria: Any bugs FESCo deems blocking (as voted on by a majority of FESCo members) are added to the the blocker for that milestone.
Happy to have revisions or better ideas...
So, just a phrasing thing, the criteria are mostly written in the form 'XXX must be the case', not 'XXX is added to the blocker list'. So perhaps:
'All bugs deemed by FESCo to block the milestone release must be fixed.'
Would be enough. My suggestion used the terms 'issues' and 'addressed' as weasel words we've found useful before - in the case where we work around a bug, rather than fixing it, we can call that 'addressing' it - but I don't really mind writing it that way and just using Common Sense (tm). I think specifying FESCo's current decision-making mechanism - majority vote - in the criterion is a mistake, as it's at least theoretically plausible that FESCo could change its decision-making mechanism in future, and then the criterion would need to be updated for no good reason. All that matters to the blocker process is that 'FESCo Hath Deemed It Thus'. The mechanism by which FESCo Deems things is out of scope.
On Fri, 21 Jun 2013 10:37:01 -0700 Adam Williamson awilliam@redhat.com wrote:
So, just a phrasing thing, the criteria are mostly written in the form 'XXX must be the case', not 'XXX is added to the blocker list'. So perhaps:
'All bugs deemed by FESCo to block the milestone release must be fixed.'
Would be enough. My suggestion used the terms 'issues' and 'addressed' as weasel words we've found useful before - in the case where we work around a bug, rather than fixing it, we can call that 'addressing' it
- but I don't really mind writing it that way and just using Common
Sense (tm). I think specifying FESCo's current decision-making mechanism - majority vote - in the criterion is a mistake, as it's at least theoretically plausible that FESCo could change its decision-making mechanism in future, and then the criterion would need to be updated for no good reason. All that matters to the blocker process is that 'FESCo Hath Deemed It Thus'. The mechanism by which FESCo Deems things is out of scope.
Sure. Works for me.
kevin
On 2013-06-21 10:41, Kevin Fenzi wrote:
On Fri, 21 Jun 2013 10:37:01 -0700 Adam Williamson awilliam@redhat.com wrote:
So, just a phrasing thing, the criteria are mostly written in the form 'XXX must be the case', not 'XXX is added to the blocker list'. So perhaps:
'All bugs deemed by FESCo to block the milestone release must be fixed.'
Would be enough. My suggestion used the terms 'issues' and 'addressed' as weasel words we've found useful before - in the case where we work around a bug, rather than fixing it, we can call that 'addressing' it
- but I don't really mind writing it that way and just using Common
Sense (tm). I think specifying FESCo's current decision-making mechanism - majority vote - in the criterion is a mistake, as it's at least theoretically plausible that FESCo could change its decision-making mechanism in future, and then the criterion would need to be updated for no good reason. All that matters to the blocker process is that 'FESCo Hath Deemed It Thus'. The mechanism by which FESCo Deems things is out of scope.
Sure. Works for me.
As there were no objections, I'm adding this to the Alpha page as I create the F20 criteria pages. Thanks!
----- Original Message -----
On 2013-06-21 10:41, Kevin Fenzi wrote:
On Fri, 21 Jun 2013 10:37:01 -0700 Adam Williamson awilliam@redhat.com wrote:
So, just a phrasing thing, the criteria are mostly written in the form 'XXX must be the case', not 'XXX is added to the blocker list'. So perhaps:
'All bugs deemed by FESCo to block the milestone release must be fixed.'
Would be enough. My suggestion used the terms 'issues' and 'addressed' as weasel words we've found useful before - in the case where we work around a bug, rather than fixing it, we can call that 'addressing' it
- but I don't really mind writing it that way and just using Common
Sense (tm). I think specifying FESCo's current decision-making mechanism - majority vote - in the criterion is a mistake, as it's at least theoretically plausible that FESCo could change its decision-making mechanism in future, and then the criterion would need to be updated for no good reason. All that matters to the blocker process is that 'FESCo Hath Deemed It Thus'. The mechanism by which FESCo Deems things is out of scope.
Sure. Works for me.
As there were no objections, I'm adding this to the Alpha page as I create the F20 criteria pages. Thanks!
Late +1! It's good to have it documented and part of blocker process to avoid surprises.
R.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
-
Adam Williamson -
Jaroslav Reznik -
Kevin Fenzi