[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Policy on stale bugs (was Re: Closing NEEDSINFO bugs after 30 days)
From:       Andrew Crouthamel <andrew () crouthamel ! us>
Date:       2018-11-16 13:12:38
Message-ID: YoFrold3Cu_09Bsv_nxhTP7zT7t3AtgW9MNdDLr2X-x0znN1k-4exd8G4uSDP0XTapob93yrwaYV78ca-ZfM-QGO3azCowa_U1mpkGTDMbg= () crouthamel ! us
[Download RAW message or body]

[Attachment #2 (text/plain)]

The changes you see were due to me. The Status change was a convenience to me for \
follow up, but as noted, has caused alarm. My apologies for that. I am already in \
process of sending updates and resetting the status, but am doing so in blocks to not \
spam anyone. Give it a few days and all will be well.

In regards to Haralds script, it is fully functional now and appears to work very \
well.

-------- Original Message --------
On Nov 16, 2018, 4:37 AM, Luigi Toscano wrote:

> Andrew Crouthamel ha scritto:
> > I've been spending a lot of time browsing, searching, and filtering our bugs
> > in Bugzilla. One of the areas I've found that could use improvement, are the
> > NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting
> > additional information or backtraces, never to be updated again. We have
> > NEEDSINFO bugs dating back to 2009.
> 
> Hi,
> the (semi)automated process which pings and then closes NEEDINFO bugs was
> implemented, but I've noticed another policy which was never discussed (as far
> as I know) here: bugs opened for a while
> 
> I disagree with this policy, and I'm not alone (at least another maintainer
> asked for his product to be excluded):
> - not all projects distinguished between CONFIRMED and UNCONFIRMED (now
> REPORTED), so it's possible that a perfectly valid bug or request (especially
> requests) seems stale. You may say that it's easy to flip the status again.
> I'd say that it's a unneeded step.
> - at most the script could add a new comment asking for updates, but not
> immediately change the status out of the blue.
> - as mentioned, it was not discussed.
> 
> Please disable it for now, or just enable it for projects who explicitly wants
> it for now.
> 
> --
> Luigi


[Attachment #3 (text/html)]

The changes you see were due to me. The Status change was a convenience to me for \
follow up, but as noted, has caused alarm. My apologies for that. I am already in \
process of sending updates and resetting the status, but am doing so in blocks to not \
spam anyone. Give it a few days and all will be well. <br><br>In regards to Haralds \
script, it is fully functional now and appears to work very well. \
<br><br><br><br><br>-------- Original Message --------<br>On Nov 16, 2018, 4:37 AM, \
Luigi Toscano < luigi.toscano@tiscali.it> wrote:<blockquote \
class="protonmail_quote"><br><p dir="ltr">Andrew Crouthamel ha scritto:<br> &gt; I've \
been spending a lot of time browsing, searching, and filtering our bugs<br> &gt; in \
Bugzilla. One of the areas I've found that could use improvement, are the<br> &gt; \
NEEDSINFO bugs. Often, bugs are placed into this status, either awaiting<br> &gt; \
additional information or backtraces, never to be updated again. We have<br> &gt; \
NEEDSINFO bugs dating back to 2009.</p> <p dir="ltr">Hi,<br>
the (semi)automated process which pings and then closes NEEDINFO bugs was<br>
implemented, but I've noticed another policy which was never discussed (as far<br>
as I know) here: bugs opened for a while</p>
<p dir="ltr">I disagree with this policy, and I'm not alone (at least another \
maintainer<br> asked for his product to be excluded):<br>
- not all projects distinguished between CONFIRMED and UNCONFIRMED (now<br>
REPORTED), so it's possible that a perfectly valid bug or request (especially<br>
requests) seems stale. You may say that it's easy to flip the status again.<br>
I'd say that it's a unneeded step.<br>
- at most the script could add a new comment asking for updates, but not<br>
immediately change the status out of the blue.<br>
- as mentioned, it was not discussed.</p>
<p dir="ltr">Please disable it for now, or just enable it for projects who explicitly \
wants<br> it for now.</p>
<p dir="ltr">--<br>
Luigi<br><br></p>
</div>



[prev in list] [next in list] [prev in thread] [next in thread]