From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Date: Tue, 20 Aug 2013 22:24:56 +0000 Subject: Re: rfc: trivial patches and slow deaths? Message-Id: <20130820152456.c12dd8f543e2735b6952ae13@linux-foundation.org> List-Id: References: <1376944033.2016.13.camel@joe-AO722> <1376946644.2016.35.camel@joe-AO722> <1376947637.2016.39.camel@joe-AO722> <1377028944.2737.75@driftwood> <1377029650.2016.72.camel@joe-AO722> <1377035369.2737.85@driftwood> <1377036678.2016.88.camel@joe-AO722> In-Reply-To: <1377036678.2016.88.camel@joe-AO722> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Joe Perches Cc: Rob Landley , Jiri Kosina , LKML , kernel-janitors On Tue, 20 Aug 2013 15:11:18 -0700 Joe Perches wrote: > Andrew? Do you want to handle patches for defects that > are both obvious _and_ trivial? I look at everything! If I like it and see that Jiri was cc'ed I try to remember to cc him on the commit. > > If it's trivial it's not time critical. If it's time critical it's not > > trivial. > > We disagree on the definition of trivial. > Trivial can also mean simple and immediately evident. I find that I often remove "trivial" from changelogs and titles. Patches which are marked thus are often non-trivial and merit a bit of thought. For example, I somewhat disagree that even https://patchwork.kernel.org/patch/2833648/ was trivial. It changes the format of kernel logs and might have implications for people who are parsing those logs. Unlikely, but one needs to read each and every conversion and decide on the risk factor.