On 07/11/2013 10:25:51 PM, Li Zefan wrote:
On 2013/7/12 8:50, Theodore Ts'o wrote:
> On Thu, Jul 11, 2013 at 03:01:17PM -0700, Greg Kroah-Hartman wrote:
>> <rant>
>> I'm sitting on top of over 170 more patches that have been
marked for
>> the stable releases right now that are not included in this set
of
>> releases. The fact that there are this many patches for stable
stuff
>> that are waiting to be merged through the main -rc1 merge window
cycle
>> is worrying to me.
>>
>> Why are subsystem maintainers holding on to fixes that are
>> _supposedly_ affecting all users? I mean, 21 powerpc core
changes
>> that I don't see until a -rc1 merge? It's as if developers don't
>> expect people to use a .0 release and are relying on me to get
the
>> fixes they have burried in their trees out to users. That's not
that
>> nice. 6 "core" iscsi-target fixes? That's the sign of either a
>> broken subsystem maintainer, or a lack of understanding what the
>> normal -rc kernel releases are supposed to be for.
>
> At least at one point in the past, the rule that Linus had laid down
> after discussing things at Kernel Summits was after -rc2, or maybe
> -rc3 at the latest, the ***only*** fixes that should be sent to
Linus
> would be for regression fixes or for really serious data integrity
> issues. The concern was that people were pushing bug fixes in -rc5
or
> -rc6 that were in some cases causing regressions.
>
> (As I recall, Linus laid down the law regarding this policy in his
own
> inimitable and colorful style; which today would result in all sorts
> of tsk, tsking on Hacker News regarding his language. :-)
>
> In any case, I've been very conservative in _not_ pushing bug fixes
to
> Linus after -rc3 (unless they are fixing a regression or the bug fix
> is super-serious); I'd much rather have them cook in the ext4 tree
> where they can get a lot more testing (a full regression test run
for
> ext4 takes over 24 hours), and for people trying out linux-next.
>
> Maybe the pendulum has swung too far in the direction of holding
back
> changes and trying to avoid the risk of introducing regressions;
> perhaps this would be a good topic to discuss at the Kernel Summit.
>
Looks like each maintainer may have his rule which may differ from the
rule laid down by Linus.
I have 2 network patches which went into 3.10-rc6, though these two
bugs
are not regressions but has been there even before the git history.
On the other hand, 2 of my cgroup bug fixes were queued for 3.11 with
stable tag added.
And what about Documentation fixes and updates? Should those patches
also follow Linus' rule? I guess people have different opinions.
Documentation fixes that go in as part of a patch series follow the
rules of that series. Ye olde Documentation maintainer (me) is mostly
here for catching stuff that would otherwise fall between the cracks,
and to reorganize Documentation after the fact into less of a "giant
unorganized heap". (Working on that last bit...)
Documentation fixes aren't going to introduce runtime regressions or
break "git bisect", and if the noise they generate is limited to the
Documentation directory the maintainer tools can filter it out.
Rob
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html