Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Nov 02, 2016 at 04:10:53PM +0100, Jan Kurik wrote: > I drafted a process to cover the evaluation of "Important bugs" [1]. > It still needs some work on the wording, however it should be good > enough for review and comments. May I ask for a feedback and possibly > improvement proposals,

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

Hi, I drafted a process to cover the evaluation of "Important bugs" [1]. It still needs some work on the wording, however it should be good enough for review and comments. May I ask for a feedback and possibly improvement proposals, please ? [1]

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Fri, 2016-10-14 at 11:26 +1000, Jeff Fearn wrote: > > Not that I think either of those fields are good for marking something > as a blocker for the distribution, a blocker flag would be more useful > for that IMO. None of this is about the blocker process, we already have one of those and it

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 14/10/2016 11:07 AM, Adam Williamson wrote: > On Thu, 2016-10-13 at 19:33 +1000, Jeff Fearn wrote: >>> That's not the intent of the fields as I understand them. 'severity' is >>> supposed to represent how bad the bug is, whereas 'priority' is >>> supposed to represent how important it is to get

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, 2016-10-13 at 19:33 +1000, Jeff Fearn wrote: > > > That's not the intent of the fields as I understand them. 'severity' is > > supposed to represent how bad the bug is, whereas 'priority' is > > supposed to represent how important it is to get it fixed compared to > > other bugs in the

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, Oct 13, 2016 at 1:22 PM, Josh Boyer wrote: > On Thu, Oct 13, 2016 at 12:02 AM, Adam Williamson > wrote: >> On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote: >>> On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson >>>

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, Oct 13, 2016 at 12:02 AM, Adam Williamson wrote: > On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote: >> On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson >> wrote: >> > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote: >> > >

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 13/10/2016 4:56 PM, Adam Williamson wrote: > On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote: >> On 13/10/16 14:02, Adam Williamson wrote: >>> On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote: On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson wrote:

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

- Original Message - | From: "Adam Williamson" | To: "Development discussions related to Fedora" | Sent: Thursday, October 13, 2016 12:26:10 PM | Subject: Re: PROPOSAL: Blocking the release is our only "big hammer" — let's

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote: > On 13/10/16 14:02, Adam Williamson wrote: > > On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote: > > > On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson > > > wrote: > > > > On Wed, 2016-10-12 at 09:55 -0400, Josh

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 13/10/16 13:59, Adam Williamson wrote: > On Thu, 2016-10-13 at 10:45 +1000, Jeff Fearn wrote: >> On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) >> slow as hell (though not >> quite as bad >>> as when we wrote blockerbugs). >> >> I haven't seen many bugs about this

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 13/10/16 14:02, Adam Williamson wrote: > On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote: >> On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson >> wrote: >>> On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote: All of the extra app stuff could be avoided if

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote: > On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson > wrote: > > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote: > > > All of the extra app stuff could be avoided if we disallowed reporters > > > (or random

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, 2016-10-13 at 10:45 +1000, Jeff Fearn wrote: > On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) > slow as hell (though not > quite as bad > > as when we wrote blockerbugs). > > I haven't seen many bugs about this since the hardware upgrade. If something > is

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson wrote: > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote: >> All of the extra app stuff could be avoided if we disallowed reporters >> (or random people) to change the Severity and Priority fields. > > Mmm, I don't

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 13/10/16 10:37, Adam Williamson wrote:> 3. Bugzilla queries are (still) slow as hell (though not quite as bad > as when we wrote blockerbugs). I haven't seen many bugs about this since the hardware upgrade. If something is slow please open a bug and we will look in to it. It's hard to get

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 2016-10-12 at 16:41 -0400, Josh Boyer wrote: > On Oct 12, 2016 4:15 PM, "Matthew Miller" wrote: > > > > On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote: > > > > I agree Jan's proposal looks like a good idea. However, I can't but > > > > help notice

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote: > All of the extra app stuff could be avoided if we disallowed reporters > (or random people) to change the Severity and Priority fields. Mmm, I don't really think so. Presumably it would be maintainers who got to set those fields, right? But

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 12, 2016 at 04:41:31PM -0400, Josh Boyer wrote: > To be clear, I'm not adamant we use bugzilla. I simply think it's odd to > invest in yet another custom tool and service that Fedora infrastructure > will now have to maintain and run. How many one off solutions do we need? I was

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Oct 12, 2016 4:15 PM, "Matthew Miller" wrote: > > On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote: > > > I agree Jan's proposal looks like a good idea. However, I can't but > > > help notice that its necessity is driven almost entirely by the fact > > >

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 12, 2016 at 01:13:05PM -0600, Kevin Fenzi wrote: > > I agree Jan's proposal looks like a good idea. However, I can't but > > help notice that its necessity is driven almost entirely by the fact > > that we cannot use our existing bugzilla tool to do this job for us. > > All of the

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 12 Oct 2016 09:55:40 -0400 Josh Boyer wrote: > On Wed, Oct 12, 2016 at 9:38 AM, Matthew Miller > wrote: > > On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote: > >> @Matt: does it reflect your thoughts ? > > > > Looks like

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 12, 2016 at 9:38 AM, Matthew Miller wrote: > On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote: >> @Matt: does it reflect your thoughts ? > > Looks like a great place to start -- thanks. The one change I'd make is > adding a separate "Critical" level,

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 12, 2016 at 10:48:36AM +0200, Jan Kurik wrote: > @Matt: does it reflect your thoughts ? Looks like a great place to start -- thanks. The one change I'd make is adding a separate "Critical" level, for things that will have us pacing the halls (figuratively) continually bugging people,

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

I think your proposal is useful, and it should be tested how far it'll get us. There's one more thing I'd like to be included. If approved, the bug should be categorized with respect to its impact on Fedora based on the discussion that led to its approval as "important". I think it would help to

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Tue, Oct 11, 2016 at 3:51 PM, Matthew Miller wrote: > On Tue, Oct 11, 2016 at 03:29:37PM +0200, Jan Kurik wrote: >> very low. Just for an information: on Fedora we have every week >> created approx. 400 - 500 new bugs. I can not imagine doing review of >> such an

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Tue, Oct 11, 2016 at 03:29:37PM +0200, Jan Kurik wrote: > very low. Just for an information: on Fedora we have every week > created approx. 400 - 500 new bugs. I can not imagine doing review of > such an amount of bugs on (bi-)weekly basic. Blocker bug meeting Oh my no. We wouldn't review all

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Mon, Oct 10, 2016 at 11:09 PM, Matthew Miller wrote: > On Wed, Oct 05, 2016 at 02:33:37PM -0700, Adam Williamson wrote: >> We used to have exactly this, up until Fedora 14. We had 'Target' > [much snip] >> lighter process than the blocker review process, though I

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 10/06/2016 03:27 PM, Adam Williamson wrote: On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote: So I like the idea, I do propose to simply re-use most of the blocker bug process for this, rather then inventing yet another process. I guess this could even be integrated and the way to

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

> Speaking for myself only here, my experience in the gfx team > is that there are so many bugs that I cannot see the forest > through the trees. > > A list with issues which are not blockers, but only barely so > and it would be really really good to have them fixed, > would certainly be a list

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 05, 2016 at 02:33:37PM -0700, Adam Williamson wrote: > We used to have exactly this, up until Fedora 14. We had 'Target' [much snip] > lighter process than the blocker review process, though I don't have a > specific proposal for how that could look at this point in time. If it > would

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote: > > So I like the idea, I do propose to simply re-use most of > the blocker bug process for this, rather then inventing yet > another process. I guess this could even be integrated and > the way to get bugs on the list would be to propose

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

In theory, I like this idea. In practice, Kevin Kofler is probably right. Unless there is a big hammer, bugs don't get fixed in many cases. So I think the solution should be different: gfx team needs more manpower so they can handle bug reports. Right now, for some packages bugzilla serves

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

Hi, On 05-10-16 20:30, Bruno Wolff III wrote: On Wed, Oct 05, 2016 at 14:19:12 -0400, Matthew Miller wrote: In any case, what do you all think? I don't think the tracking side would be hard to do. What I'd like to hear about is how the list will work for getting

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, 2016-10-06 at 00:36 +0200, Kevin Kofler wrote: > In fact, I would argue that this should even be done for blockers: A > bug  > should be a blocker if and only if a SIG/WG behind a release-blocking > image  > decides that it is important for it to be fixed in the release, no > matter  >

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Thu, 2016-10-06 at 00:36 +0200, Kevin Kofler wrote: > > In fact, I would argue that this should even be done for blockers: A bug > should be a blocker if and only if a SIG/WG behind a release-blocking image > decides that it is important for it to be fixed in the release, no matter >

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

Adam Williamson wrote: > The Target trackers were discontinued, so far as I recall, because no- > one ever really took a blind bit of notice of them. People would throw > bugs onto the list and then...nothing much would happen. It was just > kind of a wishlist and (IIRC) very few packagers even

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

Matthew Miller wrote: > I propose we create a parallel "Critical Issues" list, using basically > the same procedures. Issues eligible for this status would be those > which do not necessarily fail a release criterion but which have > critical impact on a Fedora Edition or on a council-approved

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 2016-10-05 at 16:26 -0500, Michael Catanzaro wrote: > > Probably would should just use the existing freeze exception process > for this purpose? What's the benefit of adding another thing? One thing about the freeze exception process is that we only actually review proposed freeze

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 05, 2016 at 16:26:54 -0500, Michael Catanzaro wrote: On Wed, 2016-10-05 at 14:19 -0400, Matthew Miller wrote: I propose we create a parallel "Critical Issues"  list, using basically the same procedures. Issues eligible for this status would be those which do

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 2016-10-05 at 14:19 -0400, Matthew Miller wrote: > I've talked about this before, but maybe the F26 cycle is time to make > it happen. Right now, we have only one way of saying "this bug is > important to the project as a whole; could we please get resources > focused on it?" — and that

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 2016-10-05 at 14:19 -0400, Matthew Miller wrote: > I propose we create a parallel "Critical Issues"  list, using > basically > the same procedures. Issues eligible for this status would be those > which do not necessarily fail a release criterion but which have > critical impact on a

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 5 Oct 2016 14:19:12 -0400 Matthew Miller wrote: ...snip... > In any case, what do you all think? Well, we sort of have something like this today: common bugs. ie, things we think people will hit and we couldn't/didn't fix in time for release? But we only do

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

Giant +1 There are few things more frustrating than being bitten by a bug that goes unfixed for release after release, while being told by the maintainer that they simply don't have time to fix anything but release blockers. This wouldn't automaticall fix this, but it would certainly provide a

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 5, 2016 at 3:16 PM, Chris Murphy wrote: > On Wed, Oct 5, 2016 at 12:19 PM, Matthew Miller > wrote: >> I've talked about this before, but maybe the F26 cycle is time to make >> it happen. Right now, we have only one way of saying

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 5, 2016 at 12:19 PM, Matthew Miller wrote: > I've talked about this before, but maybe the F26 cycle is time to make > it happen. Right now, we have only one way of saying "this bug is > important to the project as a whole; could we please get resources >

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, 5 Oct 2016 13:29:41 -0500 Michael Cronenworth wrote: > On 10/05/2016 01:19 PM, Matthew Miller wrote: > > In any case, what do you all think? > > What happened to the Nice-To-Have (NTH) tag? It was renamed to "Freeze Exception" to better match what we were actually

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 05, 2016 at 13:29:41 -0500, Michael Cronenworth wrote: On 10/05/2016 01:19 PM, Matthew Miller wrote: In any case, what do you all think? What happened to the Nice-To-Have (NTH) tag? It was renamed to freeze exception. But it covers a different set of fixes.

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On Wed, Oct 05, 2016 at 14:19:12 -0400, Matthew Miller wrote: In any case, what do you all think? I don't think the tracking side would be hard to do. What I'd like to hear about is how the list will work for getting bugs better fixed than bugzilla entries will?

Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

On 10/05/2016 01:19 PM, Matthew Miller wrote: In any case, what do you all think? What happened to the Nice-To-Have (NTH) tag? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.

I've talked about this before, but maybe the F26 cycle is time to make it happen. Right now, we have only one way of saying "this bug is important to the project as a whole; could we please get resources focused on it?" — and that way is to stop the whole vehicle until someone does something about