On Thu, May 31, 2012 at 11:41:27AM -0500, Les Mikesell wrote: > On Thu, May 31, 2012 at 11:26 AM, Stefan Sperling <s...@elego.de> wrote: > >> > > >> > We don't fix these kinds of bugs in the 1.6 series anymore. > >> > The 1.6 series receives only security or data corruption fixes. > >> > >> Do you happen to know how the decision is made to update the > >> subversion rpm included in RHEL6.x? Projects that jump their version > >> numbers all the time and let old versions remain broken tend to > >> conflict badly with 'enterprise ' distributions that want stable APIs. > >> There have been rare exceptions to bumping application versions > >> within an RHEL major rev lifespan but mostly in desktop type apps. > >> The odds are very likely that any unfixed bugs in 1.6 are going to > >> continue to affect a lot of people on RHEL/CentOS for another decade. > > > > Why should we spend our time maintaining old code for RedHat's customers? > > I don't know what you have against RedHat's customers, but a much > larger base of CentOS and Scientific Linux users will get exactly the > same versions delivered in their update stream in the free rebuilds.
I didn't mean to pick on their customers (not sure why you're implying I did). I just meant to imply that there is some obligation on the side of a distributor who chooses to ship a version of software that is not maintained upstream to the extent some of their customers would like (apparently you care and maybe you use RHEL/CentOS or something similar). > It is more a question of whether you want users to get fixes for the > bugs you did ship. Of course we do! Why would we not want that? We ship bug fixes every couple of weeks. > If you are happy with a lot of users continuing > to have problems for the next decade, then fine. Just don't be > surprised when the issues keep getting reported. We ask users to report bugs against the latest releases, if possible. If they can't do so, somebody else might try to reproduce the problem with the latest code and fix it if it can be reproduced. Bugfixes are shipped in new releases. The latest stable release receives fixes for all kinds of bugs. The prior one receives critical fixes only. This is stated here: http://subversion.apache.org/docs/release-notes/#supported-versions This policy is more a result of the community's capabilities than anything else. The decision to not ship all fixes to 1.6 users is a compromise. We were shipping all kinds of bugfixes for 1.6 users between March 2009 and October 2011. That is a long time, and as a result the 1.6 line is now very stable. I would say that it is a good fit for enterprise-class long-term support systems for this reason. But now, time we spend to fix non-critical bugs in 1.6 is simply not worth the gain for most of our users. For us, it is now time to focus on 1.7 maintenance and 1.8 development (each of which takes up a huge share of our available developer time and resources). Note that 1.6.18 shipped some non-critical fixes among the critical ones. These happened to sit in the queue because someone cared about each of those fixes and spent time backporting them. So if there is man power to backport fixes and publish a new releases, it will be done. If you'd like to see that happen but nobody else will do it, please volunteer. This applies to anyone, including the RedHat/CentOS/Scientific/etc. teams.