Re: rfc: trivial patches and slow deaths?
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
On Tue, 2013-08-20 at 15:24 -0700, Andrew Morton wrote: > 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! 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... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
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 > > triv...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rfc: trivial patches and slow deaths?
On Mon, 19 Aug 2013, Joe Perches wrote: > Patches submitted to the trivial address > triv...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
rfc: trivial patches and slow deaths?
Patches submitted to the trivial address triv...@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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
