On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote:
On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman <bill.hoff...@kitware.com> wrote:
I have a third idea that we have not yet tried:
What do people think of automatically closing bugs if they are not modified
for some period of time (say 6 months). They can always be reopened if the
closed. By closing them, it will notify those that have expressed interest
in the bug. We could send the closed bugs to the cmake-developer list just
like the new ones. That way all developers will know that they are being
closed.
It's a bad idea, IMHO.
If a user took the time to file a bug and CMake developers do nothing
in 6 months, closing it is the wrong thing to do.
The message you are sending to the bugreporter is "I didn't care about
the bug you reported in 6 months, and now I will care even less". For
an example, see what I said yesterday about bug 8707: two years later,
a patch provided, still no action on Kitware's side.
I completely agree. Time-based automatic bug closing is a bad idea.
On the other hand, on KDE, when we moved to KDE4, we closed almost all
KDE3-related bugs without checking if they had been fixed. It did not
made too much sense to keep bug reports around unless they were
feature requests.
That sounds like you would support version-based (as opposed to
time-based) bug report closing.
To be specific what would you think of a new bugtracker policy to
close all bugs automatically that were submitted for old versions of
CMake with the message, "please reopen this bug if it still applies to
CMake-2.<N>"? Such a policy seems reasonable to me (especially if the
old version cutoff is sufficiently in the past, e.g., close all bugs
relevant to CMake-2.<N-2> when the 2.<N> series starts) and avoids the
implicit bad message to bug reporters of a time-based policy that we
both dislike so much.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
