[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: Jaroslaw Staniek <staniek () kde ! org>
Date: 2018-11-16 10:15:04
Message-ID: CAOj7QQ1_RoVaomp3LcN+t3BRsHKG0K1jMht-rURvc_kAYNfVPg () mail ! gmail ! com
[Download RAW message or body]
On Fri, 16 Nov 2018 at 10:37, Luigi Toscano <luigi.toscano@tiscali.it>
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
>
Hi
As a heavy user of NEEDINFO I am also not enthusiastic and asked by email
for exclusion but no reaction so far.
Bug reports that I work with can easily be 6 years old and this means
nothing in the development speed that I face. In a commercial environment
maybe it's different - so old reports are really invalid, but here now I
only get more work - I need to resort to notification emails one by one, it
will take months.
Also e.g. if a bug has 10% of missing "NEEDSINFO" and dozen of comments
with valid discussion and input, how can it be abandoned automatically
based on time since the original report?
I am not sure if we can assume it is of any help that valid bugs are set as
resolved by non-project persons (who have never had a contact with a
maintainer), without proper project knowledge.
At least the bugs are not CLOSED so it's possible to query them. But how
useful is to spend time on it?
Please at least do not close them. We have to deal with the consequences
with our users. Possibly facing decline of bug reports because they see
they are resolved without proper action.
I also think something else was not considered, what applies at least to
projects I maintain: people do use old software and do not upgrade
especially on Linux e.g. due to the misunderstood thing called LTS. Hence
they face with problems that are discussed in these old bug reports. The
fact that old software is unmaintained does not mean that the report,
convert into new reports or tasks for newer software versions, for the
docs, and so on. If we automatically set bugs as resolved I seen that as a
disservice for the project.
> 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
>
>
>
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - kde.org
KEXI:
: A visual database apps builder - kexi-project.org calligra.org/kexi
twitter.com/kexi_project facebook.com/kexi.project t.me/kexi_project
Qt Certified Specialist:
: linkedin.com/in/jstaniek <http://www.linkedin.com/in/jstaniek>
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><br><div \
class="gmail_quote"><div dir="ltr">On Fri, 16 Nov 2018 at 10:37, Luigi Toscano <<a \
href="mailto:luigi.toscano@tiscali.it" \
target="_blank">luigi.toscano@tiscali.it</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Andrew Crouthamel ha scritto:<br> > I've been spending \
a lot of time browsing, searching, and filtering our bugs <br> > in Bugzilla. One \
of the areas I've found that could use improvement, are the <br> > NEEDSINFO \
bugs. Often, bugs are placed into this status, either awaiting <br> > additional \
information or backtraces, never to be updated again. We have <br> > NEEDSINFO \
bugs dating back to 2009.<br> <br>
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<br></blockquote><div><br></div><div \
class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">Hi</div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">As a \
heavy user of <span \
style="font-family:Arial,Helvetica,sans-serif">NEEDINFO</span><span \
style="font-family:Arial,Helvetica,sans-serif"> </span>I am also not enthusiastic \
and asked by email for exclusion but no reaction so far. </div><div \
class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">Bug \
reports that I work with can easily be 6 years old and this means nothing in the \
development speed that I face. In a commercial environment maybe it's different - \
so old reports are really invalid, but here now I only get more work - I need to \
resort to notification emails one by one, it will take months.</div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">Also \
e.g. if a bug has 10% of missing "NEEDSINFO" and dozen of comments with \
valid discussion and input, how can it be abandoned automatically based on time since \
the original report?</div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">I am not sure if we can \
assume it is of any help that valid bugs are set as resolved by non-project persons \
(who have never had a contact with a maintainer), without proper project knowledge. \
</div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">At \
least the bugs are not CLOSED so it's possible to query them. But how useful is \
to spend time on it?</div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small">Please at least do not close \
them. We have to deal with the consequences with our users. Possibly facing decline \
of bug reports because they see they are resolved without proper \
action.<br></div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><div \
class="gmail_default" style="font-family:monospace,monospace;font-size:small">I also \
think something else was not considered, what applies at least to projects I \
maintain: people do use old software and do not upgrade especially on Linux e.g. due \
to the misunderstood thing called LTS. Hence they face with problems that are \
discussed in these old bug reports. The fact that old software is unmaintained does \
not mean that the report, convert into new reports or tasks for newer software \
versions, for the docs, and so on. If we automatically set bugs as resolved I seen \
that as a disservice for the project.</div><div class="gmail_default" \
style="font-family:monospace,monospace;font-size:small"><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> 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.<br>
<br>
Please disable it for now, or just enable it for projects who explicitly wants <br>
it for now.<br>
<br>
-- <br>
Luigi<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" \
class="m_-4783978162179324948gmail_signature" data-smartmail="gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>regards, \
Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, \
artists, writers, translators<br>: and facilitators committed to Free Software \
development - <a href="http://kde.org" target="_blank">kde.org</a><br>KEXI:<br>: A \
visual database apps builder - <a href="http://kexi-project.org/" \
target="_blank">kexi-project.org</a> <a href="http://calligra.org/kexi" \
target="_blank">calligra.org/kexi</a></div><div> <a \
href="https://twitter.com/kexi_project" target="_blank">twitter.com/kexi_project</a> \
<a href="https://facebook.com/kexi.project" \
target="_blank">facebook.com/kexi.project</a> <a href="https://t.me/kexi_project" \
target="_blank">t.me/kexi_project</a><br>Qt Certified Specialist:<br>: <a \
href="http://www.linkedin.com/in/jstaniek" \
target="_blank">linkedin.com/in/jstaniek</a></div></div></div></div></div></div></div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic