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/ _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel