Il giorno gio 1 nov 2018 alle ore 22:35 William A Rowe Jr <[email protected]> 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 > <[email protected]> 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
