On Thu, May 31, 2012 at 3:53 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, May 31, 2012 at 1:45 PM, Les Mikesell <lesmikesell_at_gmail.com>
> wrote:
> > On Thu, May 31, 2012 at 12:23 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> >> >
> >> 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.
> >
> > Yes, it doesn't seem that bad today. I'm just pointing out that there
> > will very likely be a large user base continuing to run some version
> > of 1.6.x for 5 to 10 years in the future.
>
> How is any of this relevant? Even if Subversion keeps a healthy
> stream of 1.6.x releases coming out the door regularly none of those
> will find their way into Red Hat's packaged version. Red Hat
> selectively chooses which bugfixes to include independent of
> Subversion's bugfix releases. If they could be convinced to include a
> specific bug fix in their package, I do not think it would matter
> whether Subversion itself had released that same fix in a 1.6.x
> release. If that issue ever arises, and it is preventing Red Hat from
> back porting a fix, than bring it up here and we can look into doing a
> release or whatever is needed to help the process along.
>
Umm, Mark? It's partly customer demand. The "don't fix it if it ain't
broken", and "if it breaks my existing setup, it's your fault" are big
issues. Red Hat *did* upgrade from 1.4 to 1.6 on RHEL 6, eventually, for a
stack of excellent reasons.
> I do not think it will ever happen though because generally Red Hat is
> only going to backport fixes that have been deemed critical to
> security.
>
Upgrading some machines in a network from 1.1.x (on RHEL 4) to 1.6.x or
1.7.x (as published by me at http://github.com/nkadel/, or from 1.4.x to
1.6.x as happened on RHEL 5, *BREAKS* things. If you have a working copy on
an NFS home directory, and some of your machines get the patch and some
don't, your working copies will stop working on the hosts without the
update.
This is *death* in a production environment, or in many dev environments
where people get very, very strange about update policies. It's partly why
I spent all that time getting 1.6.x and 1.7.x backported to RHEL 4, I
wanted to be able to use consistent toolkits across platforms.
Received on 2012-06-03 13:58:13 CEST