rfc: trivial patches and slow deaths?

rfc: trivial patches and slow deaths?

[Joe Perches]

Patches submitted to the trivial address
trivial@kernel.org seem to go nowhere slowly.

Jiri, do you have any actual plans to try to
pick up these patches, notify the submitters
that the patches have been accepted or rejected,
and forward them on when appropriate?

Otherwise, the patches sit for _months_ without
any action.  That's simply too long.

Should another mechanism or pathway be created
instead?

Re: rfc: trivial patches and slow deaths?

[Jiri Kosina]

On Mon, 19 Aug 2013, Joe Perches wrote:

> Patches submitted to the trivial address
> trivial@kernel.org seem to go nowhere slowly.
> 
> Jiri, do you have any actual plans to try to
> pick up these patches, notify the submitters
> that the patches have been accepted or rejected,
> and forward them on when appropriate?
> 
> Otherwise, the patches sit for _months_ without
> any action.  That's simply too long.
> 
> Should another mechanism or pathway be created
> instead?

Joe,

I disagree. Please look at what is happening in trivial.git over longer 
period of time.

The patches I am holding off are larger series which are submitted both to 
trivial@ and maintainers as well. With such pathces, it's not clear who is 
taking (which parts of) what, hence I hold them off for long time, and get 
back to it eventually later.

It's time consuming, as I have to check linux-next for those patches, 
hence it's delayed.

One-shot single trivial patches are picked up reasonably fast (i.e. are 
very rarely delayed for one Linus' release).

But yes, I agree, you are usually sending cross-tree large patchsets, and 
therefore you are often affected by what you describe.

Perhaps if you send to trivial@ only those patches which haven't been 
picked up by maintainers already, that'd lead to much faster application 
of those, if that's what you are about.

-- 
Jiri Kosina
SUSE Labs

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Mon, 2013-08-19 at 22:34 +0200, Jiri Kosina wrote:
> On Mon, 19 Aug 2013, Joe Perches wrote:
> 
> > Patches submitted to the trivial address
> > trivial@kernel.org seem to go nowhere slowly.
> > 
> > Jiri, do you have any actual plans to try to
> > pick up these patches, notify the submitters
> > that the patches have been accepted or rejected,
> > and forward them on when appropriate?
> > 
> > Otherwise, the patches sit for _months_ without
> > any action.  That's simply too long.
> > 
> > Should another mechanism or pathway be created
> > instead?
> 
> Joe,
> 
> I disagree. Please look at what is happening in trivial.git over longer 
> period of time.

I need to look at years instead of months?

Would US Presidental election cycles or decades
be better timeframes?

> The patches I am holding off are larger series which are submitted both to 
> trivial@ and maintainers as well.

What makes something "large" to you?

This is a 7 line patch that corrects logging defects
that has had no reply from you for the last month.

https://patchwork.kernel.org/patch/2833648/

>  With such pathces, it's not clear who is 
> taking (which parts of) what, hence I hold them off for long time, and get 
> back to it eventually later.
> It's time consuming, as I have to check linux-next for those patches, 
> hence it's delayed.

No, I think you don't have to do that checking.

When I submit patches to trivial, they are submitted to you
with a simple, polite cc to the nominal maintainer(s).

You delay these patches and you also provide no feedback
as to whatever status may or may not exist to the handling
of these patches.

You're very opaque to these patches being handled or ignored.

For instance, the ctl_table typedef removal series from over
2 months ago:

https://lkml.org/lkml/2013/6/13/650

Originally, 33 patches sent to trivial (you) broken out by
subsystem with cc's to nominal maintainers.

Not a single reply to this by you to the series.

You did apply 2 of the 33 when the other nominal
maintainers supplied "acked-by"s.

I submitted another single aggregated patch with the
unapplied remainders a month ago and there's been no
action by you at all on it.

https://lkml.org/lkml/2013/7/22/600

I think that's overly long a time frame (any patch
series will bitrot) and too opaque for trivial patch
submitters to have any idea what's going on.

Also, if you're concerned that the trivial tree
wouldn't merge well in next, couldn't you use
pull+rebase to work out whether or not a patch has
already been applied in another tree?

cheers, Joe

Re: rfc: trivial patches and slow deaths?

[Jiri Kosina]

On Mon, 19 Aug 2013, Joe Perches wrote:

> This is a 7 line patch that corrects logging defects that has had no 
> reply from you for the last month.
> 
> https://patchwork.kernel.org/patch/2833648/

This hasn't missed any Linus' major release, as it has been submitted post 
3.11 merge, right? (hint, that was Jul 4th).

If this would miss *next* major Linus' release, I would accept your 
complaints. But this is definitely not the case.

Joe, patience is a virtue. Especially when it comes to lower-priority 
stuff.

> I think that's overly long a time frame (any patch series will bitrot) 
> and too opaque for trivial patch submitters to have any idea what's 
> going on.

Again, only large, corss-subsystem series with a lot of maintainers CCed 
are generally delayed.

> Also, if you're concerned that the trivial tree wouldn't merge well in 
> next, 

That's not my concern. My concern is

- avoid work duplication
- avoid git history pollution (again, especially by trivial stuff)
- avoid unecessary stepping on maintainer's toes by something that has 
  such a low importance as trivial.git

Thanks for taking care,

-- 
Jiri Kosina
SUSE Labs

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Mon, 2013-08-19 at 23:22 +0200, Jiri Kosina wrote:
> On Mon, 19 Aug 2013, Joe Perches wrote:
> 
> > This is a 7 line patch that corrects logging defects that has had no 
> > reply from you for the last month.
> > 
> > https://patchwork.kernel.org/patch/2833648/
> 
> This hasn't missed any Linus' major release, as it has been submitted post 
> 3.11 merge, right? (hint, that was Jul 4th).
> 
> If this would miss *next* major Linus' release, I would accept your 
> complaints. But this is definitely not the case.

You're suggesting this patch, which corrects obvious
defects, should miss 3.12 and go into 3.13?

I think that's wrong.

I think it should be in -next now.  It's not.

What should any patch submitter expect about
visibility and/or knowledge of the applicability
of this sort of patch from trivial?

Re: rfc: trivial patches and slow deaths?

[Rob Landley]

On 08/19/2013 04:27:17 PM, Joe Perches wrote:
> On Mon, 2013-08-19 at 23:22 +0200, Jiri Kosina wrote:
> > On Mon, 19 Aug 2013, Joe Perches wrote:
> >
> > > This is a 7 line patch that corrects logging defects that has had  
> no
> > > reply from you for the last month.
> > >
> > > https://patchwork.kernel.org/patch/2833648/
> >
> > This hasn't missed any Linus' major release, as it has been  
> submitted post
> > 3.11 merge, right? (hint, that was Jul 4th).
> >
> > If this would miss *next* major Linus' release, I would accept your
> > complaints. But this is definitely not the case.
> 
> You're suggesting this patch, which corrects obvious
> defects, should miss 3.12 and go into 3.13?
> 
> I think that's wrong.

Correcting obvious defects, which can't wait a release, is "trivial"  
now, is it?

Rob

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Tue, 2013-08-20 at 15:02 -0500, Rob Landley wrote:
> On 08/19/2013 04:27:17 PM, Joe Perches wrote:
> > On Mon, 2013-08-19 at 23:22 +0200, Jiri Kosina wrote:
> > > On Mon, 19 Aug 2013, Joe Perches wrote:
> > >
> > > > This is a 7 line patch that corrects logging defects that has had  
> > no
> > > > reply from you for the last month.
> > > >
> > > > https://patchwork.kernel.org/patch/2833648/
> > >
> > > This hasn't missed any Linus' major release, as it has been  
> > submitted post
> > > 3.11 merge, right? (hint, that was Jul 4th).
> > >
> > > If this would miss *next* major Linus' release, I would accept your
> > > complaints. But this is definitely not the case.
> > 
> > You're suggesting this patch, which corrects obvious
> > defects, should miss 3.12 and go into 3.13?
> > 
> > I think that's wrong.
> 
> Correcting obvious defects, which can't wait a release, is "trivial"  
> now, is it?

Rob, how do you suggest this obvious and trivial
patch be handled?

Send 6+ 1 line patches that do the same thing to
individual maintainers?

The next release in a couple/few weeks is 3.11.
3.12 should take 2.5/3 months for a typical cycle.

Patches bound for 3.12 should be in -next today.

3.13 should be out in about half a year.

Is it really appropriate to delay the trivially
obvious for sixish months?

Re: rfc: trivial patches and slow deaths?

[Rob Landley]

On 08/20/2013 03:14:10 PM, Joe Perches wrote:
> On Tue, 2013-08-20 at 15:02 -0500, Rob Landley wrote:
> > On 08/19/2013 04:27:17 PM, Joe Perches wrote:
> > > On Mon, 2013-08-19 at 23:22 +0200, Jiri Kosina wrote:
> > > > On Mon, 19 Aug 2013, Joe Perches wrote:
> > > >
> > > > > This is a 7 line patch that corrects logging defects that has  
> had
> > > no
> > > > > reply from you for the last month.
> > > > >
> > > > > https://patchwork.kernel.org/patch/2833648/
> > > >
> > > > This hasn't missed any Linus' major release, as it has been
> > > submitted post
> > > > 3.11 merge, right? (hint, that was Jul 4th).
> > > >
> > > > If this would miss *next* major Linus' release, I would accept  
> your
> > > > complaints. But this is definitely not the case.
> > >
> > > You're suggesting this patch, which corrects obvious
> > > defects, should miss 3.12 and go into 3.13?
> > >
> > > I think that's wrong.
> >
> > Correcting obvious defects, which can't wait a release, is "trivial"
> > now, is it?
> 
> Rob, how do you suggest this obvious and trivial
> patch be handled?

Obvious != trivial. They're orthogonal.

> Send 6+ 1 line patches that do the same thing to
> individual maintainers?

If it's important send it to Andrew Morton.

> The next release in a couple/few weeks is 3.11.
> 3.12 should take 2.5/3 months for a typical cycle.
> 
> Patches bound for 3.12 should be in -next today.
> 
> 3.13 should be out in about half a year.
> 
> Is it really appropriate to delay the trivially
> obvious for sixish months?

If it's trivial it's not time critical. If it's time critical it's not  
trivial.

Rob

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Tue, 2013-08-20 at 16:49 -0500, Rob Landley wrote:
> On 08/20/2013 03:14:10 PM, Joe Perches wrote:
> > On Tue, 2013-08-20 at 15:02 -0500, Rob Landley wrote:
> > > On 08/19/2013 04:27:17 PM, Joe Perches wrote:
> > > > On Mon, 2013-08-19 at 23:22 +0200, Jiri Kosina wrote:
> > > > > On Mon, 19 Aug 2013, Joe Perches wrote:
> > > > >
> > > > > > This is a 7 line patch that corrects logging defects that has  
> > had
> > > > no
> > > > > > reply from you for the last month.
> > > > > >
> > > > > > https://patchwork.kernel.org/patch/2833648/
> > > > >
> > > > > This hasn't missed any Linus' major release, as it has been
> > > > submitted post
> > > > > 3.11 merge, right? (hint, that was Jul 4th).
> > > > >
> > > > > If this would miss *next* major Linus' release, I would accept  
> > your
> > > > > complaints. But this is definitely not the case.
> > > >
> > > > You're suggesting this patch, which corrects obvious
> > > > defects, should miss 3.12 and go into 3.13?
> > > >
> > > > I think that's wrong.
> > >
> > > Correcting obvious defects, which can't wait a release, is "trivial"
> > > now, is it?
> > 
> > Rob, how do you suggest this obvious and trivial
> > patch be handled?
> 
> Obvious != trivial. They're orthogonal.

Silly.  Some things are both obvious _and_ trivial.

> > Send 6+ 1 line patches that do the same thing to
> > individual maintainers?
> 
> If it's important send it to Andrew Morton.

Andrew?  Do you want to handle patches for defects that
are both obvious _and_ trivial?

> 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.

Re: rfc: trivial patches and slow deaths?

[Andrew Morton]

On Tue, 20 Aug 2013 15:11:18 -0700 Joe Perches <joe@perches.com> 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.

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Tue, 2013-08-20 at 15:24 -0700, Andrew Morton wrote:
> On Tue, 20 Aug 2013 15:11:18 -0700 Joe Perches <joe@perches.com> wrote:
> 
> > Andrew?  Do you want to handle patches for defects that
> > are both obvious _and_ trivial?
> 
> I look at everything!

Well, I guess I'll have to start cc'ing you on
the trivial in case the eyestrain gets to you.

[]

> 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.

I think there are _very_ few instances where dmesg
output should be kept constant for scrapers.

The format of an oops is about the only one I can
think of where it's reasonable to do so.

> one needs to read each and every
> conversion and decide on the risk factor.

Enjoy...

Re: rfc: trivial patches and slow deaths?

[Rob Landley]

On 08/20/2013 05:11:18 PM, Joe Perches wrote:
> On Tue, 2013-08-20 at 16:49 -0500, Rob Landley wrote:
> > On 08/20/2013 03:14:10 PM, Joe Perches wrote:
> > > On Tue, 2013-08-20 at 15:02 -0500, Rob Landley wrote:
> > > > On 08/19/2013 04:27:17 PM, Joe Perches wrote:
> > > > > On Mon, 2013-08-19 at 23:22 +0200, Jiri Kosina wrote:
> > > > > > On Mon, 19 Aug 2013, Joe Perches wrote:
> > > > > >
> > > > > > > This is a 7 line patch that corrects logging defects that  
> has
> > > had
> > > > > no
> > > > > > > reply from you for the last month.
> > > > > > >
> > > > > > > https://patchwork.kernel.org/patch/2833648/
> > > > > >
> > > > > > This hasn't missed any Linus' major release, as it has been
> > > > > submitted post
> > > > > > 3.11 merge, right? (hint, that was Jul 4th).
> > > > > >
> > > > > > If this would miss *next* major Linus' release, I would  
> accept
> > > your
> > > > > > complaints. But this is definitely not the case.
> > > > >
> > > > > You're suggesting this patch, which corrects obvious
> > > > > defects, should miss 3.12 and go into 3.13?
> > > > >
> > > > > I think that's wrong.
> > > >
> > > > Correcting obvious defects, which can't wait a release, is  
> "trivial"
> > > > now, is it?
> > >
> > > Rob, how do you suggest this obvious and trivial
> > > patch be handled?
> >
> > Obvious != trivial. They're orthogonal.
> 
> Silly.  Some things are both obvious _and_ trivial.

You believe orthogonal things never coincide? Then they wouldn't be  
orthogonal. (It means unrelated, not exclusive.)

> > > Send 6+ 1 line patches that do the same thing to
> > > individual maintainers?
> >
> > If it's important send it to Andrew Morton.
> 
> Andrew?  Do you want to handle patches for defects that
> are both obvious _and_ trivial?

The important question is does he want to handle patches that you're  
flipping out about not going in before the next merge window because  
they are SO IMPORTANT that the trivial tree must promote them out of  
sequence.

If it's that important, it's not "trivial".

> > 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.

Yes. Yes we do.

> Trivial can also mean simple and immediately evident.

If it's so important that it can't wait until the next merge window,  
the trivial tree's maintainer said the trivial tree is not the right  
channel to merge it through.

Rob

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Tue, 2013-08-20 at 19:10 -0500, Rob Landley wrote:
> The important question is does he want to handle patches that you're  
> flipping out about not going in before the next merge window because  
> they are SO IMPORTANT that the trivial tree must promote them out of  
> sequence.

You're misreading.  I see no flipping out here.

I'm simply saying that obvious defects should be
corrected sooner rather than later.

I'm also saying that the trivial tree should
have some visibility about whether or not a
patch or series will be handled by the trivial
maintainer or not.

Jiri has not responded to this point.

Silence about the status of patches that extends
for months is not good.

Re: rfc: trivial patches and slow deaths?

[Rob Landley]

On 08/20/2013 07:22:36 PM, Joe Perches wrote:
> On Tue, 2013-08-20 at 19:10 -0500, Rob Landley wrote:
> > The important question is does he want to handle patches that you're
> > flipping out about not going in before the next merge window because
> > they are SO IMPORTANT that the trivial tree must promote them out of
> > sequence.
> 
> You're misreading.  I see no flipping out here.
> 
> I'm simply saying that obvious defects should be
> corrected sooner rather than later.
> 
> I'm also saying that the trivial tree should
> have some visibility about whether or not a
> patch or series will be handled by the trivial
> maintainer or not.

I fetch his git and look at the log of the branch to see which of the  
documentation patches I forwarded are there. That said, there's no  
guarantee they'll go in from there because other maintainers often grab  
them and put them in through their trees.

> Jiri has not responded to this point.

He did. Twice.

> Silence about the status of patches that extends
> for months is not good.

He has a public git tree. It's listed in his MAINTAINERS entry. I've  
found that if a patch isn't in there, he hasn't picked it up yet. (I've  
been feeding Documentation patches through his tree, hence my interest  
in this thread.)

Rob

Re: rfc: trivial patches and slow deaths?

[Joe Perches]

On Tue, 2013-08-20 at 20:36 -0500, Rob Landley wrote:
> On 08/20/2013 07:22:36 PM, Joe Perches wrote:
> > I'm also saying that the trivial tree should
> > have some visibility about whether or not a
> > patch or series will be handled by the trivial
> > maintainer or not.
[]
> > Jiri has not responded to this point.
> He did. Twice.

Not really.

> > Silence about the status of patches that extends
> > for months is not good.
> 
> He has a public git tree.

Yes, I know.

> I've found that if a patch isn't in there, he hasn't picked
> it up yet.

It's the visibility of if/yet/when for the trivial
patches submitted and unresponded to that's the question.

And no, Jiri hasn't responded with any intention of
making any such scheme public.

I think a public patchwork queue like netdev's could
work reasonably well.

http://patchwork.ozlabs.org/project/netdev/list/