FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-02-2011, 08:54 PM
Adam Williamson
 
Default Marking zapped bugs

On Fri, 2011-09-02 at 16:43 -0400, Matt McCutchen wrote:
> On Fri, 2011-09-02 at 12:29 -0700, Adam Williamson wrote:
> > On Fri, 2011-09-02 at 14:01 -0400, Matt McCutchen wrote:
> >
> > > What you're really saying is that most maintainers want to work from a
> > > list of unexpired bugs. But there are ways to achieve that other than
> > > marking all the expired bugs WONTFIX. Maintainers can always filter on
> > > the currently maintained Fedora versions, but it becomes tedious to
> > > configure that, which is where a virtual EXPIRED resolution exposed by
> > > Bugzilla would come in handy.
> >
> > Mostly your proposal makes sense,
>
> Thanks for the response.
>
> > but we're trying very hard to stick to
> > upstream Bugzilla since 3.x, as heavy customization of 2.x caused more
> > problems than it solved. So we're reluctant to add resolutions and
> > statuses that don't exist upstream - even if Mozilla have hacked up
> > their own copy of their own upstream bug reporting system to add
> > resolutions...
>
> I don't buy that: Red Hat Bugzilla currently has 4 upstream resolutions
> to 7 custom ones. Are all the custom resolutions actively being phased
> out? Otherwise, can you give some examples to illustrate the marginal
> harm likely to occur if an 8th custom resolution is added?

Hum, I didn't realize our resolutions were so customized, I thought they
were the upstream ones; this is what I've been told when discussing
custom resolutions in the past. It's certainly something you could
propose as an enhancement by filing a bug against Bugzilla, then.

> 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX
> (semantically questionable on its face, but maybe reasonable in light of
> the explanation on
> https://bugzilla.redhat.com/page.cgi?id=fields.html#status ).

As noted at the top of that page, that is the policy for RHEL, not for
Fedora. Fedora policy is
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It
states only "The resolutions CANTFIX, WONTFIX, and WORKSFORME are for
use by maintainers only, and are self-explanatory."

> 3. Do not change the bug state, and have maintainers apply the same
> conditions now used by the bug zapper on all of their searches.
> Reducing mutable state is generally good in that it reduces the possible
> ways for things to get out of whack. But then it takes more work to see
> whether a non-CLOSED bug is expired.
> 3a. Like #3, but make it easier with a virtual EXPIRED resolution.
> Probably an undesirable level of customization to Bugzilla.
> 4. Add an "Expired" keyword or custom field, use it, and:
> 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the
> keyword/field in search and maybe even get it to show as a column on
> search results.
> 4b. Do not change the status, and have maintainers use the
> keyword/field in their search.

I think if we're going to change this, the only sensible change is to
use a different CLOSED resolution. All the others seem like hacks which
are likely to cause more trouble/confusion than they resolve. We clearly
want to bugs to be CLOSED, not open with a quasi-closed keyword or
whiteboard field.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-02-2011, 10:33 PM
Matt McCutchen
 
Default Marking zapped bugs

On Fri, 2011-09-02 at 13:54 -0700, Adam Williamson wrote:
> Hum, I didn't realize our resolutions were so customized, I thought they
> were the upstream ones; this is what I've been told when discussing
> custom resolutions in the past. It's certainly something you could
> propose as an enhancement by filing a bug against Bugzilla, then.

OK, I will do that and post the link here. Any assessment of difficulty
provided by the Bugzilla team can inform a decision between 2a and 2b.

> > 2b. Co-opt an existing little-used custom resolution, e.g., CANTFIX
> > (semantically questionable on its face, but maybe reasonable in light of
> > the explanation on
> > https://bugzilla.redhat.com/page.cgi?id=fields.html#status ).
>
> As noted at the top of that page, that is the policy for RHEL, not for
> Fedora. Fedora policy is
> https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#CLOSED . It
> states only "The resolutions CANTFIX, WONTFIX, and WORKSFORME are for
> use by maintainers only, and are self-explanatory."

You are right. But taking a step back, the project has the power to
change the policy to best meet its needs. My point stands that the
resolution is little-used (less than 2% [1]), and its use for expired
bugs would harmonize with the current RHEL policy. None of my 131 bugs
have been marked CANTFIX [2]; maintainers seem to find that the
better-known WONTFIX and NOTABUG cover the range of cases.

[1] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field=resol ution&query_format=report-table&product=Fedora&format=table&action=wrap)
[2] https://bugzilla.redhat.com/report.cgi?x_axis_field=version&y_axis_field=resol ution&query_format=report-table&product=Fedora&emailreporter1=1&emailtype1=e xact&email1=matt%40mattmccutchen.net&format=table& action=wrap

> > 3. Do not change the bug state, and have maintainers apply the same
> > conditions now used by the bug zapper on all of their searches.
> > Reducing mutable state is generally good in that it reduces the possible
> > ways for things to get out of whack. But then it takes more work to see
> > whether a non-CLOSED bug is expired.
> > 3a. Like #3, but make it easier with a virtual EXPIRED resolution.
> > Probably an undesirable level of customization to Bugzilla.
> > 4. Add an "Expired" keyword or custom field, use it, and:
> > 4a. Continue to close the bugs WONTFIX. Ugh, but I can use the
> > keyword/field in search and maybe even get it to show as a column on
> > search results.
> > 4b. Do not change the status, and have maintainers use the
> > keyword/field in their search.
>
> I think if we're going to change this, the only sensible change is to
> use a different CLOSED resolution. All the others seem like hacks which
> are likely to cause more trouble/confusion than they resolve.

Fair assessment.

> We clearly
> want to bugs to be CLOSED, not open with a quasi-closed keyword or
> whiteboard field.

I'm not sure who "we" is, but I disagree. The generally accepted
definition of CLOSED is that the resolution is final unless subsequent
events invalidate the original rationale. (C.f. the RHEL policy: "The
bug is considered dead, the resolution is correct.") All it takes for
an expired bug to be reopened is for someone to have enough interest to
retest it in a maintained Fedora version. To claim that this meets the
definition of CLOSED is a big stretch. I believe that "expired" should
properly be its own major state alongside "open" and "closed", but we
have alternatives that are less radical and still solve the immediate
problem with search.

--
Matt

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-02-2011, 10:43 PM
Adam Williamson
 
Default Marking zapped bugs

On Fri, 2011-09-02 at 18:33 -0400, Matt McCutchen wrote:

> > We clearly
> > want to bugs to be CLOSED, not open with a quasi-closed keyword or
> > whiteboard field.
>
> I'm not sure who "we" is, but I disagree. The generally accepted
> definition of CLOSED is that the resolution is final unless subsequent
> events invalidate the original rationale. (C.f. the RHEL policy: "The
> bug is considered dead, the resolution is correct.") All it takes for
> an expired bug to be reopened is for someone to have enough interest to
> retest it in a maintained Fedora version. To claim that this meets the
> definition of CLOSED is a big stretch. I believe that "expired" should
> properly be its own major state alongside "open" and "closed", but we
> have alternatives that are less radical and still solve the immediate
> problem with search.

The reason for the auto-closing is 'problems with search': developers do
not want to have searches for open bugs cluttered up with bugs for
ancient versions. Any change which involves not closing the old bugs
will result in the auto-close procedure not solving this problem any
more, because the bugs will show up in a default search, and - as you
mentioned - developers will have to remember to customize their searches
every time to cover only currently-active versions. If we were to do
that we might as well not do anything to old bugs automatically at all,
because it's about as easy to customize a search to 'fedora 14, fedora
15, fedora 16, rawhide' as it is to customize it to 'no bugs with
keyword EXPIRED'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-02-2011, 11:00 PM
Emmanuel Seyman
 
Default Marking zapped bugs

* Adam Williamson [03/09/2011 00:21] :
>
> Hum, I didn't realize our resolutions were so customized, I thought they
> were the upstream ones; this is what I've been told when discussing
> custom resolutions in the past. It's certainly something you could
> propose as an enhancement by filing a bug against Bugzilla, then.

Custom resolutions these days fall in the configration scope. There is no
hacking of code required.

Emmanuel

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 02:33 AM
Matt McCutchen
 
Default Marking zapped bugs

On Fri, 2011-09-02 at 15:43 -0700, Adam Williamson wrote:
> On Fri, 2011-09-02 at 18:33 -0400, Matt McCutchen wrote:
>
> > > We clearly
> > > want to bugs to be CLOSED, not open with a quasi-closed keyword or
> > > whiteboard field.
> >
> > I'm not sure who "we" is, but I disagree. The generally accepted
> > definition of CLOSED is that the resolution is final unless subsequent
> > events invalidate the original rationale. (C.f. the RHEL policy: "The
> > bug is considered dead, the resolution is correct.") All it takes for
> > an expired bug to be reopened is for someone to have enough interest to
> > retest it in a maintained Fedora version. To claim that this meets the
> > definition of CLOSED is a big stretch. I believe that "expired" should
> > properly be its own major state alongside "open" and "closed", but we
> > have alternatives that are less radical and still solve the immediate
> > problem with search.
>
> The reason for the auto-closing is 'problems with search': developers do
> not want to have searches for open bugs cluttered up with bugs for
> ancient versions.

Yes, of course. I was only responding to your apparent claim (at the
top) that the use of CLOSED is semantically desirable.

> Any change which involves not closing the old bugs
> will result in the auto-close procedure not solving this problem any
> more, because the bugs will show up in a default search, and - as you
> mentioned - developers will have to remember to customize their searches
> every time to cover only currently-active versions.

You are assuming that developers start from the default search to bring
up their work lists. Do they? There are alternatives:

- We can set up a shortened URL for a "Fedora developer default search"
that pre-fills the appropriate fields on the query form, e.g.,
https://bugzilla.redhat.com/query.cgi?classification=Fedora&product=Fedora&ver sion=14&version=15&version=16&version=rawhide . This would also save the "Refresh Components" latency.

- They could use a saved query, which would change either every 6 months
or not at all.

- They could use http://bugz.fedoraproject.org/%s, which can be changed
to do whatever they generally want.

If we insist that the default search exclude expired bugs, it is already
customized (compare https://bugzilla.redhat.com/query.cgi to
https://landfill.bugzilla.org/bugzilla-tip/query.cgi?format=advanced),
so we may be able to make a further customization to exclude expired
Fedora bugs without affecting other products. But IMO, the default
search should target the most common use case, which may well be users
if developers do most of their queries a different way.

My intent in putting forth this argument is to get past preconceptions
and accurately assess the real drawbacks of approaches that do not close
the bugs, since they are slightly better semantically. If the community
still feels the idea is too radical, using an EXPIRED or CANTFIX
resolution would still solve my problem.

> If we were to do
> that we might as well not do anything to old bugs automatically at all,
> because it's about as easy to customize a search to 'fedora 14, fedora
> 15, fedora 16, rawhide' as it is to customize it to 'no bugs with
> keyword EXPIRED'.

Not quite: you don't have to remember which Fedora versions are
maintained, or alternatively, update your saved queries every six
months. And aside from search, marking expired bugs has the important
function of cluing in the reporter that they should expect no action
under the expiration policy.

--
Matt

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 08:45 AM
Matej Cepl
 
Default Marking zapped bugs

Dne 2.9.2011 22:54, Adam Williamson napsal(a):
> Hum, I didn't realize our resolutions were so customized, I thought they
> were the upstream ones; this is what I've been told when discussing
> custom resolutions in the past. It's certainly something you could
> propose as an enhancement by filing a bug against Bugzilla, then.

If we had upstream’s UNCONFIRMED we wouldn't have to play with the
Triaged keyword (although the meaning is subtly different).

Matěj

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-03-2011, 08:46 AM
Matej Cepl
 
Default Marking zapped bugs

Dne 3.9.2011 00:33, Matt McCutchen napsal(a):
> bugs would harmonize with the current RHEL policy. None of my 131 bugs
> have been marked CANTFIX [2]; maintainers seem to find that the
> better-known WONTFIX and NOTABUG cover the range of cases.

I use it routinely as a polite version of WONTFIX for Xorg bugs with
nvidia binary driver. But yes, that's not a big deal.

Matěj

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-07-2011, 07:17 PM
Adam Williamson
 
Default Marking zapped bugs

On Sat, 2011-09-03 at 10:45 +0200, Matej Cepl wrote:
> Dne 2.9.2011 22:54, Adam Williamson napsal(a):
> > Hum, I didn't realize our resolutions were so customized, I thought they
> > were the upstream ones; this is what I've been told when discussing
> > custom resolutions in the past. It's certainly something you could
> > propose as an enhancement by filing a bug against Bugzilla, then.
>
> If we had upstream’s UNCONFIRMED we wouldn't have to play with the
> Triaged keyword (although the meaning is subtly different).

More than subtly. We explicitly *don't* require triagers to confirm bugs
on their own systems.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org