Re: [PATCH] orangefs: Axe some dead code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Perhaps we should modify Greg KH's "be-all, end-all document"
on "HOWTO do Linux kernel development" then... you've
contributed a boatload of work to the kernel since as far
back as 2006, but I'm a newbie who just works in an
isolated subsystem... people like me need a reliable
and authoritative cheat-sheet to go by...

I think you believe I should ask for this to be pulled only
during a merge window.  Since this patch doesn't involve new
functionality, or even any functionality, it seems like pull-fodder
anytime after it is vetted, based on Greg's HOWTO...

My original intent on posting to this thread was to let
christophe.jaillet@xxxxxxxxxx know that I saw and
appreciate his review and the good patch he supplied.

-Mike

On Mon, Nov 28, 2016 at 6:07 AM, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
> On Sat, Nov 26, 2016 at 08:51:57AM -0500, Mike Marshall wrote:
>> I think I understand what you're saying, except for this part:
>>
>> > would have been secretly disapointed at your lack of
>> > courage in my heart but it would have been normal and fine.
>>
> What I'm saying is that for some people the cut off for 4.10 happens
> the week or two before 4.9 is released.  I'm sending bugfixes and they
> still push them out to 4.11.  It annoys me, secretly.
>
>
>> I'm pretty sure that Linus won't accept a pull request from me
>> at the wrong time and that I won't send one at the wrong time
>> on purpose.
>
> Linus pulls lots of things that make him unhappy.  If he didn't
> compromise he would go mad.
>
>>
>> I've been laboring under the belief that the rc period is when
>> we "push only patches that do not include new functionalities",
>> and I would have thought that stripping out a few lines of dead
>> code would be appropriate then.
>>
>
> No.  -rc is for fixing regressions only.  If it's a fix for a bug that
> has *always* been there, then think carefully about how important it is
> because that's not a regression fix.  If it's a bug fix, but it's not a
> regression fix and it's not critical then wait.  Non-bugfixes should
> only go in during the merge window.
>
> regards,
> dan carpenter
>
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux