<<< Date Index >>>     <<< Thread Index >>>

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