Below is a question regarding unassigned issues .

Here is a scenario

1. "A" opens an issue and it is unassigned
2. "B" starts working on it (issue still unassigned)
3. "B" commits the change and fixes the issue. Now "B" wants to close
the issue, does "B" have to assign the issue to himself first before
closing it ? If not, then what is the value behind assigning an issue
to "B" and then closing it (I think I have seen this happen in past
commits)

On 9/13/07, David Blevins <[EMAIL PROTECTED]> wrote:
>
> On Sep 13, 2007, at 4:52 PM, Karan Malhi wrote:
>
> > So lets say I am working on an issue, I checkin the code. Now I want
> > to close the issue, do I always resolve first and then close, or do I
> > simply close.
> >
> > In what case would we need resolve?
>
> I always just close stuff.  I find a bug, i fix it, i close it.
>
> The only compelling use I can think of for resolve is say you don't
> have access to commit the code but you want a way to say your patch
> is done and ready to go, "ball's in your court Mr. Committer".  Mr.
> Committer could check it in, verify it and close it.
>
> I guess maybe it's nice too for when someone else reported an issue
> and you're not sure if you actually addressed it in your fix.  You
> could maybe mark it as resolved and say "close it if this fixes your
> issue".  But that kind of interaction is rare.
>
> Maybe someone else has better ideas for possible "Resolved" uses.
>
> -David
>
>
>
>


-- 
Karan Singh Malhi

Reply via email to