linux-kernel - Re: [PATCH] orangefs: Axe some dead code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161128110713.GE28558@mwanda>
Date:   Mon, 28 Nov 2016 14:07:13 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Mike Marshall <hubcap@...ibond.com>
Cc:     Martin Brandenburg <martin@...ibond.com>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] orangefs: Axe some dead code

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