[CMake] CMake bug tracker discussion

[Alan W. Irwin]

On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote:

> On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman <bill.hoffman at 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
__________________________