handling of change requests
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.
Sorry for the long mail.
Cheers
Antonio Radici