2010/7/5 David Cole <david.c...@kitware.com>:
> We don't really have a well-defined procedure that everybody follows w.r.t.
> resolving/closing bugs in the bug database.
> I typically just add a note when I push a change to 'next', saying that it
> is in next, and then go back to resolve the bug when it is merged to master.
>
> For example, see this one:
> http://public.kitware.com/Bug/view.php?id=10258
> It is probably a good idea (although I didn't do it in the above example) to
> mention the git commit hash in your bug tracker note when claiming that
> something is fixed. That way, somebody investigating later can look at that
> commit and see whether it made it into master, or a given CMake release...
> Personally, I don't like the idea of the bug fixer "closing" the bug.
> Marking it as "resolved" is entirely appropriate for the fixer of a bug...
> but it should be verified as fixed by the person who reported it, who should
> then mark the bug as closed.
I totally agree...
but unless I'm wrong it was the way to do it before git
at least as far as I remember Bill asked me to
"Close the bug when you commit the fix to CVS".
May be it was a simple way to prepare merge from HEAD to
release branch at that time.
> You start to get into conflict of interest territory when the person fixing
> the bug also has responsibility for declaring it "case closed." And I
> realize that with an open source project, and shared community effort,
> "responsibility" is a vague notion anyhow.
No problem with that I would rather wait at least for the bug reporter
to say "yes" the fix is good for me. An even better way would be to
add a TEST for each fix (failing before the fix and pass after the fix)
that way the next Dashboard round would validate the fix.
I'm afraid (speaking for me) I won't have time to add an extra test for
each fix.
> But it would be good to develop
> some guidelines for the bug tracker that we all as a community agree to
> follow....
> Maybe some more discussion here is warranted before we decide exactly what
> to put on the wiki.
> Does this answer your question at all...? :-)
Yes it does.
I'll re-open the prematurely closed bug and propose the following "process":
1) A bug is reported (by a "Reporter")
2) The bug is assigned (to the "Assignee") which either
either integrate a patch from a "Fixer"
and/or produce a fix "Assignee==Fixer"
3) The Fixer test the bug
4) The Assignee merge the fix locally test it and merge to next
It signals "Fixer" and "Reporter" that the fix is in next
(ideally the tracker should send a follow-up mail)
5) The "Reporter" and the "Fixer" confirm
with the note on the tracker that the fix is OK from git next
and/or the next release
6) The Assignee close the bug telling the CMake version including this fix
(i.e. he should wait the next CMake release to close the bug)
This should work, including the fact that a bug reporter may not have the
full right to change bug status (The Assignee may be the only one to be
able to do it)
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
