[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] fix qemu building with older make
On 29/07/14 17:20, George Dunlap wrote: > On 07/29/2014 05:13 PM, Jan Beulich wrote: >>>>> On 29.07.14 at 17:43, <Ian.Jackson@xxxxxxxxxxxxx> wrote: >>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"): >>>> On 29.07.14 at 15:57, <Ian.Jackson@xxxxxxxxxxxxx> wrote: >>>>> (b) have some kind of >>>>> time limit on how long we need to support make 3.80 ? >>>>> >>>>> 3.81 was released upstream over eight years ago in April 2006. >>>> >>>> I know, but I also know there's going to be a few more years where >>>> for my day-to-day work SLE10 (coming with make 3.80) is the lowest >>>> common denominator in order to be able to test backports there. >>>> And RHEL5, iirc released at about the same time, was also quite >>>> recently considered a platform desirable to continue to support. >>> >>> RHEL5 was released in March 2007, 11 months after make 3.81 was >>> released upstream. Furthermore it is seven years old. SLES10 was >>> released in June 2006, and is therefore eight years old. People refer >>> to Debian stable as `Debian stale' but frankly this is ridiculous. >>> >>> At the very least can we put some kind of bound on this ? >>> >>> How about we `compromise' on the following rule: we will feel >>> completely entitled to delete any build and tools compatibility code >>> for anything which was superseded upstream more than a decade ago. >> >> I'm personally not in favor of this, but if a reasonably large majority >> would want a rule like this, I'll have to try and live with it. My scope >> for deprecation would be more towards such relatively wide spread >> distros going completely out of service (i.e. in the case of SLES not >> just general support [which happened about a year ago], but also >> long-term/extended support [which I think is scheduled for like 12 >> or 13 years after general availability]). > > FWIW, one of the things that has made Docker possible is Linus' > quixotic commitment to binary compatibility for any user-space > program, whether in a distro or not. > > RHEL apparently has several lifecycle "phases" > (https://access.redhat.com/support/policy/updates/errata/); > "Production 2" for RHEL 5 just ended in January of this year; > "Production 3" won't end until 2017, and the "Extended Life Phase" > won't end until 2020. > > Staying compatible with major distros, particularly if it's something > small (if slightly ugly) like this, seems like a small price to pay. > > -George We should not aim to deliberately break things. I would suggest a slightly more lax approach; if the distro has a requisite version in a standard package repository then we could consider breaking compatibility with the older package version. e.g. a newer version of make available in something like EPEL for RHEL5. I have no knowledge of whether such things exist for SLES. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |