Patches submitted to the trivial address
[email protected] 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?
On Mon, 19 Aug 2013, Joe Perches wrote:
> Patches submitted to the trivial address
> [email protected] 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
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
> > [email protected] 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
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
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?
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-
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?
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-
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.
On Tue, 20 Aug 2013 15:11:18 -0700 Joe Perches <[email protected]> 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.
On Tue, 2013-08-20 at 15:24 -0700, Andrew Morton wrote:
> On Tue, 20 Aug 2013 15:11:18 -0700 Joe Perches <[email protected]> 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...
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-
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.
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-
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/