On 12/13/2010 07:36 PM, Paul Gortmaker wrote:
>> the
>> same thing for 34-lt (i.e. you generating a 34 specific, pre-tested
>> patchset
>> instead of me doing the backports from other stable trees?)
>
> Wait, there's a 34-lt too?
There is also a 32-lt.
Luckily no 33-lt.
>
> I'd like to have all stable kvms pass some minimum acceptance test, but
> that's quiet a lot of trees to maintain. Why do we have to have both 34-lt
> and 35-lt?
Well, ideally we'd all be aligned on one release, but that requires that it be
chosen somewhat in advance and communicated well, so that people have
time to align to it. Without getting into details, different people had already
based projects and products off of 34, many months ago, at a point where
35 was not yet even being considered for extended maintenance.
Something's got to give. Either you burden the subsystem maintainers
with maintaining lots of longterm kernels, or you cherry pick the
patches yourself, and risk regressions in a stable series. I don't
think this is viable.
Or you can go with Greg's shorter justification. It is harder to
argue against. :)
I think Greg's confusing cause and effect.
--
error compiling committee.c: too many arguments to function
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
