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

[Matthew Miller]

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, please ?
> 
> [1] 
> https://fedoraproject.org/wiki/Fedora_Program_Management/Important_bugs_and_issues_process

This looks excellent to me as a first pass. We can adjust as need be as
we go. I'm a little worried about sending the message that bugs that
don't make the list here aren't "important" to us in a wider sense...
maybe we want something more neutral like "Prioritized Issues"? I know
this is a little bikesheddy, but it'll be hard to change later.

Also, I'd like to add the criteria:

   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 Fedora Objective.
   Issues may also be nominated from the Common Bugs list when they are
   deemed by QA to have critical impact.

to the page somewhere.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jan Kurik]

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] 
https://fedoraproject.org/wiki/Fedora_Program_Management/Important_bugs_and_issues_process

Thanks a lot,
Jan

On Fri, Oct 14, 2016 at 3:29 AM, Adam Williamson
 wrote:
> 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 works fine (it doesn't use flags, though that would work just as
> well as what we have).
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 works fine (it doesn't use flags, though that would work just as
well as what we have).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jeff Fearn]

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 it fixed compared to
>>> other bugs in the same component. They're obviously related, but not
>>> the same, and it's not "severity is the reporter's opinion, priority is
>>> the maintainers' opinion", no.
>> My understanding is based on ye olde services plan:
>>
>> "Bugzilla Severity and Priority
>>
>> When filing a new bug report, or actioning an existing bug, it is
>> important to bear in mind that, while both the 'Severity' and 'Priority'
>> fields are required; 'Priority' is an internal weighting and 'Severity'
>> is customer weighting. This distinction can cause confusion if not
>> consistant."
>>
>> This is only significant in that it may have impacted the way they are
>> coded on BRC.
>>
>>> I think you might be right that we allow the bug reporter to set
>>> 'severity', though.
>> BRC carries a custom patch to restrict priority to a group besides
>> editbugs group (the setpriority group), AFAICT there is no code that
>> allows similar restriction of the severity field.
> Ah, interesting. I don't really have any particular source for my
> understanding of them, it's just something I've been carrying around
> for a while, I guess. However, Fedora definitely does not handle bugs
> the same as RHEL, so we're not necessarily *bound* by that
> definition...but we could use it if we liked.

Hell no, but if a restriction on who can set severity was wanted we'd
have to add a patch for that. Whereas for priority all you'd need is
another BZ group and just switch the group inheritance.

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.

Cheers, Jeff.




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 same component. They're obviously related, but not
> > the same, and it's not "severity is the reporter's opinion, priority is
> > the maintainers' opinion", no.
> 
> My understanding is based on ye olde services plan:
> 
> "Bugzilla Severity and Priority
> 
> When filing a new bug report, or actioning an existing bug, it is
> important to bear in mind that, while both the 'Severity' and 'Priority'
> fields are required; 'Priority' is an internal weighting and 'Severity'
> is customer weighting. This distinction can cause confusion if not
> consistant."
> 
> This is only significant in that it may have impacted the way they are
> coded on BRC.
> 
> > I think you might be right that we allow the bug reporter to set
> > 'severity', though.
> 
> BRC carries a custom patch to restrict priority to a group besides
> editbugs group (the setpriority group), AFAICT there is no code that
> allows similar restriction of the severity field.

Ah, interesting. I don't really have any particular source for my
understanding of them, it's just something I've been carrying around
for a while, I guess. However, Fedora definitely does not handle bugs
the same as RHEL, so we're not necessarily *bound* by that
definition...but we could use it if we liked.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jan Kurik]

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
>>>  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 really think so. Presumably it would be maintainers who
>>> > got to set those fields, right? But they are doing so in relation to
>>>
>>> No, why would you presume that?
>>
>> I dunno, just seemed logical. That's how they're intended to be used at
>> present. Bug reporters aren't supposed to set them and don't have the
>> privilege purely by rights of having an account...but because we grant
>> 'editbugs' to all packagers and all QA team members, in practice a lot
>> of the people who actually report bugs do have the power to set it.
>>
>> If you're suggesting we restrict access to those fields such that even
>> the packagers can't use them...well, it's a possibility, but I think at
>> least *some* teams do actually use those fields at present, and would
>> be inconvenienced by not being able to any more because we'd decided to
>> take them over for distribution purposes.
>>
>>> Right.  Which speaks to Matt's "very restricted" list of people.
>>> Which would essentially be the same group that is going to do the
>>> categorizing anyway.  Which means that since the fields are useless
>>> today (as in, completely) restricting them to useful to avoid another
>>> process or tool could be a possibility.
>>
>> Well sure, but on the other hand, if all you want to propose is 'do it
>> all in Bugzilla', you don't really need to use those fields; just a
>
> No.  My main goal is "stop building one-off tools because existing
> tools (or usage of them) suck".  If people want to enhance blockerbugs
> since it already exists, that's totally fine with me.  Basically, I
> want us to stop wasting effort and creating more technical debt.

I am fine with using just Bugzilla for this purpose. It does not have
fancy UI, but the capabilities for this job are sufficient. So, lets
start with Bugzilla and we will see whether there will be a need for
something more specific as we go.

I was also exploring a way how we can ensure the priority/severity
fields will not be changed once the bug is tracked as "Important" by
someone "non-authorized". My proposal is to use "PM Score" field
instead. This is a hidden field, every bug has attached, and is not
currently used for bugs in Fedora. The original purpose of this field
is to prioritize bugs from the perspective of Product Management, so
it in fact reflects what we are trying to achieve. The value of this
field is numerical and is visible as a comment any time someone sets
or changes its value. It is accessible via XML/RPC only.

Bugzilla has also a built-in tool called BRE (Bugzilla Rule Engine)
which allow us to react on a change of a field and do some actions. So
we might then enforce value of bug's priority according to the value
sets in the PM Score field, if this will be useful.

Regards,
Jan

> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

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:
>> > > 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 they are doing so in relation to
>>
>> No, why would you presume that?
>
> I dunno, just seemed logical. That's how they're intended to be used at
> present. Bug reporters aren't supposed to set them and don't have the
> privilege purely by rights of having an account...but because we grant
> 'editbugs' to all packagers and all QA team members, in practice a lot
> of the people who actually report bugs do have the power to set it.
>
> If you're suggesting we restrict access to those fields such that even
> the packagers can't use them...well, it's a possibility, but I think at
> least *some* teams do actually use those fields at present, and would
> be inconvenienced by not being able to any more because we'd decided to
> take them over for distribution purposes.
>
>> Right.  Which speaks to Matt's "very restricted" list of people.
>> Which would essentially be the same group that is going to do the
>> categorizing anyway.  Which means that since the fields are useless
>> today (as in, completely) restricting them to useful to avoid another
>> process or tool could be a possibility.
>
> Well sure, but on the other hand, if all you want to propose is 'do it
> all in Bugzilla', you don't really need to use those fields; just a

No.  My main goal is "stop building one-off tools because existing
tools (or usage of them) suck".  If people want to enhance blockerbugs
since it already exists, that's totally fine with me.  Basically, I
want us to stop wasting effort and creating more technical debt.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jeff Fearn]

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:
> 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 they are doing so in relation to
 No, why would you presume that?
>>> I dunno, just seemed logical. That's how they're intended to be used at
>>> present. Bug reporters aren't supposed to set them and don't have the
>>> privilege purely by rights of having an account
>> This is true for priority but not true for severity. Severity is the
>> external, i.e. reporters, weighting
>> of the bug and you do not need to be in editbugs to set it.
> 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 same component. They're obviously related, but not
> the same, and it's not "severity is the reporter's opinion, priority is
> the maintainers' opinion", no.
My understanding is based on ye olde services plan:

"Bugzilla Severity and Priority

When filing a new bug report, or actioning an existing bug, it is
important to bear in mind that, while both the 'Severity' and 'Priority'
fields are required; 'Priority' is an internal weighting and 'Severity'
is customer weighting. This distinction can cause confusion if not
consistant."

This is only significant in that it may have impacted the way they are
coded on BRC.

> I think you might be right that we allow the bug reporter to set
> 'severity', though.

BRC carries a custom patch to restrict priority to a group besides
editbugs group (the setpriority group), AFAICT there is no code that
allows similar restriction of the severity field.

Cheers, Jeff.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Sudhir Dharanendraiah]

- 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 
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 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 they are doing so in relation to
| > > > 
| > > > No, why would you presume that?
| > > 
| > > I dunno, just seemed logical. That's how they're intended to be used at
| > > present. Bug reporters aren't supposed to set them and don't have the
| > > privilege purely by rights of having an account
| > 
| > This is true for priority but not true for severity. Severity is the
| > external, i.e. reporters, weighting
| > of the bug and you do not need to be in editbugs to set it.
| 
| 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 same component. They're obviously related, but not
| the same, and it's not "severity is the reporter's opinion, priority is
| the maintainers' opinion", no.
| 
| I think you might be right that we allow the bug reporter to set
| 'severity', though.

There is no direct relation between these fields.
Many projects interpret in different ways, but the most common way is,
'severity' is what user thinks of the issue, how much of an issue it is for him 
('user' is a QE engineer/consumer or a developer of other component). This is 
usually set to get the attention of the developer/owner of component over other 
bugs in same component. 
'priority' is what the developer/owner of the component (owner of the bug) 
thinks its severity is. It can also be a consensus from all stake holders.

It is not uncommon to see high severity bugs getting triaged first. It is also 
a good practice to keep priority and severity at comparable, if not same level 
once triaged (i.e., it would not logically seem correct to see high severity 
with low priority or vice-versa after triage).

Regards,
Sudhir

| --
| Adam Williamson
| Fedora QA Community Monkey
| IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
| http://www.happyassassin.net
| ___
| devel mailing list -- devel@lists.fedoraproject.org
| To unsubscribe send an email to devel-le...@lists.fedoraproject.org
|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 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 they are doing so in relation to
> > > 
> > > No, why would you presume that?
> > 
> > I dunno, just seemed logical. That's how they're intended to be used at
> > present. Bug reporters aren't supposed to set them and don't have the
> > privilege purely by rights of having an account
> 
> This is true for priority but not true for severity. Severity is the
> external, i.e. reporters, weighting
> of the bug and you do not need to be in editbugs to set it.

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 same component. They're obviously related, but not
the same, and it's not "severity is the reporter's opinion, priority is
the maintainers' opinion", no.

I think you might be right that we allow the bug reporter to set
'severity', though.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jeff Fearn]

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 since the hardware upgrade. If something 
>> is slow please open a bug
>> and we will look in to it.
>>
>> It's hard to get time allocated for this kind of stuff without a list of 
>> bugs to put in front of
>> management. Every performance bug we have open will give us more leverage to 
>> spend some time optimizing
>> the query engine.
> 
> It's nothing out of the ordinary, it's just...I mean, it's doing a
> complex query of a gigantic database. Of course it won't be
> instantaneous. It's just nice with blockerbugs that you can just go to
> the URL and see the list right away.

:( But optimizing the query engine is more fun than fixing UI stuff...

Cheers, Jeff.

-- 
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jeff Fearn]

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 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 they are doing so in relation to
>>
>> No, why would you presume that?
> 
> I dunno, just seemed logical. That's how they're intended to be used at
> present. Bug reporters aren't supposed to set them and don't have the
> privilege purely by rights of having an account

This is true for priority but not true for severity. Severity is the external, 
i.e. reporters, weighting
of the bug and you do not need to be in editbugs to set it.

Cheers, Jeff.

-- 
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 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 they are doing so in relation to
> 
> No, why would you presume that?

I dunno, just seemed logical. That's how they're intended to be used at
present. Bug reporters aren't supposed to set them and don't have the
privilege purely by rights of having an account...but because we grant
'editbugs' to all packagers and all QA team members, in practice a lot
of the people who actually report bugs do have the power to set it.

If you're suggesting we restrict access to those fields such that even
the packagers can't use them...well, it's a possibility, but I think at
least *some* teams do actually use those fields at present, and would
be inconvenienced by not being able to any more because we'd decided to
take them over for distribution purposes.

> Right.  Which speaks to Matt's "very restricted" list of people.
> Which would essentially be the same group that is going to do the
> categorizing anyway.  Which means that since the fields are useless
> today (as in, completely) restricting them to useful to avoid another
> process or tool could be a possibility.

Well sure, but on the other hand, if all you want to propose is 'do it
all in Bugzilla', you don't really need to use those fields; just a
tracking bug works fine. Or a whiteboard field. Or a flag. Anything
searchable, really. blockerbugs is a convenience tool on top of the
blocker process, it's not *necessary*. You *can* run the entire blocker
process without it, and we used to do that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 slow please open a bug
> and we will look in to it.
> 
> It's hard to get time allocated for this kind of stuff without a list of bugs 
> to put in front of
> management. Every performance bug we have open will give us more leverage to 
> spend some time optimizing
> the query engine.

It's nothing out of the ordinary, it's just...I mean, it's doing a
complex query of a gigantic database. Of course it won't be
instantaneous. It's just nice with blockerbugs that you can just go to
the URL and see the list right away.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

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 really think so. Presumably it would be maintainers who
> got to set those fields, right? But they are doing so in relation to

No, why would you presume that?

> *the package*. What's 'critical' for a given package is not necessarily
> 'critical' for the distribution. If there's a bug in 'some-obscure-
> package-two-people-use' that prevents it running, that bug should have
> maximum 'severity' (and probably 'priority'), but that still doesn't
> mean Matt or Jan would give a damn about it from a 'is the release on
> fire?' perspective.

Right.  Which speaks to Matt's "very restricted" list of people.
Which would essentially be the same group that is going to do the
categorizing anyway.  Which means that since the fields are useless
today (as in, completely) restricting them to useful to avoid another
process or tool could be a possibility.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jeff Fearn]

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 time allocated for this kind of stuff without a list of bugs 
to put in front of
management. Every performance bug we have open will give us more leverage to 
spend some time optimizing
the query engine.

Cheers, Jeff.

-- 
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 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 extra app stuff could be avoided if we disallowed reporters
> > > > (or random people) to change the Severity and Priority fields.
> > > 
> > > We could request this from bugzilla folks (restrict those fields to
> > > people in fedorabugs? Or should it be more restricted ?)
> > 
> > To be useful for this purpose, it's gotta be super-restricted. I'm not
> > sure if that will interfere with existing workflows.
> > 
> > Also, I think this only solves 10% of the problem (the "how do we
> > indicate") part. It doesn't solve the workflow and acceptance part.
> 
> True, but acceptance can be done in bugzilla too via tracker bugs.
> Workflow is similar either way; people review the issues in a tool.
> 
> 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?

For reference, we handled the blocker stuff entirely through Bugzilla
for a while. We wrote blockerbugs for a few reasons. Ones I remember:

1. Since just looking at all bugs that block the 'blocker' tracker
gives you both proposed and accepted blockers, you had to use a saved
search or something to find just proposed blockers or just accepted
blockers; blockerbugs handily groups them for you

2. None of Bugzilla's queries or anything gives you a handy view of
what updates fix what blockers, while blockerbugs does

3. Bugzilla queries are (still) slow as hell (though not quite as bad
as when we wrote blockerbugs). blockerbugs is fast (it has to run slow
Bugzilla queries to sync its data, but it just syncs every half hour,
so the user experience is fast)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 they are doing so in relation to
*the package*. What's 'critical' for a given package is not necessarily
'critical' for the distribution. If there's a bug in 'some-obscure-
package-two-people-use' that prevents it running, that bug should have
maximum 'severity' (and probably 'priority'), but that still doesn't
mean Matt or Jan would give a damn about it from a 'is the release on
fire?' perspective.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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 hoping we could just configure a corner of the blockerbugs app QA
already uses rather than actually having a whole new one.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

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
> > > that we cannot use our existing bugzilla tool to do this job for us.
> > > All of the extra app stuff could be avoided if we disallowed reporters
> > > (or random people) to change the Severity and Priority fields.
> > We could request this from bugzilla folks (restrict those fields to
> > people in fedorabugs? Or should it be more restricted ?)
>
> To be useful for this purpose, it's gotta be super-restricted. I'm not
> sure if that will interfere with existing workflows.
>
> Also, I think this only solves 10% of the problem (the "how do we
> indicate") part. It doesn't solve the workflow and acceptance part.

True, but acceptance can be done in bugzilla too via tracker bugs.
Workflow is similar either way; people review the issues in a tool.

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?

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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 extra app stuff could be avoided if we disallowed reporters
> > (or random people) to change the Severity and Priority fields.
> We could request this from bugzilla folks (restrict those fields to
> people in fedorabugs? Or should it be more restricted ?)

To be useful for this purpose, it's gotta be super-restricted. I'm not
sure if that will interfere with existing workflows.

Also, I think this only solves 10% of the problem (the "how do we
indicate") part. It doesn't solve the workflow and acceptance part.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kevin Fenzi]

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 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,
> > pulling in favors, etc.  
> 
> 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 extra app stuff could be avoided if we disallowed reporters
> (or random people) to change the Severity and Priority fields.

We could request this from bugzilla folks (restrict those fields to
people in fedorabugs? Or should it be more restricted ?)

kevin


pgp90tzxZ7q1n.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

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, for things that will have us pacing
> the halls (figuratively) continually bugging people, pulling in favors,
> etc.

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 extra app stuff could be avoided if we disallowed reporters
(or random people) to change the Severity and Priority fields.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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, pulling in favors,
etc.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Ralf Senderek]

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 know why it is
seen as important and what is at stake if it isn't fixed.

This info should be visible on the web page to help focussing the efforts to 
those
bugs which may have the most impact.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jan Kurik]

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 amount of bugs on (bi-)weekly basic. Blocker bug meeting
>
> Oh my no. We wouldn't review all bugs, just ones which are nominated,
> and I am envisioning being quite strict with whether they meet the
> criterion I suggested:
>
>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 Fedora Objective.
>
> with a possible additional:
>
>   Issues may also be nominated from the Common Bugs list when they are
>   deemed by QA to have critical impact.
>
> or something like that. If it becomes necessary, we could even restrict
> nominations to those submitted by QA, the Edition WGs, or Objective
> leads — but I'd rather start less formal and introduce that rule if it
> becomes a problem.

Thinking of it ... lets start to think of a process/policy how this
should work, to find possible frictions:


=Nomination=
- Anyone can propose a bug as "Important". In case the number of
nominated bugs will go over a limit we will be able to proceed during
the approval process, we will limit the nomination possibility to a
defined group of people.
- The proposal will be done by a modified application QE currently use
for Blocker bugs.
- The bug is assigned to a tracker collecting the nominated bugs.

=Approval=
- There will be (bi-)weekly meetings of a group of people doing a
review of nominated bugs and granting approvals.
- The group will be namely defined and needs quorum to approve a bug
as "Important".
- On the meeting, all the nominated bugs for the given period of time
need to be reviewed. The review process might end up with the
following statues:
- - Approved: the bug is approved as "Important" and it moves from the
nomination tracker to tracker for "Important" bugs
- - Rejected: the bug has not been approved as "Important" and will be
removed from the nomination tracker
- - Postponed: the decision has not been made (i.e.: need more info).
The bug stays on the nomination tracker till the next meeting

=Enforcement=
- After every Approval meeting a wiki page with approved "Important"
bugs will be generated (refreshed), to get people information what is
important to fix.
- We might integrate this bug list into
http://whatcanidoforfedora.org/ page, so new comers can start to help
in the area we consider as important
- We might publish some stats in regular blogposts on
https://communityblog.fedoraproject.org/ to have some overview which
area/component needs an attention
- We can grant badges once a developer fixes certain amount of
"Important" bugs (something like
https://badges.fedoraproject.org/badge/if-you-build-it...-koji-success-iii
)


@Matt: does it reflect your thoughts ?

@All: does any one think this activity is meaningful ? If so, do you
have any better proposal or would like to add something to the
proposal above ?


Regards,
Jan

>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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 bugs, just ones which are nominated,
and I am envisioning being quite strict with whether they meet the
criterion I suggested:

   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 Fedora Objective.

with a possible additional:

  Issues may also be nominated from the Common Bugs list when they are
  deemed by QA to have critical impact.

or something like that. If it becomes necessary, we could even restrict
nominations to those submitted by QA, the Edition WGs, or Objective
leads — but I'd rather start less formal and introduce that rule if it
becomes a problem.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jan Kurik]

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 don't have a
>> specific proposal for how that could look at this point in time. If it
>> would mainly be used by the FPL and FPM, perhaps it could simply be the
>> rule that they got to decide what bugs went on it?
>
> *nod*
>
> Based on your other message elsewhere in the thread, I promise not to
> pull you or anyone else in QA under the bus, but I mght drag Jan
> Kurik with me as FPGM. Jan, what do you think about doing a Lightweight
> Critical Issues Review Meeting every, say, two weeks? We could start it
> with you and me and anyone else who wants to show up, and give it a
> hard limit of half an hour.

Well, I did not jump into this discussion as I do not have a clear
point of view on this topic. On one hand I see the benefit of having a
list of prioritized bugs. On the other hand there were already such
activities in the past (like the Target trackers described by Adam, or
BugZappers with their Triage meetings) which disappeared over the time
as ratio of the benefit to effort needed to maintain such a list was
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
typically takes 2-3 hours every week and the amount of proposed
blockers is typically less than 10. Even on the Blocker bug meetings I
see the need to check/consult an issue with a representative of a
WG/SIG or a maintainer to fully understand what is really going on in
the bug. With the amount of bugs Fedora receives I can not imagine
doing the review without representatives from WGs and SIGs, just
because of expertise needed to make a qualify decision. As such, the
cost to have such a list of prioritized bugs is quite high and the
benefit is questionable due to lack of enforcement.

[1] https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

Regards,
Jan

> Adam, if we do that, would it be hard to add to the existing
> blockerbugs app, so we don't need to stand up new infrastructure?
>
> Then we could try it for a bit and see if it is working / helpful or
> just another crazy idea.
>
> --
> Matthew Miller
> 
> Fedora Project Leader



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Jóhann B . Guðmundsson]

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 get bugs on the list would be to propose them
as blockers as normal and then during the blocker meeting
when the vote says "no this is not a blocker" a second vote
is done to see if it is a critical bug.

Let me phrase my earlier objection a little more strongly and
personally:

If someone tries to make me spend another three damn hours a week
reviewing 'proposed critical bugs' I'm going to jump out a window and
go start that yak farm. You won't see me for dust.


Interesting to see that now the person responsible for adding additional 
load on the QA community want's to jump out of windows after doing so. 
You reap what you sow...


As I mentioned sometime back in my QA days, QA should just take care of 
the installer/core/baseOS, then each sub community that delivers an 
product of some sort into the hands of an end users needs to take care 
of QA-ing it itself for whatever it builds on top of that and arguably 
the rest of the release process for that product.


Then the release process needs to be scaled from supporting just a 
single product ( which has never reflected what the community has ever 
done since there have always been more then one product in circulation 
from the community )  designed in such manner that product A cant block 
product B or C or F.


I have never understood this whole attitude of always putting all the 
load on QA and Releng which has never had any resources to effectively 
manage it for everybody to begin with.


JBG
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kamil Paral]

> 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 I would look at and see if there is
> anything on there I can pick up.
> 
> 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 them
> as blockers as normal and then during the blocker meeting
> when the vote says "no this is not a blocker" a second vote
> is done to see if it is a critical bug.

As already mentioned, the CommonBugs page might actually fit most of the 
requirements here. We often place important "almost blocker" bugs in there, 
issues which are very inconvenient for many people, or critical issues for a 
specific narrow group of people. If we know it's being used even by developers, 
we might try harder to include important issues in there. It's not exactly the 
same idea that Matthew talked about, but I think the overlap is definitely 
there. As a bonus, there's a quick summary of the issue (which someone has to 
write, on the other hand, of course).

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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 mainly be used by the FPL and FPM, perhaps it could simply be the
> rule that they got to decide what bugs went on it?

*nod*

Based on your other message elsewhere in the thread, I promise not to
pull you or anyone else in QA under the bus, but I mght drag Jan
Kurik with me as FPGM. Jan, what do you think about doing a Lightweight
Critical Issues Review Meeting every, say, two weeks? We could start it
with you and me and anyone else who wants to show up, and give it a
hard limit of half an hour.

Adam, if we do that, would it be hard to add to the existing
blockerbugs app, so we don't need to stand up new infrastructure?

Then we could try it for a bit and see if it is working / helpful or
just another crazy idea.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 them
> as blockers as normal and then during the blocker meeting
> when the vote says "no this is not a blocker" a second vote
> is done to see if it is a critical bug.

Let me phrase my earlier objection a little more strongly and
personally:

If someone tries to make me spend another three damn hours a week
reviewing 'proposed critical bugs' I'm going to jump out a window and
go start that yak farm. You won't see me for dust.

:P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Christian Stadelmann]

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 as a 
dump of bugs nobody cares about. I doubt you can fix this by process or rules, 
I think fixing it by manpower will be more successful. As far as I can see 
those package maintainers do their job pretty well except for the fact that 
they don't have enough time to do so.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Hans de Goede]

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 bugs better fixed than bugzilla 
entries will? Is this something people paid to work on Fedora (or perhaps 
centos and rhel for bugs in common with Fedora) can use to change their work 
priorities? Are we going to hope that volunteers will be more likely to notice 
bugs on this list than bugzilla. Or perhaps we hope to recruit volunteers who 
wouldn't normally work on a package to help out for these important bugs? 
(There are some really good packagers who could help out almost
anywhere but obviously have limited time and can't help everywhere.)


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 I would look at and see if there is
anything on there I can pick up.

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 them
as blockers as normal and then during the blocker meeting
when the vote says "no this is not a blocker" a second vote
is done to see if it is a critical bug.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Michael Catanzaro]

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 
> whether it fits into any kind of global formal criteria.

Hi,

If the Workstation WG were to have such a responsibility, I strongly
suspect we would prefer to delegate it to the existing QA team and
blocker bug process. It's been working pretty well for us and the WG is
not set up to handle minutiae like this.

We might meddle with the blocker criteria from time to time by
requesting new blocker criteria to fit a particular bug, but in general
I don't think it would be helpful to turn WG meetings into blocker
review meetings. The QA folks who currently handle blocker review are
doing a better job than we could anyway.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 
> whether it fits into any kind of global formal criteria.

We base the criteria heavily on SIG/WG input. I prefer this to the idea
of just letting SIGs/WGs declare whether bugs are blockers because the
point of the criteria is to try to produce consistent and predictable
decisions, so far as that's possible; if we just say 'blockers are
whatever SIGs decide' we're either going to get inconsistent decisions,
or we're going to have each SIG/WG having to do the work of
implementing criteria and a blocker review process separately, which
just seems like extra bureaucracy.

If you're unhappy with any of the criteria from a KDE perspective, we
absolutely can adjust them. We want the criteria to be agreed upon,
they're not carved in stone and imposed upon you.

Also, as a practical matter, the people who mainly actually show up to
do the work of blocker review are QA, releng and 'management' folks
(i.e. FPL and FPM). In theory blocker review is supposed to be done
with equal input from QA, 'development', releng and 'management', but
in practice we rarely get many 'development' folks showing up. sgallagh
is usually there and could be counted as a Server rep, we sometimes get
someone from Workstation, but there's rarely anyone from Cloud or KDE
(apologies if I'm forgetting anyone).

>  And punting 
> blockers should also only be possible if the responsible SIG/WG agrees with 
> it. As long as the SIGs and WGs for all release-blocking images have not 
> signed off on the release, we should slip, even if it takes weeks (and to 
> avoid long freezes, a slip should consist of accepting ALL pending updates 
> and restarting the freeze process from scratch – that should also 
> singificantly reduce the need for freeze exceptions).

I don't think this would be an improvement. As long as a 'Fedora
release' is as big and messy of a thing as it is right now, involving a
zillion deliverables and teams, I don't think it makes sense to declare
that certain groups have a complete veto on shipping. The current
process is pretty collaborative between all the stakeholder groups, I'd
say.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kevin Kofler]

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 looked at it, and
> even those involved in release wrangling had enough on their plates
> just dealing with the blocker list.

That's exactly the problem with such a process with no enforcement. I also 
doubt it is going to work.

> Blocker review is a rather resource-intensive process, where the
> resource involved are of the squishy human kind. I'm not sure anyone
> would be super-thrilled about spending several *extra* hours per week
> having bunfights about whether an issue is 'critical' or 'important'. I
> think if we're gonna go with this it might make sense to use a rather
> 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 mainly be used by the FPL and FPM, perhaps it could simply be the
> rule that they got to decide what bugs went on it?

Why would this need a centralized process at all? Why not just let the 
affected SIG or WG decide?

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 
whether it fits into any kind of global formal criteria. And punting 
blockers should also only be possible if the responsible SIG/WG agrees with 
it. As long as the SIGs and WGs for all release-blocking images have not 
signed off on the release, we should slip, even if it takes weeks (and to 
avoid long freezes, a slip should consist of accepting ALL pending updates 
and restarting the freeze process from scratch – that should also 
singificantly reduce the need for freeze exceptions).

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kevin Kofler]

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 Fedora
> Objective.
> 
> Since Fedora is a volunteer process, this can't be backed by a hard
> mandate (like the "block the release!" emergency brake)

And that is exactly why this will never work. As you wrote in the subject, 
blocking the release is our only "big hammer". So, if we are not willing to 
block the release for such issues (and I really mean BLOCK, even if it takes 
weeks! Right now, blockers are very quickly downgraded or "resolved" by 
merely documenting them, which defeats the purpose of them being blockers), 
they will never get fixed.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 exceptions when it makes sense to - i.e. when
we're actually in (or about to enter) a freeze. So there can be quite
long periods when proposed freeze exceptions aren't being reviewed.

There can also be bugs that are freeze exceptions but aren't actually
terribly important, funny as it may sound. For instance, we typically
grant freeze exceptions for fixing dependency errors, even if the
package with the error is something incredibly obscure that only two
people care about, just on the basis that it's nice to have as few
consistency issues in the 'frozen' release trees as possible. But if
it's a pretty obscure package, that's not really a terribly *important*
bug, it's just a cleanliness thing.

Another example along those lines...any non-blocking image being larger
than it's supposed to be is an automatic FE. But again, is it really
that *important* if the Astronomy spin is 10MiB too big? No disrespect
to our astronomer friends :)

The reverse case is also possible: there can be bugs that are quite
important but which it makes no sense to grant a freeze exception to,
because getting the fix into the frozen package set for a given
milestone isn't actually necessary to solve the problem.

So...the freeze exception bug list is actually not as good a proxy for
'non-blocker bugs we really care a lot about' as you might think.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Bruno Wolff III]

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 not necessarily fail a release criterion but which have
critical impact on a Fedora Edition or on a council-approved Fedora
Objective.


So how is this any different from freeze exceptions? Your email
acknowledges that freeze exceptions already exist, but doesn't describe
how you envision critical issues to function differently. What makes an
issue a freeze exception and not a critical issue, or vice-versa?


Freeze exceptions don't have to be critical bugs if they are low risk. 
For example fixes to packages that are on a non-releasing blocking spin 
can have a very low bar to cross since the chance of introducing a new 
blocker is very low.



Probably would should just use the existing freeze exception process
for this purpose? What's the benefit of adding another thing?


The freeze exceptions are often requested when there is already a fix or 
when one is anticipated. The list hasn't been useful for getting people 
to fix bugs that otherwise weren't being worked on.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 way is to stop the whole vehicle until
> someone does something about it. This has always been kind of
> problematic, even though it has served well enough so far... but as we
> move to more deliverables and add things with different lifecycles, I
> think we need something else.
> 
> We have the Accepted Blockers
> 
> list. The process is nicely documented at
> ; please
> read that if you're not familiar.
> 
> 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 Fedora
> Objective.

We used to have exactly this, up until Fedora 14. We had 'Target'
trackers as well as 'Blocker' trackers. Fedora 14 was in fact a rather
special release as it had all three concepts: 'blocker', 'freeze
exception' (though we called these something else at the time) and
'target'. (F13 had a 'Target' tracker but no freeze exception trackers,
F15 had blocker and freeze exception trackers but no 'Target' tracker).
Here's the F14 Beta blocker tracker:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=611991

the Beta freeze exception tracker:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=634253

and the 'Target' tracker (we never split these by milestone):

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=538278

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 looked at it, and
even those involved in release wrangling had enough on their plates
just dealing with the blocker list.

At that point the blocker process was rather less defined than it is
now, and there was absolutely no kind of 'process' around the Target
tracker - it just got created, there was no kind of process that made
it anyone's job to actually care about the bugs on the list - so it's
possible that this idea could fly better with some kind of process
around it. But I think it's worth noting we had this before and
explicitly stopped doing it because it was kinda pointless.

> We could either implement this by extending the existing blocker bug
> process — adding a new tracker bug, add a new category in the
> blockerbug app, and review candidate issues at the normal blocker
> review meetings. Or, it could be done in parallel, with a
> separately-configured instance of the blockerbug app and with review
> in a separate meeting called as needed (or maybe just FESCo?)
> 
> As with the existing Blocker or Freeze Exception levels, we could also
> introduce a second tier "Important Issues", which could have a wider
> net than the rules for "Critical Issues". I'm not sure about that.
> 
> In any case, what do you all think?

Blocker review is a rather resource-intensive process, where the
resource involved are of the squishy human kind. I'm not sure anyone
would be super-thrilled about spending several *extra* hours per week
having bunfights about whether an issue is 'critical' or 'important'. I
think if we're gonna go with this it might make sense to use a rather
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 mainly be used by the FPL and FPM, perhaps it could simply be the
rule that they got to decide what bugs went on it?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Michael Catanzaro]

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 Fedora Edition or on a council-approved Fedora
> Objective.

So how is this any different from freeze exceptions? Your email
acknowledges that freeze exceptions already exist, but doesn't describe
how you envision critical issues to function differently. What makes an
issue a freeze exception and not a critical issue, or vice-versa?

Probably would should just use the existing freeze exception process
for this purpose? What's the benefit of adding another thing?

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Kevin Fenzi]

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 those around milestones and I guess this might
be more coverage for other times... 

I'm willing to try a more formal system, but I'm not convinced it will
help out too much. 

kevin




pgpqJfH21Ir6M.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Ian Pilcher]

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
strong signal that a bug is deemed worthy of attention by someone other
than the reporter.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Josh Boyer]

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 "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 it. This has always been kind of
>> problematic, even though it has served well enough so far... but as we
>> move to more deliverables and add things with different lifecycles, I
>> think we need something else.
>>
>> We have the Accepted Blockers
>> 
>> list. The process is nicely documented at
>> ; please
>> read that if you're not familiar.
>>
>> 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 Fedora
>> Objective.
>>
>> Since Fedora is a volunteer process, this can't be backed by a hard
>> mandate (like the "block the release!" emergency brake), but if we
>> agree together to take it seriously, I think it will still provide a
>> useful list. Anyone with a package or component involved in the issue
>> will be able to see the impact, and take that into account when
>> prioritizing. As FPL, it'd give me a nice overview of issues that might
>> need extra resources or coordination.
>>
>> We could either implement this by extending the existing blocker bug
>> process — adding a new tracker bug, add a new category in the
>> blockerbug app, and review candidate issues at the normal blocker
>> review meetings. Or, it could be done in parallel, with a
>> separately-configured instance of the blockerbug app and with review
>> in a separate meeting called as needed (or maybe just FESCo?)
>>
>> As with the existing Blocker or Freeze Exception levels, we could also
>> introduce a second tier "Important Issues", which could have a wider
>> net than the rules for "Critical Issues". I'm not sure about that.
>>
>> In any case, what do you all think?
>
>
> If this can be prominently included in a concise "how you can help
> make Fedora better" as a form of contributor recruitment, it'd
> probably be more enticing as well as helpful. If there were some

The issue I see with that is if these are critical fixes that aren't
being fixed, the likelyhood of a new contributor coming in and fixing
them in a timely fashion is pretty low.  What Matthew is really after
is a prioritization problem for critical resources.

> consolidated, yet sortable list of To Do's: sortable by priority, and
> by expertise needed, and maybe an effort estimate, I think we'd find
> many small things getting more attention. It'd be easy to dive in, do
> something, finish it, and duck out.

That is completely orthogonal to what Matthew is talking about.  We
already have 'what can you do for Fedora' so if we need to expand
that, let's start a different discussion.

> A way of advertising a path to getting more intermediate-expert types,
> rather than having to always depend on the same people for blockers
> and big fixes every release.

Where do you foresee these people coming from?  Or rather, why aren't
they already involved?

> Also a nice to have with this would be a Fantasy Fedora mechanism. A
> way to put together a virtual team and send out invites: here's
> something that needs work, what do you three people think of solving
> this problem together?

How is that not just sending an email?

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Chris Murphy]

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
> focused on it?" — and that way is to stop the whole vehicle until
> someone does something about it. This has always been kind of
> problematic, even though it has served well enough so far... but as we
> move to more deliverables and add things with different lifecycles, I
> think we need something else.
>
> We have the Accepted Blockers
> 
> list. The process is nicely documented at
> ; please
> read that if you're not familiar.
>
> 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 Fedora
> Objective.
>
> Since Fedora is a volunteer process, this can't be backed by a hard
> mandate (like the "block the release!" emergency brake), but if we
> agree together to take it seriously, I think it will still provide a
> useful list. Anyone with a package or component involved in the issue
> will be able to see the impact, and take that into account when
> prioritizing. As FPL, it'd give me a nice overview of issues that might
> need extra resources or coordination.
>
> We could either implement this by extending the existing blocker bug
> process — adding a new tracker bug, add a new category in the
> blockerbug app, and review candidate issues at the normal blocker
> review meetings. Or, it could be done in parallel, with a
> separately-configured instance of the blockerbug app and with review
> in a separate meeting called as needed (or maybe just FESCo?)
>
> As with the existing Blocker or Freeze Exception levels, we could also
> introduce a second tier "Important Issues", which could have a wider
> net than the rules for "Critical Issues". I'm not sure about that.
>
> In any case, what do you all think?


If this can be prominently included in a concise "how you can help
make Fedora better" as a form of contributor recruitment, it'd
probably be more enticing as well as helpful. If there were some
consolidated, yet sortable list of To Do's: sortable by priority, and
by expertise needed, and maybe an effort estimate, I think we'd find
many small things getting more attention. It'd be easy to dive in, do
something, finish it, and duck out.

A way of advertising a path to getting more intermediate-expert types,
rather than having to always depend on the same people for blockers
and big fixes every release.

Also a nice to have with this would be a Fantasy Fedora mechanism. A
way to put together a virtual team and send out invites: here's
something that needs work, what do you three people think of solving
this problem together?


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Tim Flink]

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 doing with that tracker bug.

The purpose of the Freeze Exception (formerly NTH) bugs is to mark
issues which are serious but not blockers which generally can't be
fixed through a 0-day release. If a working fix becomes available
during freeze, that fix will be eligible to be pulled into stable as a
special case.

Tim


pgp5R7L91ENpX.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Bruno Wolff III]

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. 
Those are bugs that are worth breaking a freeze in order to get a fix in, 
but aren't worth delaying the release for.


The issue we are trying to fix, is getting important bugs (blocker or not) 
attention from people who are capable of fixing them. That can sometimes 
be hard to do.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Bruno Wolff III]

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? Is this something people paid to work on Fedora (or perhaps 
centos and rhel for bugs in common with Fedora) can use to change their 
work priorities? Are we going to hope that volunteers will be more likely 
to notice bugs on this list than bugzilla. Or perhaps we hope to recruit 
volunteers who wouldn't normally work on a package to help out for these 
important bugs? (There are some really good packagers who could help out 
almost anywhere but obviously have limited time and can't help everywhere.)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Michael Cronenworth]

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