On Thu, Dec 9, 2010 at 7:19 PM, Eric Noulard eric.noul...@gmail.com wrote:
2010/12/9 David Cole david.c...@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
___
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
