[CMake] [cmake-developers] CMake bug tracker discussion
David Cole
david.cole at kitware.com
Thu Dec 9 19:30:30 EST 2010
On Thu, Dec 9, 2010 at 7:19 PM, Eric Noulard <eric.noulard at gmail.com> wrote:
> 2010/12/9 David Cole <david.cole at kitware.com>:
>> Hello CMake users and devs,
>>
>> (And now for something completely different...)
>>
>> Controversial questions:
>>
>> - Should we eliminate the bug tracker entirely and just do all
>> discussion and patches on the mailing list? (Why have two sources of
>> information...?)
>>
>> - Or, alternatively, should we eliminate the bulk of mailing list
>> traffic, and insist on issues in the bug tracker being the main
>> conversational forum for the whole community?
>
> I would personally vote for keeping both.
>
> I'd like to keep ML bug related activities for:
> 1) Having preliminary discussion like
> Is this a bug or not?
> If it is a feature request is it worth a formal request ...?
>
> 2) Public poll directed to people who seldom browse the bug tracker.
>
> Then use the tracker:
>
> 1) When we are sure (with or without discussion) that the issue
> is a bug or a feature request.
>
> 2) Because one NEEDS to keep track of changes, bug fixes etc...
>
> So my opinion is that BOTH are mandatory, including the usage
> of the ML for bug handling but may be some "common usage rules may be
> advertised".
>
> Now I agree that may be the systematic handling of bugs filed into the tracker
> has to be improved but I think it already started.
>
> As external free-time contributor to CMake I was granted commit right when
> CMake was using CVS, it's even more easy now with git since
> I can autonomously commit patches to next branch
> (see CMake workflow http://www.cmake.org/Wiki/CMake/Git)
> which is regularly (once a week) merged to master by Kitware.
>
> I do get (I don't remember since when) a copy of each new bug entered in the
> tracker so that I can (autonomously) assign those bugs to myself if do think
> I can handle it.
>
We added that a couple months ago to raise awareness of new bugs being
entered to the mailing list community.
> If I cannot (not enough time or not my expertise zone) but I'm interested in the
> bug I do add myself to the monitor list and may add some personal
> comments to the bug report.
>
> So to comment to Pau remark:
>> Maybe you could start by having some people from outside of Kitware
>> (apart from Alex ;-) ) help with triaging bugs and commit patches and
>> not-too-complex features.
>
> I'll try to do that myself but I'm far away from Alex efficiency :-]
>
> May be helping the bug triage would be nice, may be some people
> may search the bug tracker for "unassigned" and "oldish" bugs
> and send some list of such bugs from time to time on the
> cmake-developer ML?
>
This is a great idea. Is there anybody out there on these mailing
lists that would like to contribute simply by organizing bugs and
communicating about them with the reporters and the developers
involved? It would be good to have extra eyes and hands poking around
in the oldish and unassigned...
> I know that some Kitware people do that (searching the Bug Tracker)
> from time to time but I do not know if it is systematic nor periodic :-)
>
As of our new release procedures since switching to git, we're doing
this at least once every patch release of CMake, which we hope to keep
going on a quarterly basis (4x a year) moving forward.
> May be opening a Wiki page with the list of CMake developers (Kitware
> and outsiders)
> with their domain of CMake expertise may help "triage volunteer" to contact them
> about the "unassigned" and "oldish" bug?
>
I don't think this is necessary. We can use the mailing list for this
function. And/or simply add notes in the bugs. Reporters, assignees
and interested monitors all get notified by email already as notes are
added to bugs.
>
> --
> Erk
> Membre de l'April - « promouvoir et défendre le logiciel libre » -
> http://www.april.org
>
Again, thanks for your input. This is one of the things that's really
nice about working with the CMake community. You are for the most
part, a bunch of thoughtful, deliberately spoken folk, whose opinion I
value very highly.
Thanks,
David Cole
More information about the CMake
mailing list