Re: handling of change requests
On Friday, 12 June 2009 at 01:18, Antonio Radici wrote:
> Hi there,
> I'm the co-maintainer of the mutt package in Debian and we are costantly
> working on incorporating
> your changes upstream into the Debian package and, the other way roud, in
> notifying new bugs to you
> and so on.
>
> Unfortunately our bug queue is really big and we would like to reduce it, a
> big chunk of it (more
> than 50%) are wishlist bugs, which on your side are usually classified as
> 'change request'; we even
> have wishlist bugs opened years ago.
>
> I know that bugs have priority over CR's but it would be great if you can say
> yes/no to some change
> requests, for example if you don't have any intention to incorporate a change
> request in the next
> releases (or for the next milestone) you could just close the CR rather than
> leave it open, so we
> will close the bug on our side. Obviously we would do our best to make the
> users happy but we also
> have to consider that our resources are limited :-)
>
> I have a list of 'wishlist' bugs which were all forwarded to you, what do you
> think if I pass this
> to you for a review and you tell us if the CR will be implemented in the next
> releases or if there
> is no intention to implement the CR? (because for example it's too
> complicated or you think it's not
> needed).
>
> I see that you are very collaborative on the bugs and it helped a lot in
> improving the Debian
> version of mutt, I hope we can find a solution for this problem as well.
I can tell you that hardly anything in the wishlist category will be
in the next release, because we're really trying to get 1.6 out the
door soon. 1.5.20 should be out this weekend, and I expect 1.5.21 to
be the first release candidate for 1.6 (possibly that'll be 1.5.22, if
I monkey with new mail handling much in 1.5.21).
Having said that, I imagine that a good number of enhancement requests
will be implemented eventually, and I like having them in the BTS for
when we plan post-1.6 work. I'm not really clear on why they should be
closed if they aren't going to be in the next release.