To keep this thread moving (additional feedback is welcomed and appreciated)...
On Thu, Nov 1, 2018 at 5:03 AM Marion & Christophe JAILLET < christophe.jail...@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.
