Let me elaborate a bit why I don't do that: backporting all patches to the many (unsupported) versions of rsyslog we have is a very time-consuming task (even though it may be rather simple, as probably in this case). So the more I backport, the less new stuff I get done. I went through this last year and it resulted in a *very considerable* productivity reduction. I am glad I got rid of all that in the later half of 2012, and so I am hesitant to go back to that business again. Just for the records: we of course support *all* versions for support contract customers, but then it is of benefit to the project because it provides funding. Whereas it probably is even counter-productive in other cases: the more I backport, the less the interest in moving to new releases and so we stay with all that outdated stuff. Also, if it is very simple for package maintainers to stick to outdated stuff, they probably have few incentive to move to new ones (to the disadvantage of many users). So if they want to stick with the old stuff, let them *they* pay the price for that and not *the project* ;) There are exceptions of course, and the maintainers I work with know that very well ;)
Friday, December 14, 2012
On backporting patches
Every now and then, I get (polite) requests to backport some patch to older versions. First of all, let me say that I usually patch things in the oldest affected (and supported) version and then "upport" these to the newer releases. So in those cases, everything is already covered (it pays to look into the ChangeLog file in the project root directory). However, "supported" is a keyword. I usually do not backport patches to older, unsupported versions (except if there exists good reasons and the version is in widespread use).