[Insight-developers] Mantis policy etc

Luis Ibanez luis.ibanez at kitware.com
Sat Jun 12 11:24:04 EDT 2010 

Hi Ivan,

First of all,
Thanks for signing up for the Adopt-A-Bug program,
It is great to have you in the developers team.

Thanks for asking about the MANTIS practices,
please find some comments below.

-----------------------------------------------------------------------
On Thu, Jun 10, 2010 at 8:27 AM, Ivan Macia <imacia at vicomtech.org> wrote:

> Dear all,
>
> I was trying to fix my first bug (just signed in as a bug adopter :S) and I
> have a few general questions.
>
> The first one seems quite obvious but just in case. I am working with the
> latest CVS version, I guess we should always stay updated when fixing
> something else, assuming that the CVS is not broken, isn't it?
>
> ------------------------------------------------------------------------

Yes, we should stick to the CVS HEAD version.

On the release branches we only commit bug fixes
when they are critical, and there is only one person
with write access to those branches.

So, yes, please start by doing a CVS update before
you tackle any existing bug.

The CVS branch is never broken for more than a
few hours. (That's the time it takes us to track the
developer responsible and hit her/his head with
a solid object).     :-)


 ----------------------------------------------------------------

> I tried to assign a bug to myself (
> http://public.kitware.com/Bug/view.php?id=7594) but then I realized that I
> have only Reporter access level (I had the account created previously) and I
> guess we need Developer access level. Who should we ask permission for this?
> After careful testing with latest CVS and the provided example I was unable
> to reproduce this bug so I wanted to mark it as Resolved with Unable to
> Reproduce.
>
> ------------------------------------------------------------------------

This is because as you get your initial account you
only have reporter level.  I have now promoted you
to be a developer. Please give it a try again and
let me know if you still see any problem. You should
now be able to assign bugs to yourself (and to others).

--

Yes, if you are unable to reproduce the bug,
add a note  describing what you did, and mark it
as resolved.  As soon as you add the note, MANTIS
will send email to the reporter of the bug, and some
dialog should occur after that.  Maybe some valuable
piece of information was missing from the initial report,
or, you may well be dealing with a platform-dependent
bug....


--------------------------------

I am quite used to Mantis since we use it in our own projects, it its easy
> and intuitive. But some questions about Mantis in ITK, that I could not
> deduct from here (
> http://www.itk.org/Wiki/ITK_Procedure_for_Contributing_Bug_Fixes) are:
>
> - Is there any kind of policy about Mantis regarding the states of the
> issues or other things? For example, resolved issues I guess are fixed with
> the Resolved state (green), but what is the policy to switch to the Closed
> state? Are other less common states such as Feedback, Acknowledged and
> Confirmed used? In our lab we sometimes use Feedback (to request someone
> else more info) and Confirmed (to let the others know that it is not fixed
> but indeed is a bug) but we barely use Acknowledged.
>


We only switch to Closed + Fixed when the bug
reporter has confirmed that the bug is fixed (or
when the fix is so obvious that we don't need
confirmation).

"Feedback" is used when you (as bug fixer) realize
that an important piece of information is missing
from the bug report, and that you really need it
before starting to attack the bug. By marking the
bug as "Feedback" state and adding a note that
describes what information is missing, MANTIS
sends email to the bug reporter, and some time
later you should receive such extra information.

"Acknowledged"  means that you (the bug fixer)
know about the bug, and endorse the fact that it
is an existing problem.

"Confirmed" means that you (the bug fixer) were
able to replicate the bug.  This is usually a short
lived state, since hopefully, right away you are
going to look into potential fixes.   However,
please switch the bug to this state as soon as
you manage to replicate it.

[ I must admit that the distinction between
"Acknowledged" and "confirmed" is quite
gray...   maybe we should consider getting
rid of one of these states...]


------------------------------------------------------------------------

> - Is there any policy for assigning bugs or one just assigns the bug to
> itself depending on availability and expertise? In the first case who assign
> bugs and following which criteria? Or this is just for the core developers?
>
------------------------------------------------------------------------

At this point we are assigning bugs based on

a) A volunteer come forward and offers to help
    with fixing the bug.

and

b) The bug is clearly the result of a commit
    by one known developer, and therefore we
    assign the bug to that developer.


We used to have sessions of bug triage,
during which we assigned bugs to specifics
developers. We may resume this practice
during the development of ITKv4.


-------------------------------------------------------------------

> - What kind of information is mandatory? You already mention a WebCVS link
> to the commit when fixed.
>
> -------------------------------------------------------------------

The rule of thumb is:

Think of all the information that someone else
will need in order to deal effectively with this
bug, and be generous.

The point is that, when you are reporting the
bug, a lot of information is fresh in your mind,
and it will take several hours (maybe days) to
another developer to rediscover such information
if you don't share it as part of the bug report.

 ------------------------------------------------------------------------

> I know some things may seem obvious, I just want to know how to do things
> correctly without messing anything up :)
>
> ------------------------------------------------------------------------

We appreciate a lot that you are making
an effort to follow the practices of the community.


------------------------------------------------------------------------

> Thanks for your help
>
> Iván
>
>
>
>
>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20100612/e388b346/attachment.htm>

More information about the Insight-developers mailing list