On Mon, Sep 16, 2019 at 5:06 PM Adam Williamson
wrote:
> I still consider automatic blockers to be about obviousness (not
> criticality), but I'm open to different resolutions here anyway, if we
> want to come up with something really clear.
>
For the record, we talked about this yesterday in
On Mon, 2019-09-16 at 16:11 +0200, Kamil Paral wrote:
> On Fri, Sep 13, 2019 at 6:44 PM Adam Williamson
> wrote:
>
> > On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > > As I feel it (and would like to have it), "automatic blockers" imply they
> > > are such core and basic issues that
On Fri, Sep 13, 2019 at 6:44 PM Adam Williamson
wrote:
> On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > As I feel it (and would like to have it), "automatic blockers" imply they
> > are such core and basic issues that they are non-questionable and
> > non-waivable (except by FESCo,
On Fri, Sep 13, 2019 at 1:10 PM Adam Williamson
wrote:
>
> Let's be clear about what we mean by 'waiving'. Actually I'd like to
> avoid using that word at all (yes I know I did it once, I edited my
> mail to take them out but missed one).
>
> We are *not* 'waiving' the criterion. We are *not*
On Fri, 2019-09-13 at 12:34 -0600, Chris Murphy wrote:
> On Fri, Sep 13, 2019 at 10:43 AM Adam Williamson
> wrote:
> > On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > > As I feel it (and would like to have it), "automatic blockers" imply they
> > > are such core and basic issues that
On Fri, Sep 13, 2019 at 10:43 AM Adam Williamson
wrote:
>
> On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > As I feel it (and would like to have it), "automatic blockers" imply they
> > are such core and basic issues that they are non-questionable and
> > non-waivable (except by FESCo,
On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> As I feel it (and would like to have it), "automatic blockers" imply they
> are such core and basic issues that they are non-questionable and
> non-waivable (except by FESCo, which is itself part of the same policy and
> marked to have godly
s can't un-accepted (waived), with the exception of FESCo."
>
> An alternative option would be to exclude just "last minute blocker bugs"
> exception, but keep "difficult to fix" exception:
> "Automatic blockers can't be subject to last minute blocker
en dependencies, and *oversize images*. I don't think anyone
but FESCo should be able to say "go" in that case, regardless of when the
problem was reported (even minutes before the final meeting). I'd really
like automatic to mean automatic, without any consideration.
As a result, I propose
ase criteria]] should be accepted as a
> blocker bug for the next relevant milestone release. However, bearing
> in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis
> on '''both''' time '''and''' quality, in some cases we may make an
> exception. There are two main catego
On Wed, Aug 14, 2019 at 4:48 PM Adam Williamson
wrote:
>
> Hmm. Since we've had a proposal for 7 days and a proposal for 3 days,
> why not just split the difference and say 5 days? That would be the
> Saturday before go/no-go: so anything proposed the week before isn't
> covered, but from the
On Wed, 2019-08-14 at 14:26 -0600, Chris Murphy wrote:
> Another option here, is applying the last minute blocker to the
> Release Target #1 week, and not to the Preferred Target week. Of even,
> if it's a 3 day period apply it to the Preferred Target week; and if 7
> days apply to Target #1 week.
On Wed, Aug 14, 2019 at 2:09 PM Ben Cotton wrote:
>
> On Wed, Aug 14, 2019 at 3:57 PM Chris Murphy wrote:
> >
> > On Wed, Aug 14, 2019 at 11:14 AM Ben Cotton wrote:
> > >
> > > only bug that's really made me mad in the years
> >
> > Go on then!
> >
> Whoops! I was going to say the only bug
On Wed, Aug 14, 2019 at 11:26 AM Adam Williamson
wrote:
>
> If we say 3 days, then we're committing to doing all of that for a
> blocker that's proposed the Sunday before the go/no-go - one day before
> the final blocker review meeting. Which, I mean...yeah, we have time to
> do all that. Juuust
On Wed, Aug 14, 2019 at 3:57 PM Chris Murphy wrote:
>
> On Wed, Aug 14, 2019 at 11:14 AM Ben Cotton wrote:
> >
> > only bug that's really made me mad in the years
>
> Go on then!
>
Whoops! I was going to say the only bug that's really made me mad in
the year I've been FPgM is the one that got
On Wed, Aug 14, 2019 at 11:14 AM Ben Cotton wrote:
>
> On Tue, Aug 13, 2019 at 8:46 AM Kamil Paral wrote:
> >
> > I thought about it and 7 days probably sounds OK, considering it also
> > includes the weekend. I think I wouldn't increase it, but consider
> > decreasing it if people think it's
I have the same doubts about the 7. Well, nobody is sure ;) +1 on my side,
great work Pat & Adam
On August 14, 2019 7:33:03 PM GMT+02:00, Ben Cotton wrote:
>On Wed, Aug 14, 2019 at 1:26 PM Adam Williamson
> wrote:
>>
>> If we say 3 days, then we're committing to doing all of that for a
>>
On Wed, Aug 14, 2019 at 1:26 PM Adam Williamson
wrote:
>
> If we say 3 days, then we're committing to doing all of that for a
> blocker that's proposed the Sunday before the go/no-go - one day before
> the final blocker review meeting. Which, I mean...yeah, we have time to
> do all that. Juuust
On Wed, 2019-08-14 at 13:13 -0400, Ben Cotton wrote:
> On Tue, Aug 13, 2019 at 8:46 AM Kamil Paral wrote:
> > I thought about it and 7 days probably sounds OK, considering it also
> > includes the weekend. I think I wouldn't increase it, but consider
> > decreasing it if people think it's the
On Tue, Aug 13, 2019 at 8:46 AM Kamil Paral wrote:
>
> I thought about it and 7 days probably sounds OK, considering it also
> includes the weekend. I think I wouldn't increase it, but consider decreasing
> it if people think it's the right way to go.
>
7 is definitely higher than I would have
milestone release. However, bearing
> > > in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis
> > > on '''both''' time '''and''' quality, in some cases we may make an
> > > exception. There are two main categories of bug that may be
> &g
On Mon, 2019-08-12 at 16:11 -0600, Chris Murphy wrote:
> On Fri, Aug 9, 2019 at 8:04 PM Adam Williamson
> wrote:
> > # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or
> > fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release
>
On Fri, Aug 9, 2019 at 8:04 PM Adam Williamson
wrote:
>
> # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or
> fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release
> (Beta or Final) can be considered under this policy, as there are some
>
'' quality, in some cases we may make an
> > exception. There are two main categories of bug that may be
> > 'exceptional':
> >
> > # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or
> > fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone r
t; blocker bug for the next relevant milestone release. However, bearing
> in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis
> on '''both''' time '''and''' quality, in some cases we may make an
> exception. There are two main categories of bug that may be
> 'exceptio
ses ===
Generally speaking, any bug that is agreed to be a violation of the
[[Fedora Release Criteria|release criteria]] should be accepted as a
blocker bug for the next relevant milestone release. However, bearing
in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis
on '''both'''
ine? It makes it more convenient to read them quickly. For the
record, here is Pat's proposal:
" 3Last Minute Blocker Bugs
3.1 A Last Minute Blocker Bug occurs when a bug is nominated
as a blocker bug seven (7) days or less before a scheduled freeze for
either a B
I got feedback from Adam and Ben today; so the following changes have
been made:
I have added a little paragraph at the beginning to say what a last
minute blocker bug is. I used freeze as the time anchor rather than a
meeting since that seems to be the most firm time constraint we work to.
I like Pat's proposal, but I don't see that we actually say what a
"last minute blocker bug" is. I am in favor of giving us a little
lattitude to use judgment, but I think we want to set some sort of
guidance for our future selves. We should make it clear that "last
minute" status is based on when
On Mon, 2019-06-17 at 09:20 -0400, pmkel...@frontier.com wrote:
> Proposed additions to the Blocker Bug Procedure to cover Last Minute
> Blocker Bugs (tidied up version). In case we cover this today at the QA
> meeting.
Thanks for this, Pat, and sorry for the late reply. I
Proposed additions to the Blocker Bug Procedure to cover Last Minute
Blocker Bugs (tidied up version). In case we cover this today at the QA
meeting.
Have a Great Day!
Pat (tablepc)
BlockerBugs.odt
Description: application/vnd.oasis.opendocument.text
I like the general idea of the original draft, but I would go for a simpler
route: bugs not nominated as a blocker by the scheduled start of the
Go/No-Go meeting are subject to not being considered for blocking the
release.
This gives us the flexibility to make the best judgment call that we can.
Lukas Ruzicka igorleak hau idatzi zuen (2019 mai. 14,
ar. 14:12):
>
> I am talking about the quorum, if there is a late discovered bug, that
> would normally be considered a blocker, but because
>
> a) it could not be fixed on time, and
> b) it is not as serious as it would prevent people from
I am talking about the quorum, if there is a late discovered bug, that
would normally be considered a blocker, but because
a) it could not be fixed on time, and
b) it is not as serious as it would prevent people from using Fedora anyway
In this case, I think more people to decide is crucial
Lukas Ruzicka igorleak hau idatzi zuen (2019 mai. 14,
ar. 12:55):
> Yeah, you can be right, Julen, however the process, as we are having now,
> would allow discarding Blocker Bugs possibly anytime, even if 3 or 4 people
> would be present on a meeting. And I don't think it is correct to let 4
>
Yeah, you can be right, Julen, however the process, as we are having now,
would allow discarding Blocker Bugs possibly anytime, even if 3 or 4 people
would be present on a meeting. And I don't think it is correct to let 4
people decide.
In case of a qorum (and I am not saying it has to be 10
Lukas Ruzicka igorleak hau idatzi zuen (2019 mai. 14,
ar. 10:39):
> I have suggested the quorum, but we can still discuss the exact numbers
> (mine were just examples). Besides, the votes do not have to come from
> people present in one particular IRC meeting, but
>
>- votes could be
I have suggested the quorum, but we can still discuss the exact numbers
(mine were just examples). Besides, the votes do not have to come from
people present in one particular IRC meeting, but
- votes could be recorded in all such meetings (blocker bugs meeting,
go-nogo, ...)
- votes
On both fc29 and fc30 cycles, nor the later blocker review meetings nor the
go/no-go ones did not have 10 participants, so needing a 80% agremeent with
a minimum of 10 votes would directly block on last minute bugs on those
scenarios.
I don't have a clear opinion on this, but for now I would
t QA team meeting (04/29/2019) I volunteered to help with
> adding something to the blocker bug process to handle Last Minute
> Blocker Bugs.
>
> I started by reading:
>
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q46M75GUKRHMI5IMNGBNL6XHLD5GL
This is a resend.
In the last QA team meeting (04/29/2019) I volunteered to help with
adding something to the blocker bug process to handle Last Minute
Blocker Bugs.
I started by reading:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message
In the last QA team meeting (04/29/2019) I volunteered to help with
adding something to the blocker bug process to handle Last Minute
Blocker Bugs.
I started by reading:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q46M75GUKRHMI5IMNGBNL6XHLD5GLLTS
42 matches
Mail list logo
