Re: [PATCH] fix qemu building with older make

[George Dunlap <george.dunlap@eu.citrix.com>]

On 07/29/2014 05:13 PM, Jan Beulich wrote:
>>>> On 29.07.14 at 17:43, <Ian.Jackson@eu.citrix.com> wrote:
>> Jan Beulich writes ("Re: [PATCH] fix qemu building with older make"):
>>> On 29.07.14 at 15:57, <Ian.Jackson@eu.citrix.com> 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