Joachim Breitner's Homepage

Do what's best for your users. That's my advice. If the changes you want to make enhance the package in a way that everyone would appreciate it, then put it into the Debian package. If not, then don't.



As an example of a downstream-only patch, Debian is the home of the GNU/kFreeBSD port of Mono - it's only a small patch, but it's something upstream really didn't care about - but we did.

Don't use a Debian package as a means to fork while keeping the same name. I would suggest maintaining a fork independent from Debian, following whatever procedures you would if you did so, and then packaging that fork.

I’m not really considering full forks – just small patches that enhance the program in minor, non-critical ways. Usually by adding an option that is off by default – would that be different?

Not in my view. I don't believe that feature-adding patches belong in a package that isn't marked as being explicitly divergent from upstream (eg. mutt-patched).

If the patch is useful to you, chances are it will be useful to others as well, so please apply your patches.

My take: get upstream’s opinion (but do not feel obligated to follow it if it is wrong). If there is risk of breakage, patch experimental first.

Am not a DD, but I'd go for including that patch, with a README.Debian (noting the rationale for the patch, and maybe a link to why upstream refused it). If someone wants pure upstream, they can open a bugreport explaining why upstream's version rocks and/or just use pure upstream. A good idea is to discuss it on debian-devel-list first before doing any of these.

I maintain a fair amount of packages myself too (see Homepage link), and there are also some with unresponsive upstreams. When it comes to applying patches, especially such that users would like to have added, I see it as my job of package maintainer to decide wether it makes sense to keep it in Debian when Upstream doesn't respond or like it.



Actually, I have a pretty nice story about that. The beep package's Upstream author was unresponsive for me for a pretty long period of time. The package got up to Debian revision 24 over the last years (8 or such?) and piled up a fair amount of patches. Just recently I tried to contact him again - and finally got a response, including that he picked up all of my patches and did an instant new release with them.



Long story cut short: You'll never know wether non-responsive upstreams might come back at some point and be thankful for your job. It might even happen that you start to become the upstream author for such packages. Having the package in a strict maintenance stage with a dead upstream often enough isn't helpful.

Well… look at the CVS package. It even

breaks checkouts’ hashes because the

date format inserted into $Id$ and si-

milar tags was broken (converted from

YYYY/MM/DD to ISO YYYY-MM-DD).



If they can do THAT, you can surely put

your own fixes/improvements into your

package – maybe upstream will pick them

up that way. Maybe other OS packagers

will pick them up from you (BTST).



So, by all means, go on, but please try

not to break too much (unlike cvs) ☺

I'm not a DD, but I've been a user for a long time.



I would say as package maintainer you have the responsibility to release the "best" package you can for the user.



You could ask yourself how would you respond to this if it was a wishlist bug report that included the patch?



As maintainer your opinion of what is "best" should probably be pretty heavily weighted. The fact that as a user you feel the need to have the patch applied is a pretty good indicator what you believe is best. The two packages doesn't really pass the "eat your own dog food" test. If it is a configurable feature or just sits there idly in a menu, I'd rather have the choice for more features.



Posting to debian-devel is a good way to get opinions, if you feel the change requires more thought, but in the end you still have to make the decision. This can be a political mess though, and from what I've seen is a great way to avoid making a decision.



As far as relationship to upstream. I would not interpret no response as a rejection. I'd interpret it as don't care, you can't have a negative effect on a relationship that isn't there. It's a two way street, you're not dirt. You are their connection to one of the largest package archives and user bases. If they actually do reject your patch, find out why. They should be the technical experts and probably have a good reason. Maybe they are planning on adding the feature in a different way in the near future. Maybe they would prefer it coded slightly differently.

Remember ideas are children of the mind. Developers can get unusual attachments to their code. Maybe they want you too sign over rights to the patch, or join their development circle. Maybe they are just jerks who think that only they can write code for their baby. Maybe they don't see the obviously existing use case, and just need it explained to them. Maybe they know there is a better way to accomplish the same thing.

I'm not a DD.



In my view the risk of adding features in the debian version of the package probably outweighs the feature. If it weren't a niche feature then upstream would have accepted it. Or maybe it just goes against upstream's vision for the software.



My advice is to take on the responsibility of upstream by becoming upstream. Upstream developers almost always run the latest and greatest version of the software, instead of the debian packaged version.



So collect your patches, improve the software, and distribute the fork when you think you have something sufficiently different. If you develop a vision for the software, you might even find yourself rejecting patches that other people send you.