I'm trying to review ticket #10899, which is about a small bug in the
test client. The reporter also provided a simple patch and a regression test.
There's also a 2 years old feature request ticket that is about the same
area, and implementing the feature would also fix the bug. So Jacob has
closed the bug ticket as duplicate. The reporter has reopened the bug
because a bug ticket cannot be a duplicate of a feature ticket.
Now--how do we want to deal with this? In the user's view, there's a
bug, and it should be fixed and not put into the feature request
queue. In the developer's view, it looks like duplicate work.
My proposal is:
If the bug is really bad or the fix looks simple, fix the bug. Else,
close it as duplicate, but keep the tickets consistent for the users and
promote the feature request to a bug ticket.
Is this OK for you?
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Ticket #15740 is the right one ...
That's more or less how I look at things, with one additional caveat:
if a bug fix would be truly redundant compared to adding a new
feature, and if the new feature's reasonable in scope, I just don't
see the point in half-fixing something. That's what's at play in this
situation, for me: the small fix, while easy enough, is completely
superseded by the new feature, and in fact would basically have to be
backed out to get the feature in. And the feature itself is easy
enough, close to done, and all in a all a good idea.
I'll let others weight in here if they want, but my opinion here is
that we should focus attention on the bigger issue and get that fixed.
Killing more birds with one stone seems a better use of development
Thanks for the clarification, Jacob.