[darcs-users] clarifying bug tracker usage

Mark Stosberg mark at summersault.com
Fri Aug 15 16:27:55 UTC 2008


> On Thu, Aug 14, 2008 at 22:33:39 -0400, Mark Stosberg wrote:
> > I agree with this assessment of what they mean. I think we could do without the
> > "feature" priority, though.
> 
> I was going to say +1 for collapsing feature into wishlist, but what if
> we don't know what release we want this to be critical for, but we do
> know it's a pretty 'big' wishlist item?  How do we declare that, as it
> worth trying?

A project manager adds a "ReleaseLater" tag. It means that we know that we want
to release the wish/feature, we just don't know when. 

I'll see about merging "feature" into "wishlist"

> > >  * undecided: duplicate vs. resolved vs. deferred:
> > >    * I don't like using resolved for duplicates, because it makes it harder to search for a bug and determine if it has already been fixed or not
> > >    * But if we just use 'duplicate' we can't tell if it's a duplicate of a fixed bug or not
> > 
> > I would mark a bug a duplicate while the issue is still open (in some other
> > ticket) and then mark it as resolved when the other ticket is resolve, so that
> > the ticket requestors of the dupe ticket are notified that it is resolved. 
> 
> Yes.  This means gardening the duplicates.
> 
> Perhaps we just need a script that says 'if I am a duplicate, and my
> supereceder is resolved, then I am resolved', maybe with a message
> saying so and requesting that the original poster check for themselves.

That automation would be welcome. I'm not familiar with scripting/automating Roundup, but seems
like it could be done.

> > I use 'deferred' as a way of saying "lower priority" Usually this goes along with wishlist requests.
> 
> Fine

On further consideration, I suspect "deferred" could be eliminated, we as
already have several ways to say we aren't working something now or is
lower-priority: "wishlist", "needs-volunteer", and the lack of any "release"
tag implies deferment. Since I doubt we would object much to a volunteer
implementing a deferred feature sooner, the distinction may not be important. 
But I'll leave it alone for now, as we are making enough other changes at the moment.

> These may seem like silly details, but it's important to get them right
> so that using the bug tracker becomes obvious.  We want it so that
> anybody can pigeonhole a bug easily, thereby avoiding bugtracker-rot.

I thought they were somewhat silly to discuss when I thought of them myself
around the Darcs 2 release bug triage cycle. When I saw that all the same
questions were coming up for you too, it didn't seem silly anymore!

I think these tweaks will make the project smoother to manage.

    Mark




More information about the darcs-users mailing list