Bugzilla open tasks by year

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

Hi everybody,

since we have around 1700 bugs opened in bugzilla (that is impressive for a
project that have been triaging and supporting users for so many years, so
kudos!) I tried to break down them for last modified/update year:

  16 2004
  24 2005
  34 2006
  60 2007
  80 2018
  82 2008
 109 2010
 110 2009
 122 2011  (subtotal up to here: 637)
 160 2015
 161 2016
 174 2014
 175 2012
 184 2013
 232 2017

As hackathon project it could be good to review some of those
older-than-2011 tasks and see which ones are good to keep and which ones
can be closed for no-activity/stale/not-valid-anymore/etc..

Luca

Re: Bugzilla open tasks by year

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

On Fri, Mar 30, 2018 at 11:50 AM, Luca Toscano <to...@gmail.com> wrote:
>
> 2018-03-26 11:35 GMT+02:00 Nick Kew <ni...@apache.org>:
>>
>> > As hackathon project it could be good to review some of those
>> > older-than-2011 tasks and see which ones are good to keep and which ones can
>> > be closed for no-activity/stale/not-valid-anymore/etc..
>>
>> Good idea.  Deal collectively with some of those judgement-calls that
>> stump a solo bug-blitz.
>>
>> What we perhaps also need is a review of our bugzilla categories and
>> workflow.
>> For example, sometimes a PR is submitted with a proposed patch likely to
>> be useful
>> for some but not appropriate for inclusion in standard HTTPD.  I’ve always
>> left those
>> open, which leaves them as not-bugs in the bugzilla count.  Maybe we could
>> deal
>> with those with a new RESOLVED category (RESOLVED-PATCH?) and update the
>> docs to invite users to search patch-bugs?
>>
>
> We could also use http://www.apache.org/dist/httpd/patches/ to collect
> those, and then link them in bugzilla closing the task (one should be able
> to find them if searching etc...). Those patches would get stale very soon
> though, so not sure what's best; ideally a patch is either accepted or not,
> and the correspondent task eventually closed to avoid polluting whoever is
> triaging/resolving the open ones :)

Because these are not "published" by httpd (due to not being appropriate),
the /dist/httpd/ tree is very problematic.

If a patches tree of "interesting things under consideration" is needed, that
would fit better under the httpd.a.o/dev/ tree.

Re: Bugzilla open tasks by year

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

2018-03-26 11:35 GMT+02:00 Nick Kew <ni...@apache.org>:

>
> > As hackathon project it could be good to review some of those
> older-than-2011 tasks and see which ones are good to keep and which ones
> can be closed for no-activity/stale/not-valid-anymore/etc..
>
> Good idea.  Deal collectively with some of those judgement-calls that
> stump a solo bug-blitz.
>
> What we perhaps also need is a review of our bugzilla categories and
> workflow.
> For example, sometimes a PR is submitted with a proposed patch likely to
> be useful
> for some but not appropriate for inclusion in standard HTTPD.  I’ve always
> left those
> open, which leaves them as not-bugs in the bugzilla count.  Maybe we could
> deal
> with those with a new RESOLVED category (RESOLVED-PATCH?) and update the
> docs to invite users to search patch-bugs?
>
>
We could also use http://www.apache.org/dist/httpd/patches/ to collect
those, and then link them in bugzilla closing the task (one should be able
to find them if searching etc...). Those patches would get stale very soon
though, so not sure what's best; ideally a patch is either accepted or not,
and the correspondent task eventually closed to avoid polluting whoever is
triaging/resolving the open ones :)

Luca

Re: Bugzilla open tasks by year

[Nick Kew <ni...@apache.org>]

> As hackathon project it could be good to review some of those older-than-2011 tasks and see which ones are good to keep and which ones can be closed for no-activity/stale/not-valid-anymore/etc..

Good idea.  Deal collectively with some of those judgement-calls that stump a solo bug-blitz.

What we perhaps also need is a review of our bugzilla categories and workflow.
For example, sometimes a PR is submitted with a proposed patch likely to be useful
for some but not appropriate for inclusion in standard HTTPD.  I’ve always left those
open, which leaves them as not-bugs in the bugzilla count.  Maybe we could deal
with those with a new RESOLVED category (RESOLVED-PATCH?) and update the
docs to invite users to search patch-bugs?

— 
Nick Kew