[CMake] CMake bug tracker discussion

[Eric Noulard]

2010/12/10 Bill Hoffman <bill.hoffman at kitware.com>:
> There are a few things we have already started to do that should help with
> the bug tracker issue.
>
> 1. We hare having 4 releases of CMake each year.   After each release we
> post to the list and ask people to "vote" for bugs they would like fixed in
> the next release.
>
> 2. We are now sending all new bugs to the cmake-developer list.  This way
> any CMake developer can start working on them or at least know about them
> when the are opened.

This was a very good idea.

I would suggest that each reporter get the follow-up of the bug he posted,
I think (but I have no way to verify that) that bug reporters do not
get automatic
e-mail follow-up for each comment posted to their bug unless they add themselves
as "monitor".

I'm using this default behavior for other opens source project bug
tracker and I usually
get fast answers (including "I have no time/mean to answer") on bug comments.

Knowing that, If a bug reporter does not react to a comment posted on his bug I
would usually tend to stop working on this bug because of the lack of
info and let the bug
close itself after a grace period.

> 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.

I would prefer having 2 messages:
    One after 6 monthes of inactivity (i.e. no new comments etc...)
       saying the bug will be automatically closed a month later
       unless the situation evolves
    A second one closing it if no activity is seen after the "grace period".

Those message should be sent to the monitor list AND the bug reporter.

The first message should be didactic, and may be explain that a bug
is more easily fixed with the involvement of the reporter:
    - test case
    - patch
etc....

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org