On Apr 12 Felipe Contreras wrote:
> But this is exactly the opposite; the patch that broke things is in
> the 'release branch' (3.3.1); it's not in upstream (3.3). Sure, it's
> also on a later upstream, which is also broken.
^^^^^
No, upstream /earlier/ than 3.3.1 contains the defect.
v3.4-rc1 is older than v3.3.1.
3.3 is not 3.3.y's upstream. 3.3 is the branch point from where 3.3.y
began.
torvalds/linux.git #HEAD is 3.3.y's upstream.
A git snapshot shortly before v3.4-rc1 was v3.3.1's upstream.
Furthermore, consider this: You as user of the 3.3.y series are using a
temporary, dead-end side branch. Its maintenance will stop at some point,
and you will be left looking for a different, maintained series to migrate
to. You will be most interested in that series /not/ containing any
regressions that you suffered already through the 3.3.y lifetime.
That other 3.3+n.y kernel to which you will be wanting to migrate to
should obviously be based on a branch point which does not lack any of the
fixes which your last 3.3.y already had.
I.e. you require that stable kernels are branched off of good branch
points. Mainline releases, i.e. releases of branch points, happen on a
time-based scheme (as opposed to a feature-based scheme). So a rule whose
purpose is to ensure that future stable branch points contain all fixes
that earlier stable branches had already must necessarily be a time-based
rule. This time-based rule is "fix mainline before stable".
The rule is there to protect you, as a user of the stable series, from
repeated regressions.
--
Stefan Richter
-=====-===-- -=-- -==-=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
