On Fri, Aug 11, 2017 at 12:51 AM, Adam Williamson <
adamw...@fedoraproject.org> wrote:
> On Thu, 2017-08-10 at 10:59 +0200, Jan Kurik wrote:
> > Thanks Adam for putting this together. I am definitely+1 to extend the
> > Blocker bug process with your proposal.
> >
> > And there is one more topic re
On Thu, 2017-08-10 at 10:59 +0200, Jan Kurik wrote:
> Thanks Adam for putting this together. I am definitely+1 to extend the
> Blocker bug process with your proposal.
>
> And there is one more topic related to this: how we should deal with
> 0day bugs found at the last moment before release ? Shou
Thanks Adam for putting this together. I am definitely+1 to extend the
Blocker bug process with your proposal.
And there is one more topic related to this: how we should deal with
0day bugs found at the last moment before release ? Should not we have
a statement for Accepted0Day and AcceptedPrevio
On Mon, 2017-07-17 at 17:48 -0700, Adam Williamson wrote:
> Hi, folks!
So there was some great feedback on the first version of this proposal;
here's the second draft, with all the suggestions considered and
applied. Note, given the misunderstanding between Kamil and Matt, I
added a little parag
On Mon, Jul 24, 2017 at 11:03:34AM +0200, Kamil Paral wrote:
> However, I think I misread your comment. I believed you're proposing we
> reject bugs existing in stable releases as blockers at any point of the
> development cycle. But you seem to have suggested we do this only if
> they're discovere
On Thu, Jul 20, 2017 at 4:22 PM, Matthew Miller
wrote:
> On Thu, Jul 20, 2017 at 10:02:09AM +0200, Kamil Paral wrote:
> > But all of that above is a separate problem. What I'd like to understand
> is
> > why you think existing bugs should be treated differently from new bugs.
> > What is the rati
On Thu, Jul 20, 2017 at 10:02:09AM +0200, Kamil Paral wrote:
> But all of that above is a separate problem. What I'd like to understand is
> why you think existing bugs should be treated differently from new bugs.
> What is the rationale? And if you want to treat them differently, then how?
I thin
On Wed, Jul 19, 2017 at 5:57 PM, Matthew Miller
wrote:
> On Wed, Jul 19, 2017 at 12:24:16PM +0200, Kamil Paral wrote:
> > > Another consideration that might be relevant: is this a *new* issue or
> > > something that also affects the current release (either as released or
> > > with updates)? If s
Michael Catanzaro wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1405539
IMHO, this isn't even a bug. Everything is working as designed.
And won't editing the kernel command line (which can be done interactively
in GRUB) to add vconsole.keymap= the desired keymap solve the problem? So
whe
On Wed, Jul 19, 2017 at 12:24:16PM +0200, Kamil Paral wrote:
> > Another consideration that might be relevant: is this a *new* issue or
> > something that also affects the current release (either as released or
> > with updates)? If something is a clear-cut blocker criterion violation
> > but isn't
The proposal sounds fine.
On Tue, Jul 18, 2017 at 3:48 PM, Matthew Miller
wrote:
> Another consideration that might be relevant: is this a *new* issue or
> something that also affects the current release (either as released or
> with updates)? If something is a clear-cut blocker criterion violat
On Tue, 2017-07-18 at 09:48 -0400, Matthew Miller wrote:
> On Mon, Jul 17, 2017 at 05:48:09PM -0700, Adam Williamson wrote:
> > All such cases must be evaluated and discussed by the usual parties
> > (usually at a blocker bug review meeting) and all relevant factors must
> > be taken into account,
On Mon, Jul 17, 2017 at 05:48:09PM -0700, Adam Williamson wrote:
> All such cases must be evaluated and discussed by the usual parties
> (usually at a blocker bug review meeting) and all relevant factors must
> be taken into account, much like the discussion of a bug that is a
> 'conditional' viola
On Mon, Jul 17, 2017 at 8:37 PM, Kevin Kofler
wrote:
A blocker ought to be a blocker, no matter when it is discovered and
how
long it takes to fix.
https://bugzilla.redhat.com/show_bug.cgi?id=1405539
It violates a release criterion (IMO), but it's been broken forever and
fixing it would be
On Tue, 2017-07-18 at 02:01 +, Zbigniew Jędrzejewski-Szmek wrote:
>
> > Firstly, it may occur if it is agreed to be very unlikely that the bug
> > can possibly be fixed within a reasonable time frame for the release to
> > be made. For instance, fixing the bug may be a task of such technical
>
On Tue, 2017-07-18 at 03:37 +0200, Kevin Kofler wrote:
>
> IMHO, this is a slippery slope eroding the quality of Fedora just because
> some people are not willing to wait a week longer for their "fix". The
> argument that this steals time from the next cycle is also invalid, because
> the obvio
On Mon, Jul 17, 2017 at 05:48:09PM -0700, Adam Williamson wrote:
> === Exceptional cases ===
>
> 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.
>
> Ho
Adam Williamson wrote:
> So, during the blocker review process in the last few cycles, we have
> several times come up against the unfortunate situation that a bug that
> in the usual course of events would block a release is discovered
> extremely late - say the day before the go/no-go meeting - a
Hi, folks!
So, during the blocker review process in the last few cycles, we have
several times come up against the unfortunate situation that a bug that
in the usual course of events would block a release is discovered
extremely late - say the day before the go/no-go meeting - and at least
some fo
19 matches
Mail list logo
