Stale BZ Bug Tracker reports

[William A Rowe Jr <wr...@rowe-clan.net>]

There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or
NEEDINFO with no Resolution.

For these bugs I believe we should simply close them with a message that
this is a mass-update, that the version is beyond EOL, and a request for
reporters/observers to retest and reopen with the supported version number
if they are still reproducible using a modern 2.4.x version. But I can't
determine the best Status/Resolution code... suggestions?

There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?). These
should likely be reviewed by hand and either ACCEPTED against 2.4-HEAD,
tagged NEEDINFO with a request to re-review (after mass-cleanup of NEEDINFO
above), or closed as above with an invitation to retest and reopen.

There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are over
three years old. For these, the best resolution is probably NEEDINFO. And
there are 38 2.4.x NEEDINFO bugs, most of which can likely be closed for
good as INVALID under a manual review.

I'm thinking of generic comment which would read (2nd paragraph for
2.0-2.3.x only);

"""
Please help us to refine our list of open and current defects. This is a
mass update of older Bugzilla reports which reflect user error, already
resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued
all development and patch review of the 2.2.x series of releases. The final
release 2.2.34 was published in July 2017, and no further evaluation of bug
reports or security risks will be considered or published for 2.2.x
releases.
If your report represented a question or confusion about how to use an
httpd feature, an unexpected server behavior, problems building or
installing httpd, or working with an external component (a third party
module, browser etc.) we ask you to start by bringing your question to the
User Support and Discussion mailing list, see [
https://httpd.apache.org/lists.html#http-users] for details. Include a link
to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd, we ask that you retest using
a modern httpd release (2.4.33 or later) released in the past year. If it
can be reproduced, please reopen this bug and change the Version field
above to the httpd version you have reconfirmed with.

Your help in identifying only current defects in the httpd server software
is greatly appreciated.
"""

Comments, suggestions and other feedback before we proceed to take a broad
scythe to the stale reports?

Re: [resolution] Stale BZ Bug Tracker reports

[William A Rowe Jr <wr...@rowe-clan.net>]

I clicked send on this note, before I saw the deluge.

What we would not want is to hide closure notices to the cc recipients on
the issue. We would not want to remove bugs@ from the issue itself. And
anyone reconfirming a ticket is not stale is going to the bugs@
notification list.

My only thought on avoiding this in the future is to suspend the bugs@ list
entirely for a several minute period while the mass update notifications
are sent. Then restore the normal list behavior.

If you simply want to hide this mass update, I would unthread your mail
reader, and mass select and delete all email notices during that small 5
minute window.

Another option, I kept with threading, and mass deleted only those updates
with no other notices in a multi-year period. I'm now going back over some
70 closures which had an active discussion at some point in the not so
distant past.

Sorry for this somewhat painful side effect of this cleanup operation.
Since we've decided most other updates will employ some level of manual
scrutiny and intervention, there shouldn't be another burst of notices for
some years to come.

Re: [resolution] Stale BZ Bug Tracker reports

[Yann Ylavic <yl...@gmail.com>]

Hi Bill,

On Wed, Nov 7, 2018 at 10:22 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Mass update completed.

Would it be possible now to have buz send us an email on bugs@ (and
possibly only bugs@) for tickets still in the "open" field (i.e. not
resolved/invalid/...)?

For those of us who track bz but by email, the massive update has put
stale entries on the top of the list...
Emails are easier to follow (IMHO), and getting an update for "open"
entries shouldn't hurt (provided it does not ping the OP/CCs too), and
could even ring some bells for each of us.

Thanks for update work in any case!

Regards,
Yann.

[resolution] Stale BZ Bug Tracker reports

[William A Rowe Jr <wr...@rowe-clan.net>]

Mass update completed. Search criteria;

Version: 2.0-HEAD, 2.0.32, 2.0.35, 2.0.36, 2.0.39, 2.0.40, 2.0.42, 2.0.43,
2.0.44, 2.0.45, 2.0.46, 2.0.47, 2.0.48, 2.0.49, 2.0.50, 2.0.51, 2.0.52,
2.0.53, 2.0.54, 2.0.55, 2.0.58, 2.0.59, 2.0.61, 2.0.63, 2.0.64, 2.0.65,
2.1-HEAD, 2.2-HEAD, 2.2.0, 2.2.2, 2.2.3, 2.2.4, 2.2.6, 2.2.8, 2.2.9,
2.2.10, 2.2.11, 2.2.12, 2.2.13, 2.2.14, 2.2.15, 2.2.16, 2.2.17, 2.2.18,
2.2.19, 2.2.20, 2.2.21, 2.2.22, 2.2.23, 2.2.24, 2.2.25, 2.2.26, 2.2.27,
2.2.29, 2.2.31, 2.2.32, 2.2.33, 2.2.34, 2.3.11-beta, 2.3.12-beta,
2.3.14-beta, 2.3.15-beta Resolution: --- Status: NEW, NEEDINFO Product:
Apache httpd-2

715 bugs found.

Status updated; RESOLVED, LATER
Keyword added; MassUpdate
Comment added;
Please help us to refine our list of open and current defects; this is a
mass update of old and inactive Bugzilla reports which reflect user error,
already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued
all development and patch review of the 2.2.x series of releases. The final
release 2.2.34 was published in July 2017, and no further evaluation of bug
reports or security risks will be considered or published for 2.2.x
releases. All reports older than 2.4.x have been updated to status
RESOLVED/LATER; no further action is expected unless the report still
applies to a current version of httpd.

If your report represented a question or confusion about how to use an
httpd feature, an unexpected server behavior, problems building or
installing httpd, or working with an external component (a third party
module, browser etc.) we ask you to start by bringing your question to the
User Support and Discussion mailing list, see [
https://httpd.apache.org/lists.html#http-users] for details. Include a link
to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask
that you retest using a modern httpd release (2.4.33 or later) released in
the past year. If it can be reproduced, please reopen this bug and change
the Version field above to the httpd version you have reconfirmed with.

Your help in identifying the defects or enhancements to the current httpd
server software is greatly appreciated.

Re: Stale BZ Bug Tracker reports

[William A Rowe Jr <wr...@rowe-clan.net>]

On Fri, Nov 2, 2018, 06:24 Luca Toscano <toscano.luca@gmail.com wrote:

> Il giorno gio 1 nov 2018 alle ore 22:35 William A Rowe Jr
> <wr...@rowe-clan.net> ha scritto:
> >
> > To keep this thread moving (additional feedback is welcomed and
> appreciated)...
>
> Thanks a lot for this effort William, I really think that having 1700+
> bugs opened does not look good for any reporter/user that doesn't know
> how we work, since it is easy to get the impression that bugs are
> simply opened to take dust for ages (thing that doesn't really
> happen).
>
>
> >
> > So I'd read this as the bug needs to be reproduced with a "later"
> version of httpd, and is subject to reconsideration "later" on further
> review, but may have already been resolved in a "later" release.
>
> The RESOLVED/FUTURE seems a bit confusing from my point of view, but I
> don't really have any good suggestion.. I would personally stick with
> something that clearly indicates that the bug was closed due to being
> too old.
>
> [Generic text comment proposed]
>
> +1 nice!
>
> > Edits noted, thanks!
>

It seems I should define that this bug may be reevaluated "LATER" and we
are asking for their help to close or reopen against a current flavor. I'll
work up a small tweak to the language we've agreed on.

We've given this enough cycles, I'll proceed to the initial step. Looking
for any tweaks which might let bugs mentioning "2.4." in the discussing to
be calldd out for manual reevaluation.

Re: Stale BZ Bug Tracker reports

[Luca Toscano <to...@gmail.com>]

Il giorno gio 1 nov 2018 alle ore 22:35 William A Rowe Jr
<wr...@rowe-clan.net> ha scritto:
>
> To keep this thread moving (additional feedback is welcomed and appreciated)...

Thanks a lot for this effort William, I really think that having 1700+
bugs opened does not look good for any reporter/user that doesn't know
how we work, since it is easy to get the impression that bugs are
simply opened to take dust for ages (thing that doesn't really
happen).

>
> On Thu, Nov 1, 2018 at 5:03 AM Marion & Christophe JAILLET <ch...@wanadoo.fr> wrote:
> >
> > Le 31/10/2018 à 21:52, William A Rowe Jr a écrit :
> > >
> > > There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or NEEDINFO with no Resolution.
> > >
> > > For these bugs I believe we should simply close them with a message that this is a mass-update, that the version is beyond EOL, and a request for reporters/observers to retest and reopen with the supported version number if they are still reproducible using a modern 2.4.x version. But I can't determine the best Status/Resolution code... suggestions?
> >
> > +1
> > IMHO, the best status would be CLOSED/WONTFIX. Maybe a new Keyword such as TooOldAndInactive to ease finding such mass-update?
> > Or ask for a new status TOO_OLD (but I'm not sure it would really be that useful)
>
> I agree a keyword MassUpdate would be helpful to later identify all tickets closed in any automated way.
>
> WONTFIX doesn't seem to fit; 1) a subset of these have been FIXED,  2) a subset are INVALID, 3) there is a WONTFIX subset (applying to 2.5.x as well.)
>
> I think a new status is right, perhaps RESOLVED/FUTURE is the best course for the mass-change of these defects that are unlikely to be reviewed by the project community in their present state. They are in fact NEEDINFO (we need info that a) there is a bug and b) it still exists), but since we don't have that as a closure state, RESOLVED/FUTURE seems like the best catch-all. Of course this label is no longer endorsed by the bugzilla team, but they don't seem to have substituted anything else; https://bugs.eclipse.org/bugs/show_bug.cgi?id=178923
>
> So I'd read this as the bug needs to be reproduced with a "later" version of httpd, and is subject to reconsideration "later" on further review, but may have already been resolved in a "later" release.

The RESOLVED/FUTURE seems a bit confusing from my point of view, but I
don't really have any good suggestion.. I would personally stick with
something that clearly indicates that the bug was closed due to being
too old.

> > > There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?). These should likely be reviewed by hand and either ACCEPTED against 2.4-HEAD, tagged NEEDINFO with a request to re-review (after mass-cleanup of NEEDINFO above), or closed as above with an invitation to retest and reopen.
> >
> > +1, after by-hand review, as proposed.

+1

> > > There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are over three years old. For these, the best resolution is probably NEEDINFO.
> >
> > -1.
> > Not sure NEEDINFO is fine for these ones. We should set NEEDINFO after by hand review, if we NEEDINFO. Or close it if invalid, or leave it as is if it looks right but no one has looked at it.
> > The reporter has done his job. He has reported what he thinks is enough. WE should provide an answer or ask for more details.

I agree, even if this effort might be big, sometimes the "history" of
a bug is so long and inconclusive that it is really difficult to judge
what it is the current status. In my opinion we should think about a
quick procedure to keep or close these tasks and apply to all of them.

> You are signing up to reproduce and validate that all of the bugs still exist in the current tree?  I agree that reviewing these 255 bugs would be a noble goal, but who is signing up to the task? Will we simply wait until 2.6.0 has been around for a year or two and then reap all the bugs as described above? I propose we do ask for more details, specifically, that their reported bug still exists, on the presumption it is a bug.
>
> This merits further discussion, and I'm not moving ahead till we've come to some concensus, but we would do well to decide what we are doing here with the group of 3 to 8 year old flavors of 2.4.x.
>
> > > And there are 38 2.4.x NEEDINFO bugs, most of which can likely be closed for good as INVALID under a manual review.
> >
> > +1 if older than, let say, 1 year?
> > The number is small, they could also be doubled check by hand. But is is likely, that it would end as INVALID because the analysis has already been done, and the reporter does not seem to be interested to answer.

+1

> This number is small, and I am proposing this is a manual effort to either bump the version number perhaps with help from a NEEDINFO request, or closing as INVALID where they are actually not bugs.
>
> > > I'm thinking of generic comment which would read (2nd paragraph for 2.0-2.3.x only);
> > >
> > > """
> > > Please help us to refine our list of open and current defects. This is a mass update of older Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.
> >
> > [...]. This is a mass update of old and inactive reports [...]
> >
> > > As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases.
> > >
> > > If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.
> > >
> > > If your report was clearly a defect in httpd, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.
> >
> > [...] a defect in httpd or a feature request [...]
> >
> > > Your help in identifying only current defects in the httpd server software is greatly appreciated.
> > > """
>

+1 nice!

> Edits noted, thanks!
>
> >> Comments, suggestions and other feedback before we proceed to take a broad scythe to the stale reports?
> >
> > We should also forbid bug report against 2.2.x.
>
> This was annoying, since there was no mass-update feature, but is now done. New bug creation is now restricted to 2.4.x or 2.4/2.5-HEAD.

Nice!

Luca

Re: Stale BZ Bug Tracker reports

[William A Rowe Jr <wr...@rowe-clan.net>]

To keep this thread moving (additional feedback is welcomed and
appreciated)...

On Thu, Nov 1, 2018 at 5:03 AM Marion & Christophe JAILLET <
christophe.jaillet@wanadoo.fr> wrote:
>
> Le 31/10/2018 à 21:52, William A Rowe Jr a écrit :
> >
> > There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or
NEEDINFO with no Resolution.
> >
> > For these bugs I believe we should simply close them with a message
that this is a mass-update, that the version is beyond EOL, and a request
for reporters/observers to retest and reopen with the supported version
number if they are still reproducible using a modern 2.4.x version. But I
can't determine the best Status/Resolution code... suggestions?
>
> +1
> IMHO, the best status would be CLOSED/WONTFIX. Maybe a new Keyword such
as TooOldAndInactive to ease finding such mass-update?
> Or ask for a new status TOO_OLD (but I'm not sure it would really be that
useful)

I agree a keyword MassUpdate would be helpful to later identify all tickets
closed in any automated way.

WONTFIX doesn't seem to fit; 1) a subset of these have been FIXED,  2) a
subset are INVALID, 3) there is a WONTFIX subset (applying to 2.5.x as
well.)

I think a new status is right, perhaps RESOLVED/FUTURE is the best course
for the mass-change of these defects that are unlikely to be reviewed by
the project community in their present state. They are in fact NEEDINFO (we
need info that a) there is a bug and b) it still exists), but since we
don't have that as a closure state, RESOLVED/FUTURE seems like the best
catch-all. Of course this label is no longer endorsed by the bugzilla team,
but they don't seem to have substituted anything else;
https://bugs.eclipse.org/bugs/show_bug.cgi?id=178923

So I'd read this as the bug needs to be reproduced with a "later" version
of httpd, and is subject to reconsideration "later" on further review, but
may have already been resolved in a "later" release.

> > There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?).
These should likely be reviewed by hand and either ACCEPTED against
2.4-HEAD, tagged NEEDINFO with a request to re-review (after mass-cleanup
of NEEDINFO above), or closed as above with an invitation to retest and
reopen.
>
> +1, after by-hand review, as proposed.
>
> > There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are
over three years old. For these, the best resolution is probably NEEDINFO.
>
> -1.
> Not sure NEEDINFO is fine for these ones. We should set NEEDINFO after by
hand review, if we NEEDINFO. Or close it if invalid, or leave it as is if
it looks right but no one has looked at it.
> The reporter has done his job. He has reported what he thinks is enough.
WE should provide an answer or ask for more details.

You are signing up to reproduce and validate that all of the bugs still
exist in the current tree?  I agree that reviewing these 255 bugs would be
a noble goal, but who is signing up to the task? Will we simply wait until
2.6.0 has been around for a year or two and then reap all the bugs as
described above? I propose we do ask for more details, specifically, that
their reported bug still exists, on the presumption it is a bug.

This merits further discussion, and I'm not moving ahead till we've come to
some concensus, but we would do well to decide what we are doing here with
the group of 3 to 8 year old flavors of 2.4.x.

> > And there are 38 2.4.x NEEDINFO bugs, most of which can likely be
closed for good as INVALID under a manual review.
>
> +1 if older than, let say, 1 year?
> The number is small, they could also be doubled check by hand. But is is
likely, that it would end as INVALID because the analysis has already been
done, and the reporter does not seem to be interested to answer.

This number is small, and I am proposing this is a manual effort to either
bump the version number perhaps with help from a NEEDINFO request, or
closing as INVALID where they are actually not bugs.

> > I'm thinking of generic comment which would read (2nd paragraph for
2.0-2.3.x only);
> >
> > """
> > Please help us to refine our list of open and current defects. This is
a mass update of older Bugzilla reports which reflect user error, already
resolved defects, and still-existing defects in httpd.
>
> [...]. This is a mass update of old and inactive reports [...]
>
> > As repeatedly announced, the Apache HTTP Server Project has
discontinued all development and patch review of the 2.2.x series of
releases. The final release 2.2.34 was published in July 2017, and no
further evaluation of bug reports or security risks will be considered or
published for 2.2.x releases.
> >
> > If your report represented a question or confusion about how to use an
httpd feature, an unexpected server behavior, problems building or
installing httpd, or working with an external component (a third party
module, browser etc.) we ask you to start by bringing your question to the
User Support and Discussion mailing list, see [
https://httpd.apache.org/lists.html#http-users] for details. Include a link
to this Bugzilla report for completeness with your question.
> >
> > If your report was clearly a defect in httpd, we ask that you retest
using a modern httpd release (2.4.33 or later) released in the past year.
If it can be reproduced, please reopen this bug and change the Version
field above to the httpd version you have reconfirmed with.
>
> [...] a defect in httpd or a feature request [...]
>
> > Your help in identifying only current defects in the httpd server
software is greatly appreciated.
> > """

Edits noted, thanks!

>> Comments, suggestions and other feedback before we proceed to take a
broad scythe to the stale reports?
>
> We should also forbid bug report against 2.2.x.

This was annoying, since there was no mass-update feature, but is now done.
New bug creation is now restricted to 2.4.x or 2.4/2.5-HEAD.

Re: Stale BZ Bug Tracker reports

[Marion & Christophe JAILLET <ch...@wanadoo.fr>]

Le 31/10/2018 à 21:52, William A Rowe Jr a écrit :
> There are 715 reports tagged 2.0.0 through 2.3-HEAD of Status NEW or 
> NEEDINFO with no Resolution.
>
> For these bugs I believe we should simply close them with a message 
> that this is a mass-update, that the version is beyond EOL, and a 
> request for reporters/observers to retest and reopen with the 
> supported version number if they are still reproducible using a modern 
> 2.4.x version. But I can't determine the best Status/Resolution 
> code... suggestions?

+1
IMHO, the best status would be CLOSED/WONTFIX. Maybe a new Keyword such 
as TooOldAndInactive to ease finding such mass-update?
Or ask for a new status TOO_OLD (but I'm not sure it would really be 
that useful)

>
> There are 69 bugs of status REOPENED, and 20 of status ASSIGNED (?). 
> These should likely be reviewed by hand and either ACCEPTED against 
> 2.4-HEAD, tagged NEEDINFO with a request to re-review (after 
> mass-cleanup of NEEDINFO above), or closed as above with an invitation 
> to retest and reopen.
+1, after by-hand review, as proposed.

>
> There are 255 bugs of Status NEW from 2.4.1-2.4.17, releases which are 
> over three years old. For these, the best resolution is probably NEEDINFO.
-1.
Not sure NEEDINFO is fine for these ones. We should set NEEDINFO after 
by hand review, if we NEEDINFO. Or close it if invalid, or leave it as 
is if it looks right but no one has looked at it.
The reporter has done his job. He has reported what he thinks is enough. 
WE should provide an answer or ask for more details.

> And there are 38 2.4.x NEEDINFO bugs, most of which can likely be 
> closed for good as INVALID under a manual review.
+1 if older than, let say, 1 year?
The number is small, they could also be doubled check by hand. But is is 
likely, that it would end as INVALID because the analysis has already 
been done, and the reporter does not seem to be interested to answer.

>
> I'm thinking of generic comment which would read (2nd paragraph for 
> 2.0-2.3.x only);
>
> """
> Please help us to refine our list of open and current defects. This is 
> a mass update of older Bugzilla reports which reflect user error, 
> already resolved defects, and still-existing defects in httpd.
[...]. This is a mass update of old and inactive reports [...]
>
> As repeatedly announced, the Apache HTTP Server Project has 
> discontinued all development and patch review of the 2.2.x series of 
> releases. The final release 2.2.34 was published in July 2017, and no 
> further evaluation of bug reports or security risks will be considered 
> or published for 2.2.x releases.
>
> If your report represented a question or confusion about how to use an 
> httpd feature, an unexpected server behavior, problems building or 
> installing httpd, or working with an external component (a third party 
> module, browser etc.) we ask you to start by bringing your question to 
> the User Support and Discussion mailing list, see 
> [https://httpd.apache.org/lists.html#http-users] for details. Include 
> a link to this Bugzilla report for completeness with your question.
>
> If your report was clearly a defect in httpd, we ask that you retest 
> using a modern httpd release (2.4.33 or later) released in the past 
> year. If it can be reproduced, please reopen this bug and change the 
> Version field above to the httpd version you have reconfirmed with.
>
[...] a defect in httpd or a feature request [...]

> Your help in identifying only current defects in the httpd server 
> software is greatly appreciated.
> """
>
> Comments, suggestions and other feedback before we proceed to take a 
> broad scythe to the stale reports?
>

We should also forbid bug report against 2.2.x.

CJ