[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge bug -- svn:keywords and conflict resolution

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 31 May 2012 19:23:57 +0200

On Thu, May 31, 2012 at 11:41:27AM -0500, Les Mikesell wrote:
> On Thu, May 31, 2012 at 11:26 AM, Stefan Sperling <stsp_at_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.
Received on 2012-05-31 19:24:35 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.