* [Ksummit-discuss] Maintainer's Summit Agenda Planning @ 2017-10-05 19:20 Theodore Ts'o 2017-10-05 20:13 ` Rafael J. Wysocki ` (3 more replies) 0 siblings, 4 replies; 42+ messages in thread From: Theodore Ts'o @ 2017-10-05 19:20 UTC (permalink / raw) To: ksummit-discuss This is a rough draft of a proposed agenda for the Maintainer's Summit. I've fliled in most of the slots with those topics that seemed to make the most amount of sense as topics for us to talk about, with some room intentionally blank sponts. Please comment about topics you think we should include in the agenda; or if you think there are topics that should not be included, please also let us know. Thanks!! - Ted Maintainers Summit -- Thursday 8:00 am Breakfast 9:00 am Agenda Bashing 9:30 am Improve regression tracking 10:00 am Bash the kernel maintainers 10:30 am Android Kernel Issues (drivers, long-term stable) 11:00 am What is Linus Happy/Unhappy about? 11:30 am 12:00 am 12:30 pm Lunch Appendix: Other topics that were brought up ------------------------------------------- Documentation Bug reporting feedback loop Driver and/or module versions Developing across multiple areas of the kernel ABI feature gates tracepoints without user space interfaces (EBPF) Appendix: Maintainer's Summit Attendees --------------------------------------- (Does not include the sponsored attendees; I don't have most of those names yet.) Andrew Morton Arnd Bergmann Ben Hutchings Chris Mason Dan Williams Fengguang Wu Greg KH H. Peter Anvin James Bottomley Jens Axboe Jiri Kosina Jonathan Corbet Kees Cook Laura Abbott Linus Torvalds Martin Petersen Michael Ellerman Rom Lemarchand Sean Paul Shuah Khan Stephen Rothwell Takashi Iwai Ted Ts'o Thorsten Leemhuis ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-05 19:20 [Ksummit-discuss] Maintainer's Summit Agenda Planning Theodore Ts'o @ 2017-10-05 20:13 ` Rafael J. Wysocki 2017-10-05 21:55 ` Jiri Kosina ` (2 subsequent siblings) 3 siblings, 0 replies; 42+ messages in thread From: Rafael J. Wysocki @ 2017-10-05 20:13 UTC (permalink / raw) To: Theodore Ts'o; +Cc: ksummit-discuss On Thursday, October 5, 2017 9:20:02 PM CEST Theodore Ts'o wrote: > This is a rough draft of a proposed agenda for the Maintainer's > Summit. > > I've fliled in most of the slots with those topics that seemed to make > the most amount of sense as topics for us to talk about, with some > room intentionally blank sponts. > > Please comment about topics you think we should include in the agenda; > or if you think there are topics that should not be included, please > also let us know. > > Thanks!! > > - Ted > > Maintainers Summit -- Thursday > > 8:00 am Breakfast > 9:00 am Agenda Bashing > 9:30 am Improve regression tracking Well, to be honest I really would like to participate in this discussion. It really is relevant to all maintainers IMO. > 10:00 am Bash the kernel maintainers > 10:30 am Android Kernel Issues (drivers, long-term stable) > 11:00 am What is Linus Happy/Unhappy about? > 11:30 am > 12:00 am > 12:30 pm Lunch > > > Appendix: Other topics that were brought up > ------------------------------------------- > > Documentation > Bug reporting feedback loop Similarly for the two topics above. > Driver and/or module versions > Developing across multiple areas of the kernel And same here. > ABI feature gates > tracepoints without user space interfaces (EBPF) Thanks, Rafael ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-05 19:20 [Ksummit-discuss] Maintainer's Summit Agenda Planning Theodore Ts'o 2017-10-05 20:13 ` Rafael J. Wysocki @ 2017-10-05 21:55 ` Jiri Kosina 2017-10-06 14:59 ` Takashi Iwai 2017-10-06 15:27 ` James Bottomley 3 siblings, 0 replies; 42+ messages in thread From: Jiri Kosina @ 2017-10-05 21:55 UTC (permalink / raw) To: Theodore Ts'o; +Cc: ksummit-discuss On Thu, 5 Oct 2017, Theodore Ts'o wrote: > Please comment about topics you think we should include in the agenda; > or if you think there are topics that should not be included, please > also let us know. [ ... snip ... ] > > Maintainers Summit -- Thursday > > 8:00 am Breakfast > 9:00 am Agenda Bashing > 9:30 am Improve regression tracking > 10:00 am Bash the kernel maintainers > 10:30 am Android Kernel Issues (drivers, long-term stable) > 11:00 am What is Linus Happy/Unhappy about? > 11:30 am > 12:00 am > 12:30 pm Lunch > Appendix: Other topics that were brought up > ------------------------------------------- [... snip ... ] If we are voting about the topics to fill 11:30 and 12:00 slots, my choice definitely would be (the first one even more so as especially major distros will apparently have representatives there): > Bug reporting feedback loop > ABI feature gates Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-05 19:20 [Ksummit-discuss] Maintainer's Summit Agenda Planning Theodore Ts'o 2017-10-05 20:13 ` Rafael J. Wysocki 2017-10-05 21:55 ` Jiri Kosina @ 2017-10-06 14:59 ` Takashi Iwai 2017-10-06 15:27 ` James Bottomley 3 siblings, 0 replies; 42+ messages in thread From: Takashi Iwai @ 2017-10-06 14:59 UTC (permalink / raw) To: Theodore Ts'o; +Cc: ksummit-discuss On Thu, 05 Oct 2017 21:20:02 +0200, Theodore Ts'o wrote: > > This is a rough draft of a proposed agenda for the Maintainer's > Summit. > > I've fliled in most of the slots with those topics that seemed to make > the most amount of sense as topics for us to talk about, with some > room intentionally blank sponts. > > Please comment about topics you think we should include in the agenda; > or if you think there are topics that should not be included, please > also let us know. > > Thanks!! > > - Ted > > Maintainers Summit -- Thursday > > 8:00 am Breakfast > 9:00 am Agenda Bashing > 9:30 am Improve regression tracking > 10:00 am Bash the kernel maintainers > 10:30 am Android Kernel Issues (drivers, long-term stable) > 11:00 am What is Linus Happy/Unhappy about? > 11:30 am > 12:00 am > 12:30 pm Lunch > > > Appendix: Other topics that were brought up > ------------------------------------------- > > Documentation > Bug reporting feedback loop I think this one (bug reporting) can be combined with regression tracking session. In practice, they are tied closely. Other than that, > Developing across multiple areas of the kernel > ABI feature gates ... these two are my vote to be filled in the empty slots. thanks, Takashi > tracepoints without user space interfaces (EBPF) > > Appendix: Maintainer's Summit Attendees > --------------------------------------- > > (Does not include the sponsored attendees; I don't have most of those > names yet.) > > Andrew Morton > Arnd Bergmann > Ben Hutchings > Chris Mason > Dan Williams > Fengguang Wu > Greg KH > H. Peter Anvin > James Bottomley > Jens Axboe > Jiri Kosina > Jonathan Corbet > Kees Cook > Laura Abbott > Linus Torvalds > Martin Petersen > Michael Ellerman > Rom Lemarchand > Sean Paul > Shuah Khan > Stephen Rothwell > Takashi Iwai > Ted Ts'o > Thorsten Leemhuis > > > > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-05 19:20 [Ksummit-discuss] Maintainer's Summit Agenda Planning Theodore Ts'o ` (2 preceding siblings ...) 2017-10-06 14:59 ` Takashi Iwai @ 2017-10-06 15:27 ` James Bottomley 2017-10-06 16:26 ` Josh Poimboeuf ` (3 more replies) 3 siblings, 4 replies; 42+ messages in thread From: James Bottomley @ 2017-10-06 15:27 UTC (permalink / raw) To: Theodore Ts'o, ksummit-discuss On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > Appendix: Other topics that were brought up > ------------------------------------------- > > Documentation > Bug reporting feedback loop > Driver and/or module versions > Developing across multiple areas of the kernel > ABI feature gates > tracepoints without user space interfaces (EBPF) I've got a couple of extra possibilities 1) git tree script alignment. Most of us send out some type of your patch was added and your patch was dropped email notifications. We usually automate it through a private tree git commit or update script. Should we standardise these (because if we do, we could have kernel.org do it for us instead of running our own infrastructure). 2) Trivial patches (again). OpenStack has recently started to become annoyed by these http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122472 I thought about our process around the trivial tree, but it hasn't been updated in the last few releases, so effectively we no longer use it. So is what we're currently doing (variable standards by tree) OK, or should we have a more concerted trivial policy? 3) Tasteful Rebasing. We've come around (finally) to the conclusion that rebasing isn't always bad. My own opinion is that rebasing to fix issues in patches (particularly those marked for stable) so they can backport cleanly and atomically. There's also less of a consensus that rebasing to clean up history is a reasonably good thing (provided it's not done just before requesting a pull). However, we have a divergence of opinions not just on whether we should rebase, but what constitutes a tasteful rebase. Just telling people, particularly would be new maintainers, that it's a judgement call always is unhelpful, we could do with putting together some more detailed guidance (assuming we can agree on it). James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 15:27 ` James Bottomley @ 2017-10-06 16:26 ` Josh Poimboeuf 2017-10-06 16:32 ` Jonathan Corbet 2017-10-09 8:13 ` Mark Brown ` (2 subsequent siblings) 3 siblings, 1 reply; 42+ messages in thread From: Josh Poimboeuf @ 2017-10-06 16:26 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss On Fri, Oct 06, 2017 at 08:27:45AM -0700, James Bottomley wrote: > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > > Appendix: Other topics that were brought up > > ------------------------------------------- > > > > Documentation > > Bug reporting feedback loop > > Driver and/or module versions > > Developing across multiple areas of the kernel > > ABI feature gates > > tracepoints without user space interfaces (EBPF) > > I've got a couple of extra possibilities > > 1) git tree script alignment. Most of us send out some type of your > patch was added and your patch was dropped email notifications. We > usually automate it through a private tree git commit or update script. > Should we standardise these (because if we do, we could have > kernel.org do it for us instead of running our own infrastructure). > > 2) Trivial patches (again). OpenStack has recently started to become > annoyed by these > > http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122472 > > I thought about our process around the trivial tree, but it hasn't been > updated in the last few releases, so effectively we no longer use it. > So is what we're currently doing (variable standards by tree) OK, or > should we have a more concerted trivial policy? > > 3) Tasteful Rebasing. We've come around (finally) to the conclusion > that rebasing isn't always bad. My own opinion is that rebasing to fix > issues in patches (particularly those marked for stable) so they can > backport cleanly and atomically. There's also less of a consensus that > rebasing to clean up history is a reasonably good thing (provided it's > not done just before requesting a pull). However, we have a divergence > of opinions not just on whether we should rebase, but what constitutes > a tasteful rebase. Just telling people, particularly would be new > maintainers, that it's a judgement call always is unhelpful, we could > do with putting together some more detailed guidance (assuming we can > agree on it). Maintainers seem to have a lot of tribal knowledge, which is self-taught, or passed on by word of mouth, or learned the hard way when they make a mistake: branch management, merge conflicts, rebasing, pull requests, cross-tree changes, release candidate timing, co-maintainer processes, etc. I think it would be a good idea to have a Maintainer's Guide which tries to document a lot of this knowledge. It would help new maintainers learn the ropes, and would also help drive consensus for maintainer's best practices. It could document the typical processes of a maintainer, and policy guidelines like some of the above topics. -- Josh ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 16:26 ` Josh Poimboeuf @ 2017-10-06 16:32 ` Jonathan Corbet 2017-10-06 16:51 ` Josh Poimboeuf ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Jonathan Corbet @ 2017-10-06 16:32 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: James Bottomley, ksummit-discuss On Fri, 6 Oct 2017 11:26:21 -0500 Josh Poimboeuf <jpoimboe@redhat.com> wrote: > I think it would be a good idea to have a Maintainer's Guide which tries > to document a lot of this knowledge. It would help new maintainers > learn the ropes, and would also help drive consensus for maintainer's > best practices. It could document the typical processes of a > maintainer, and policy guidelines like some of the above topics. Strangely enough, this is a conversation that has been popping up in other contexts too. We may see an initial attempt before too long. The tricky part, of course, is finding a way to document the consensus on best practices without trying to "drive" it too hard. My own thought is that a good starting place might be a "how to avoid getting your pull request flamed" document, since there is some semblance of a consensus there and it's a place where people often make mistakes. jon ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 16:32 ` Jonathan Corbet @ 2017-10-06 16:51 ` Josh Poimboeuf 2017-10-06 16:56 ` James Bottomley 2017-10-06 20:11 ` Linus Walleij 2 siblings, 0 replies; 42+ messages in thread From: Josh Poimboeuf @ 2017-10-06 16:51 UTC (permalink / raw) To: Jonathan Corbet; +Cc: James Bottomley, ksummit-discuss On Fri, Oct 06, 2017 at 10:32:59AM -0600, Jonathan Corbet wrote: > On Fri, 6 Oct 2017 11:26:21 -0500 > Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > I think it would be a good idea to have a Maintainer's Guide which tries > > to document a lot of this knowledge. It would help new maintainers > > learn the ropes, and would also help drive consensus for maintainer's > > best practices. It could document the typical processes of a > > maintainer, and policy guidelines like some of the above topics. > > Strangely enough, this is a conversation that has been popping up in other > contexts too. We may see an initial attempt before too long. Ah, nice. > The tricky part, of course, is finding a way to document the consensus on > best practices without trying to "drive" it too hard. We somehow manage to get consensus on millions of lines of code, you'd think we could figure out how to agree on a small process document ;-) But seriously, I think even parts which are disagreed upon, or which are up to the maintainer's judgement, can be documented as such. I wonder if a maintainers mailing list would help for such discussions, if we don't already have one. > My own thought is that a good starting place might be a "how to avoid > getting your pull request flamed" document, since there is some semblance > of a consensus there and it's a place where people often make mistakes. Agreed! -- Josh ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 16:32 ` Jonathan Corbet 2017-10-06 16:51 ` Josh Poimboeuf @ 2017-10-06 16:56 ` James Bottomley 2017-10-06 17:16 ` Josh Poimboeuf 2017-10-06 20:11 ` Linus Walleij 2 siblings, 1 reply; 42+ messages in thread From: James Bottomley @ 2017-10-06 16:56 UTC (permalink / raw) To: Jonathan Corbet, Josh Poimboeuf; +Cc: ksummit-discuss On Fri, 2017-10-06 at 10:32 -0600, Jonathan Corbet wrote: > On Fri, 6 Oct 2017 11:26:21 -0500 > Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > I think it would be a good idea to have a Maintainer's Guide which > > tries to document a lot of this knowledge. It would help new > > maintainers learn the ropes, and would also help drive consensus > > for maintainer's best practices. It could document the typical > > processes of a maintainer, and policy guidelines like some of the > > above topics. > > Strangely enough, this is a conversation that has been popping up in > other contexts too. We may see an initial attempt before too long. > > The tricky part, of course, is finding a way to document the > consensus on best practices without trying to "drive" it too hard. > > My own thought is that a good starting place might be a "how to avoid > getting your pull request flamed" document, since there is some > semblance of a consensus there and it's a place where people often > make mistakes. Actually, I'd argue this is the most arcane area. Accepting a pull request represents the expression of a trust relationship and it's not entirely well documented how to form that. The mechanics of what should be in it and how it should be split vary by puller. For instance, Linus' requirements are reasonably well documented in git- request-pull, but other trees have varying requirements. Why he might flame you varies from too many merge window patches in a non-merge window to to many merge points in the tree or "unclean" history. James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 16:56 ` James Bottomley @ 2017-10-06 17:16 ` Josh Poimboeuf 0 siblings, 0 replies; 42+ messages in thread From: Josh Poimboeuf @ 2017-10-06 17:16 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss On Fri, Oct 06, 2017 at 09:56:44AM -0700, James Bottomley wrote: > On Fri, 2017-10-06 at 10:32 -0600, Jonathan Corbet wrote: > > On Fri, 6 Oct 2017 11:26:21 -0500 > > Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > > > > I think it would be a good idea to have a Maintainer's Guide which > > > tries to document a lot of this knowledge. It would help new > > > maintainers learn the ropes, and would also help drive consensus > > > for maintainer's best practices. It could document the typical > > > processes of a maintainer, and policy guidelines like some of the > > > above topics. > > > > Strangely enough, this is a conversation that has been popping up in > > other contexts too. We may see an initial attempt before too long. > > > > The tricky part, of course, is finding a way to document the > > consensus on best practices without trying to "drive" it too hard. > > > > My own thought is that a good starting place might be a "how to avoid > > getting your pull request flamed" document, since there is some > > semblance of a consensus there and it's a place where people often > > make mistakes. > > Actually, I'd argue this is the most arcane area. Accepting a pull > request represents the expression of a trust relationship and it's not > entirely well documented how to form that. The mechanics of what > should be in it and how it should be split vary by puller. For > instance, Linus' requirements are reasonably well documented in git- > request-pull, but other trees have varying requirements. Why he might > flame you varies from too many merge window patches in a non-merge > window to to many merge points in the tree or "unclean" history. Each thing you just said is a good example of something which should be documented. In fact I think each sentence could be expanded into a paragraph or section in the document. -- Josh ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 16:32 ` Jonathan Corbet 2017-10-06 16:51 ` Josh Poimboeuf 2017-10-06 16:56 ` James Bottomley @ 2017-10-06 20:11 ` Linus Walleij 2 siblings, 0 replies; 42+ messages in thread From: Linus Walleij @ 2017-10-06 20:11 UTC (permalink / raw) To: Jonathan Corbet; +Cc: James Bottomley, ksummit-discuss On Fri, Oct 6, 2017 at 6:32 PM, Jonathan Corbet <corbet@lwn.net> wrote: > The tricky part, of course, is finding a way to document the consensus on > best practices without trying to "drive" it too hard. I put some two very technical, not too subjective design patterns in Documentation/driver-model/design-patterns.txt I have found myself on the verge of sending a patch adding Rusty Russell's API design manifesto somewhere there http://sweng.the-davies.net/Home/rustys-api-design-manifesto The problem is mostly that I don't always feel what the consensus is. With some subsystem maintainers happily agree to disagree on so many things like inverse-christmas tree includes or u_int8_t vs u8 it's easy to be discouraged. I guess we should just be more bold? Who knows, maybe noone even gets upset. Apart from that I guess Documentation/process/* need to be updated with best practices? Maybe that was the actual initial question. I especially like management-style.rst, that doc kicks ass. Yours, Linus Walleij ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 15:27 ` James Bottomley 2017-10-06 16:26 ` Josh Poimboeuf @ 2017-10-09 8:13 ` Mark Brown 2017-10-09 15:54 ` Jiri Kosina 2017-10-24 23:03 ` Kees Cook 3 siblings, 0 replies; 42+ messages in thread From: Mark Brown @ 2017-10-09 8:13 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 641 bytes --] On Fri, Oct 06, 2017 at 08:27:45AM -0700, James Bottomley wrote: > 1) git tree script alignment. Most of us send out some type of your > patch was added and your patch was dropped email notifications. We > usually automate it through a private tree git commit or update script. > Should we standardise these (because if we do, we could have > kernel.org do it for us instead of running our own infrastructure). This has been talked about in the past on the list - there were concernes about monoculture making any problems with the scripts much worse and just there being enough differences in workflow to cause problems. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 15:27 ` James Bottomley 2017-10-06 16:26 ` Josh Poimboeuf 2017-10-09 8:13 ` Mark Brown @ 2017-10-09 15:54 ` Jiri Kosina 2017-10-09 16:37 ` James Bottomley 2017-10-24 23:03 ` Kees Cook 3 siblings, 1 reply; 42+ messages in thread From: Jiri Kosina @ 2017-10-09 15:54 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss On Fri, 6 Oct 2017, James Bottomley wrote: > 2) Trivial patches (again). OpenStack has recently started to become > annoyed by these > > http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122472 > > I thought about our process around the trivial tree, but it hasn't been > updated in the last few releases, so effectively we no longer use it. This has been caused solely by me being buried in other things, and there was always something else that overrode trivial tree in priority. > So is what we're currently doing (variable standards by tree) OK, or > should we have a more concerted trivial policy? My original plan was to revive trivial tree for 4.15, as there are quite a few patches in the queue (that still apply). But if it's generally considered annoying (although I am pretty sure we don't suffer from what's in the openstack thread), I don't object and can ditch it completely. The thing is that such patches will keep coming anyway, and I think they have the value (although the priority is really lower than other changes of course). I still believe that having greppable comments, for example, is nice to have. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-09 15:54 ` Jiri Kosina @ 2017-10-09 16:37 ` James Bottomley 2017-10-09 16:47 ` Joe Perches ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: James Bottomley @ 2017-10-09 16:37 UTC (permalink / raw) To: Jiri Kosina; +Cc: ksummit-discuss On Mon, 2017-10-09 at 17:54 +0200, Jiri Kosina wrote: > On Fri, 6 Oct 2017, James Bottomley wrote: > > > > > 2) Trivial patches (again). OpenStack has recently started to > > become annoyed by these > > > > http://lists.openstack.org/pipermail/openstack-dev/2017-September/t > > hread.html#122472 > > > > I thought about our process around the trivial tree, but it hasn't > > been updated in the last few releases, so effectively we no longer > > use it. > > This has been caused solely by me being buried in other things, and > there was always something else that overrode trivial tree in > priority. > > > > > So is what we're currently doing (variable standards by tree) OK, > > or should we have a more concerted trivial policy? > > My original plan was to revive trivial tree for 4.15, as there are > quite a few patches in the queue (that still apply). But if it's > generally considered annoying (although I am pretty sure we don't > suffer from what's in the openstack thread), I don't object and can > ditch it completely. Well, their objection was core (by which they mean Maintainer) review and merge time, plus the interference to higher priority patches caused by mismerges. I was actually thinking a trivial tree might help them because it would offload all the mismerges and review and they only need do a real merge just before release stabilisation. > The thing is that such patches will keep coming anyway, and I think > they have the value (although the priority is really lower than other > changes of course). I still believe that having greppable comments, > for example, is nice to have. Well, we tend to veto changes to old drivers in various subsystems anyway (having been burned by the this is only a trivial change and then finding out six months later that the driver is broken). Trivial changes seem to fall broadly into three categories: 1. spelling fixes 2. whitespace changes (I ran checkpatch.pl on your file and it returned these issues). 3. pattern imposition (we now have a new API for this so lets change all prior open coded incarnations) 4. trivial pattern fixes (things like replacing if(x) kfree(x); with kfree(x);) I don't want to open the whole spelling/whitespace can of worms, but perhaps we could have a more meaningful discussion about the pattern based issues ... for instance if we agree it's useful and coccinelle can do it, then tree wide replacement at -rc1 might be a better solution than ad-hoc application of hundreds of patches. James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-09 16:37 ` James Bottomley @ 2017-10-09 16:47 ` Joe Perches 2017-10-09 16:49 ` Julia Lawall 2017-10-10 8:53 ` Jiri Kosina 2 siblings, 0 replies; 42+ messages in thread From: Joe Perches @ 2017-10-09 16:47 UTC (permalink / raw) To: James Bottomley, Jiri Kosina; +Cc: ksummit-discuss On Mon, 2017-10-09 at 09:37 -0700, James Bottomley wrote: > it's useful and coccinelle > can do it, then tree wide replacement at -rc1 might be a better > solution than ad-hoc application of hundreds of patches. Patches that span subsystems are always painful and, even if submitted to all subsystems simultaneously, are frequently only partially applied. Scripting is useful. Coccinelle is a very good tool, but it is not the only scripted patch generator. A preferred mechanism to get scripted patches applied tree-wide would be beneficial. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-09 16:37 ` James Bottomley 2017-10-09 16:47 ` Joe Perches @ 2017-10-09 16:49 ` Julia Lawall 2017-10-09 16:56 ` James Bottomley 2017-10-10 8:53 ` Jiri Kosina 2 siblings, 1 reply; 42+ messages in thread From: Julia Lawall @ 2017-10-09 16:49 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 3066 bytes --] On Mon, 9 Oct 2017, James Bottomley wrote: > On Mon, 2017-10-09 at 17:54 +0200, Jiri Kosina wrote: > > On Fri, 6 Oct 2017, James Bottomley wrote: > > > > > > > > 2) Trivial patches (again). OpenStack has recently started to > > > become annoyed by these > > > > > > http://lists.openstack.org/pipermail/openstack-dev/2017-September/t > > > hread.html#122472 > > > > > > I thought about our process around the trivial tree, but it hasn't > > > been updated in the last few releases, so effectively we no longer > > > use it. > > > > This has been caused solely by me being buried in other things, and > > there was always something else that overrode trivial tree in > > priority. > > > > > > > > So is what we're currently doing (variable standards by tree) OK, > > > or should we have a more concerted trivial policy? > > > > My original plan was to revive trivial tree for 4.15, as there are > > quite a few patches in the queue (that still apply). But if it's > > generally considered annoying (although I am pretty sure we don't > > suffer from what's in the openstack thread), I don't object and can > > ditch it completely. > > Well, their objection was core (by which they mean Maintainer) review > and merge time, plus the interference to higher priority patches caused > by mismerges. I was actually thinking a trivial tree might help them > because it would offload all the mismerges and review and they only > need do a real merge just before release stabilisation. > > > The thing is that such patches will keep coming anyway, and I think > > they have the value (although the priority is really lower than other > > changes of course). I still believe that having greppable comments, > > for example, is nice to have. > > Well, we tend to veto changes to old drivers in various subsystems > anyway (having been burned by the this is only a trivial change and > then finding out six months later that the driver is broken). > > Trivial changes seem to fall broadly into three categories: > > 1. spelling fixes > 2. whitespace changes (I ran checkpatch.pl on your file and it returned > these issues). > 3. pattern imposition (we now have a new API for this so lets change > all prior open coded incarnations) > 4. trivial pattern fixes (things like replacing if(x) kfree(x); with > kfree(x);) > > I don't want to open the whole spelling/whitespace can of worms, but > perhaps we could have a more meaningful discussion about the pattern > based issues ... for instance if we agree it's useful and coccinelle > can do it, then tree wide replacement at -rc1 might be a better > solution than ad-hoc application of hundreds of patches. Do you suggest one big patch, that goes to who? Or lots of little patches that go out at once to the individual maintainers of the affected code? Both are doable. julia > > James > > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-09 16:49 ` Julia Lawall @ 2017-10-09 16:56 ` James Bottomley 2017-10-09 17:04 ` Joe Perches 2017-10-11 18:51 ` Jani Nikula 0 siblings, 2 replies; 42+ messages in thread From: James Bottomley @ 2017-10-09 16:56 UTC (permalink / raw) To: Julia Lawall; +Cc: ksummit-discuss On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: > > On Mon, 9 Oct 2017, James Bottomley wrote: > > > > > On Mon, 2017-10-09 at 17:54 +0200, Jiri Kosina wrote: > > > > > > On Fri, 6 Oct 2017, James Bottomley wrote: > > > > > > > > > > > > > > > 2) Trivial patches (again). OpenStack has recently started to > > > > become annoyed by these > > > > > > > > http://lists.openstack.org/pipermail/openstack-dev/2017-Septemb > > > > er/t > > > > hread.html#122472 > > > > > > > > I thought about our process around the trivial tree, but it > > > > hasn't been updated in the last few releases, so effectively we > > > > no longer use it. > > > > > > This has been caused solely by me being buried in other things, > > > and there was always something else that overrode trivial tree in > > > priority. > > > > > > > > > > > > > > > So is what we're currently doing (variable standards by tree) > > > > OK, or should we have a more concerted trivial policy? > > > > > > My original plan was to revive trivial tree for 4.15, as there > > > are quite a few patches in the queue (that still apply). But if > > > it's generally considered annoying (although I am pretty sure we > > > don't suffer from what's in the openstack thread), I don't object > > > and can ditch it completely. > > > > Well, their objection was core (by which they mean Maintainer) > > review and merge time, plus the interference to higher priority > > patches caused by mismerges. I was actually thinking a trivial > > tree might help them because it would offload all the mismerges and > > review and they only need do a real merge just before release > > stabilisation. > > > > > > > > The thing is that such patches will keep coming anyway, and I > > > think they have the value (although the priority is really lower > > > than other changes of course). I still believe that having > > > greppable comments, for example, is nice to have. > > > > Well, we tend to veto changes to old drivers in various subsystems > > anyway (having been burned by the this is only a trivial change and > > then finding out six months later that the driver is broken). > > > > Trivial changes seem to fall broadly into three categories: > > > > 1. spelling fixes > > 2. whitespace changes (I ran checkpatch.pl on your file and it > > returned > > these issues). > > 3. pattern imposition (we now have a new API for this so lets > > change > > all prior open coded incarnations) > > 4. trivial pattern fixes (things like replacing if(x) kfree(x); > > with > > kfree(x);) > > > > I don't want to open the whole spelling/whitespace can of worms, > > but perhaps we could have a more meaningful discussion about the > > pattern based issues ... for instance if we agree it's useful and > > coccinelle can do it, then tree wide replacement at -rc1 might be a > > better solution than ad-hoc application of hundreds of patches. > > Do you suggest one big patch, that goes to who? Or lots of little > patches that go out at once to the individual maintainers of the > affected code? I was actually thinking we validate the script and if there are no problems, apply it at -rc1 ... so effectively one big patch. What actually gets applied (script or big patch) would be up to Linus ... he's the one that makes the -rc1 changes. However, if we agree a curation path for the script, the application could be done by Jíři as a pull from the trivial tree (unless Linus wanted to do it himself or someone else wanted to manage this). James ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-09 16:56 ` James Bottomley @ 2017-10-09 17:04 ` Joe Perches 2017-10-11 18:51 ` Jani Nikula 1 sibling, 0 replies; 42+ messages in thread From: Joe Perches @ 2017-10-09 17:04 UTC (permalink / raw) To: James Bottomley, Julia Lawall; +Cc: ksummit-discuss On Mon, 2017-10-09 at 09:56 -0700, James Bottomley wrote: > I was actually thinking we validate the script That's the hard part. Completeness and correctness are non trivial. > and if there are no problems, apply it at -rc1 I also think that might be the best mechanism. > However, if we agree a > curation path for the script, the application could be done by Jíři as > a pull from the trivial tree (unless Linus wanted to do it himself or > someone else wanted to manage this). Perhaps a kbuild robot variant could be utilized here. Many changes should produce no object code differences and validation of the correctness of the changes might be better done using compilation comparison tools. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-09 16:56 ` James Bottomley 2017-10-09 17:04 ` Joe Perches @ 2017-10-11 18:51 ` Jani Nikula 2017-10-12 10:03 ` Daniel Vetter 2017-10-16 14:12 ` James Bottomley 1 sibling, 2 replies; 42+ messages in thread From: Jani Nikula @ 2017-10-11 18:51 UTC (permalink / raw) To: James Bottomley, Julia Lawall; +Cc: ksummit-discuss On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: >> Do you suggest one big patch, that goes to who? Or lots of little >> patches that go out at once to the individual maintainers of the >> affected code? > > I was actually thinking we validate the script and if there are no > problems, apply it at -rc1 ... so effectively one big patch. By -rc1 we (drm in general, drm/i915 in particular) will already have accumulated easily 4-5 weeks' worth of commits for the *next* merge window. Applying treewide stuff to Linus' tree at -rc1 forces a backmerge and potentially conflicts galore I'm not particularly thrilled about. I'd much rather see the patches to our driver come through our tree, and we generally deal with them without a fuss. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-11 18:51 ` Jani Nikula @ 2017-10-12 10:03 ` Daniel Vetter 2017-10-16 14:12 ` James Bottomley 1 sibling, 0 replies; 42+ messages in thread From: Daniel Vetter @ 2017-10-12 10:03 UTC (permalink / raw) To: Jani Nikula; +Cc: James Bottomley, ksummit-discuss On Wed, Oct 11, 2017 at 8:51 PM, Jani Nikula <jani.nikula@intel.com> wrote: > On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: >> On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: >>> Do you suggest one big patch, that goes to who? Or lots of little >>> patches that go out at once to the individual maintainers of the >>> affected code? >> >> I was actually thinking we validate the script and if there are no >> problems, apply it at -rc1 ... so effectively one big patch. > > By -rc1 we (drm in general, drm/i915 in particular) will already have > accumulated easily 4-5 weeks' worth of commits for the *next* merge > window. Applying treewide stuff to Linus' tree at -rc1 forces a > backmerge and potentially conflicts galore I'm not particularly thrilled > about. I'd much rather see the patches to our driver come through our > tree, and we generally deal with them without a fuss. And it's not just the development that's already queued, there's tons of patch series in developer trees that need to be rebased too. Doing treewide stuff at -rc1 is as disruptive as any other time for developers overall, it only optimizes the disruption in Linus repo. The other reason I'm not too fond of doing treewide stuff as one huge patch is that those cocci patches are perfect newbie fodder for their first patch. Of course once a refactor has tappererd of it's good to do one final push, but not always and consistently. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-11 18:51 ` Jani Nikula 2017-10-12 10:03 ` Daniel Vetter @ 2017-10-16 14:12 ` James Bottomley 2017-10-16 14:25 ` Jani Nikula 2017-10-16 18:52 ` Mark Brown 1 sibling, 2 replies; 42+ messages in thread From: James Bottomley @ 2017-10-16 14:12 UTC (permalink / raw) To: Jani Nikula, Julia Lawall; +Cc: ksummit-discuss On Wed, 2017-10-11 at 21:51 +0300, Jani Nikula wrote: > On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnersh > ip.com> wrote: > > > > On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: > > > > > > Do you suggest one big patch, that goes to who? Or lots of > > > little > > > patches that go out at once to the individual maintainers of the > > > affected code? > > > > I was actually thinking we validate the script and if there are no > > problems, apply it at -rc1 ... so effectively one big patch. > > By -rc1 we (drm in general, drm/i915 in particular) will already have > accumulated easily 4-5 weeks' worth of commits for the *next* merge > window. Applying treewide stuff to Linus' tree at -rc1 forces a > backmerge and potentially conflicts galore If we're applying a semantic patch script (and we've verified it works well enough to use the script on the -rc1 main tree), couldn't you simply apply it to your tree at the same time? James > I'm not particularly thrilled about. I'd much rather see the patches > to our driver come through our tree, and we generally deal with them > without a fuss. > > BR, > Jani. > > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-16 14:12 ` James Bottomley @ 2017-10-16 14:25 ` Jani Nikula 2017-10-16 16:07 ` Joe Perches 2017-10-16 18:52 ` Mark Brown 1 sibling, 1 reply; 42+ messages in thread From: Jani Nikula @ 2017-10-16 14:25 UTC (permalink / raw) To: James Bottomley, Julia Lawall; +Cc: ksummit-discuss On Mon, 16 Oct 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Wed, 2017-10-11 at 21:51 +0300, Jani Nikula wrote: >> On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnersh >> ip.com> wrote: >> > >> > On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: >> > > >> > > Do you suggest one big patch, that goes to who? Or lots of >> > > little >> > > patches that go out at once to the individual maintainers of the >> > > affected code? >> > >> > I was actually thinking we validate the script and if there are no >> > problems, apply it at -rc1 ... so effectively one big patch. >> >> By -rc1 we (drm in general, drm/i915 in particular) will already have >> accumulated easily 4-5 weeks' worth of commits for the *next* merge >> window. Applying treewide stuff to Linus' tree at -rc1 forces a >> backmerge and potentially conflicts galore > > If we're applying a semantic patch script (and we've verified it works > well enough to use the script on the -rc1 main tree), couldn't you > simply apply it to your tree at the same time? If we did, the fixes would show up in a later kernel release. Which is just fine for us. In other words, just let subsystems and drivers handle this as they see fit? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-16 14:25 ` Jani Nikula @ 2017-10-16 16:07 ` Joe Perches 2017-10-17 8:34 ` Jani Nikula 0 siblings, 1 reply; 42+ messages in thread From: Joe Perches @ 2017-10-16 16:07 UTC (permalink / raw) To: Jani Nikula, James Bottomley, Julia Lawall; +Cc: ksummit-discuss On Mon, 2017-10-16 at 17:25 +0300, Jani Nikula wrote: > On Mon, 16 Oct 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > On Wed, 2017-10-11 at 21:51 +0300, Jani Nikula wrote: > > > On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnersh > > > ip.com> wrote: > > > > > > > > On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: > > > > > > > > > > Do you suggest one big patch, that goes to who? Or lots of > > > > > little > > > > > patches that go out at once to the individual maintainers of the > > > > > affected code? > > > > > > > > I was actually thinking we validate the script and if there are no > > > > problems, apply it at -rc1 ... so effectively one big patch. > > > > > > By -rc1 we (drm in general, drm/i915 in particular) will already have > > > accumulated easily 4-5 weeks' worth of commits for the *next* merge > > > window. Applying treewide stuff to Linus' tree at -rc1 forces a > > > backmerge and potentially conflicts galore > > > > If we're applying a semantic patch script (and we've verified it works > > well enough to use the script on the -rc1 main tree), couldn't you > > simply apply it to your tree at the same time? > > If we did, the fixes would show up in a later kernel release. Which is > just fine for us. In other words, just let subsystems and drivers handle > this as they see fit? Scheduling and acceptance rates are the issue. Also some scripted patches require complete treewide application to allow things like API changes. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-16 16:07 ` Joe Perches @ 2017-10-17 8:34 ` Jani Nikula 2017-10-18 1:27 ` Joe Perches 0 siblings, 1 reply; 42+ messages in thread From: Jani Nikula @ 2017-10-17 8:34 UTC (permalink / raw) To: Joe Perches, James Bottomley, Julia Lawall; +Cc: ksummit-discuss On Mon, 16 Oct 2017, Joe Perches <joe@perches.com> wrote: > On Mon, 2017-10-16 at 17:25 +0300, Jani Nikula wrote: >> On Mon, 16 Oct 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: >> > On Wed, 2017-10-11 at 21:51 +0300, Jani Nikula wrote: >> > > On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnersh >> > > ip.com> wrote: >> > > > >> > > > On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: >> > > > > >> > > > > Do you suggest one big patch, that goes to who? Or lots of >> > > > > little >> > > > > patches that go out at once to the individual maintainers of the >> > > > > affected code? >> > > > >> > > > I was actually thinking we validate the script and if there are no >> > > > problems, apply it at -rc1 ... so effectively one big patch. >> > > >> > > By -rc1 we (drm in general, drm/i915 in particular) will already have >> > > accumulated easily 4-5 weeks' worth of commits for the *next* merge >> > > window. Applying treewide stuff to Linus' tree at -rc1 forces a >> > > backmerge and potentially conflicts galore >> > >> > If we're applying a semantic patch script (and we've verified it works >> > well enough to use the script on the -rc1 main tree), couldn't you >> > simply apply it to your tree at the same time? >> >> If we did, the fixes would show up in a later kernel release. Which is >> just fine for us. In other words, just let subsystems and drivers handle >> this as they see fit? > > Scheduling and acceptance rates are the issue. > > Also some scripted patches require complete treewide > application to allow things like API changes. As described in https://lwn.net/Articles/735468/ we have a pretty extensive and growing CI system in place. We don't apply a single patch without a pre-merge green light from CI, no exceptions. I take issue with applying any patches to our driver that didn't go through our CI first, let alone bypassing our repositories. If an API change requires a flag day treewide change in a 15M+ line hierarchically developed codebase, you're just plain doing it wrong. Please just let subsystems and drivers handle this as they see fit, and queue changes via their trees. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-17 8:34 ` Jani Nikula @ 2017-10-18 1:27 ` Joe Perches 2017-10-18 10:41 ` Jani Nikula 0 siblings, 1 reply; 42+ messages in thread From: Joe Perches @ 2017-10-18 1:27 UTC (permalink / raw) To: Jani Nikula, James Bottomley, Julia Lawall; +Cc: ksummit-discuss On Tue, 2017-10-17 at 11:34 +0300, Jani Nikula wrote: > On Mon, 16 Oct 2017, Joe Perches <joe@perches.com> wrote: > > On Mon, 2017-10-16 at 17:25 +0300, Jani Nikula wrote: > > > On Mon, 16 Oct 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > On Wed, 2017-10-11 at 21:51 +0300, Jani Nikula wrote: > > > > > On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnersh > > > > > ip.com> wrote: > > > > > > > > > > > > On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: > > > > > > > > > > > > > > Do you suggest one big patch, that goes to who? Or lots of > > > > > > > little > > > > > > > patches that go out at once to the individual maintainers of the > > > > > > > affected code? > > > > > > > > > > > > I was actually thinking we validate the script and if there are no > > > > > > problems, apply it at -rc1 ... so effectively one big patch. > > > > > > > > > > By -rc1 we (drm in general, drm/i915 in particular) will already have > > > > > accumulated easily 4-5 weeks' worth of commits for the *next* merge > > > > > window. Applying treewide stuff to Linus' tree at -rc1 forces a > > > > > backmerge and potentially conflicts galore > > > > > > > > If we're applying a semantic patch script (and we've verified it works > > > > well enough to use the script on the -rc1 main tree), couldn't you > > > > simply apply it to your tree at the same time? > > > > > > If we did, the fixes would show up in a later kernel release. Which is > > > just fine for us. In other words, just let subsystems and drivers handle > > > this as they see fit? > > > > Scheduling and acceptance rates are the issue. > > > > Also some scripted patches require complete treewide > > application to allow things like API changes. > > As described in https://lwn.net/Articles/735468/ we have a pretty > extensive and growing CI system in place. We don't apply a single patch > without a pre-merge green light from CI, no exceptions. I take issue > with applying any patches to our driver that didn't go through our CI > first, let alone bypassing our repositories. > > If an API change requires a flag day treewide change in a 15M+ line > hierarchically developed codebase, you're just plain doing it wrong. THe size of the codebase is not particularly relevant and that's simply not always possible. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-18 1:27 ` Joe Perches @ 2017-10-18 10:41 ` Jani Nikula 0 siblings, 0 replies; 42+ messages in thread From: Jani Nikula @ 2017-10-18 10:41 UTC (permalink / raw) To: Joe Perches, James Bottomley, Julia Lawall; +Cc: ksummit-discuss On Tue, 17 Oct 2017, Joe Perches <joe@perches.com> wrote: > On Tue, 2017-10-17 at 11:34 +0300, Jani Nikula wrote: >> On Mon, 16 Oct 2017, Joe Perches <joe@perches.com> wrote: >> > On Mon, 2017-10-16 at 17:25 +0300, Jani Nikula wrote: >> > > On Mon, 16 Oct 2017, James Bottomley <James.Bottomley@HansenPartnership.com> wrote: >> > > > On Wed, 2017-10-11 at 21:51 +0300, Jani Nikula wrote: >> > > > > On Mon, 09 Oct 2017, James Bottomley <James.Bottomley@HansenPartnersh >> > > > > ip.com> wrote: >> > > > > > >> > > > > > On Mon, 2017-10-09 at 18:49 +0200, Julia Lawall wrote: >> > > > > > > >> > > > > > > Do you suggest one big patch, that goes to who? Or lots of >> > > > > > > little >> > > > > > > patches that go out at once to the individual maintainers of the >> > > > > > > affected code? >> > > > > > >> > > > > > I was actually thinking we validate the script and if there are no >> > > > > > problems, apply it at -rc1 ... so effectively one big patch. >> > > > > >> > > > > By -rc1 we (drm in general, drm/i915 in particular) will already have >> > > > > accumulated easily 4-5 weeks' worth of commits for the *next* merge >> > > > > window. Applying treewide stuff to Linus' tree at -rc1 forces a >> > > > > backmerge and potentially conflicts galore >> > > > >> > > > If we're applying a semantic patch script (and we've verified it works >> > > > well enough to use the script on the -rc1 main tree), couldn't you >> > > > simply apply it to your tree at the same time? >> > > >> > > If we did, the fixes would show up in a later kernel release. Which is >> > > just fine for us. In other words, just let subsystems and drivers handle >> > > this as they see fit? >> > >> > Scheduling and acceptance rates are the issue. >> > >> > Also some scripted patches require complete treewide >> > application to allow things like API changes. >> >> As described in https://lwn.net/Articles/735468/ we have a pretty >> extensive and growing CI system in place. We don't apply a single patch >> without a pre-merge green light from CI, no exceptions. I take issue >> with applying any patches to our driver that didn't go through our CI >> first, let alone bypassing our repositories. >> >> If an API change requires a flag day treewide change in a 15M+ line >> hierarchically developed codebase, you're just plain doing it wrong. > > THe size of the codebase is not particularly relevant and Sure it is. It translates to the amount of people and subsystems and the pain you're causing them. > that's simply not always possible. That something is not always possible is not a reason to change the usual process to cater for the rare outlier case. Making it easier to do treewide changes encourages people to do just that, and discourages them from finding the ways to not cause trouble to subsystems. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-16 14:12 ` James Bottomley 2017-10-16 14:25 ` Jani Nikula @ 2017-10-16 18:52 ` Mark Brown 1 sibling, 0 replies; 42+ messages in thread From: Mark Brown @ 2017-10-16 18:52 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss [-- Attachment #1: Type: text/plain, Size: 789 bytes --] On Mon, Oct 16, 2017 at 07:12:55AM -0700, James Bottomley wrote: > On Wed, 2017-10-11 at 21:51 +0300, Jani Nikula wrote: > > By -rc1 we (drm in general, drm/i915 in particular) will already have > > accumulated easily 4-5 weeks' worth of commits for the *next* merge > > window. Applying treewide stuff to Linus' tree at -rc1 forces a > > backmerge and potentially conflicts galore > If we're applying a semantic patch script (and we've verified it works > well enough to use the script on the -rc1 main tree), couldn't you > simply apply it to your tree at the same time? git doesn't do the best job figuring out that the same change was made in two different commits so you still end up with the conflicts. It's much easier if we can just get changes in through the maintainer tree. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-09 16:37 ` James Bottomley 2017-10-09 16:47 ` Joe Perches 2017-10-09 16:49 ` Julia Lawall @ 2017-10-10 8:53 ` Jiri Kosina 2 siblings, 0 replies; 42+ messages in thread From: Jiri Kosina @ 2017-10-10 8:53 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit-discuss On Mon, 9 Oct 2017, James Bottomley wrote: > Trivial changes seem to fall broadly into three categories: > [ ... snip ... ] > 2. whitespace changes (I ran checkpatch.pl on your file and it returned > these issues). Just to be clear on this -- I'm not taking such patches through trivial.git. > I don't want to open the whole spelling/whitespace can of worms, but > perhaps we could have a more meaningful discussion about the pattern > based issues ... for instance if we agree it's useful and coccinelle > can do it, then tree wide replacement at -rc1 might be a better > solution than ad-hoc application of hundreds of patches. Agreed, and I think Linus did this several times in the past and has no issues with doing so. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-06 15:27 ` James Bottomley ` (2 preceding siblings ...) 2017-10-09 15:54 ` Jiri Kosina @ 2017-10-24 23:03 ` Kees Cook 2017-10-24 23:41 ` Joe Perches 3 siblings, 1 reply; 42+ messages in thread From: Kees Cook @ 2017-10-24 23:03 UTC (permalink / raw) To: James Bottomley; +Cc: ksummit On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: >> Appendix: Other topics that were brought up >> [...] >> Developing across multiple areas of the kernel > > I've got a couple of extra possibilities > [...] > 2) Trivial patches (again). Given that the "trivial patches" topic's discussion ended up boiling down to a discussion about developing across multiple areas of the kernel, maybe we should make space for a "tree-wide changes" discussion? Even after the earlier thread about it, I tripped all over this in the last couple months while doing timer conversions, so I would at least have some more strong opinions on the subject. ;) -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-24 23:03 ` Kees Cook @ 2017-10-24 23:41 ` Joe Perches 2017-10-25 0:54 ` Kees Cook 0 siblings, 1 reply; 42+ messages in thread From: Joe Perches @ 2017-10-24 23:41 UTC (permalink / raw) To: Kees Cook, James Bottomley; +Cc: ksummit On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: > On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > > > Appendix: Other topics that were brought up > > > [...] > > > Developing across multiple areas of the kernel > > > > I've got a couple of extra possibilities > > [...] > > 2) Trivial patches (again). > > Given that the "trivial patches" topic's discussion ended up boiling > down to a discussion about developing across multiple areas of the > kernel, maybe we should make space for a "tree-wide changes" > discussion? Even after the earlier thread about it, I tripped all over > this in the last couple months while doing timer conversions, so I > would at least have some more strong opinions on the subject. ;) It's a ripe area (like months old limburger cheese) for discussion. There's currently no good way to do tree-wide changes. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-24 23:41 ` Joe Perches @ 2017-10-25 0:54 ` Kees Cook 2017-10-25 4:21 ` Julia Lawall ` (5 more replies) 0 siblings, 6 replies; 42+ messages in thread From: Kees Cook @ 2017-10-25 0:54 UTC (permalink / raw) To: Joe Perches; +Cc: James Bottomley, ksummit On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: > On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: >> On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley >> <James.Bottomley@hansenpartnership.com> wrote: >> > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: >> > > Appendix: Other topics that were brought up >> > > [...] >> > > Developing across multiple areas of the kernel >> > >> > I've got a couple of extra possibilities >> > [...] >> > 2) Trivial patches (again). >> >> Given that the "trivial patches" topic's discussion ended up boiling >> down to a discussion about developing across multiple areas of the >> kernel, maybe we should make space for a "tree-wide changes" >> discussion? Even after the earlier thread about it, I tripped all over >> this in the last couple months while doing timer conversions, so I >> would at least have some more strong opinions on the subject. ;) > > It's a ripe area (like months old limburger cheese) for discussion. > > There's currently no good way to do tree-wide changes. Some things stand out for me: 1) I would like a standard way to distinguish patch submissions between "please ack this (it's going into my tree)" and "please apply this to your tree." I have tried post-"---"-line notes, cover letter notes, etc, and maintainers still miss it. It can sometimes be very disruptive (to both me and the maintainer) to have a maintainer take a patch out of the middle of a series that was intending to land via a different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or "[MY-TREE]" or something? 2) When you have a 200+ patch series, it is outrageously difficult to figure out where to send things. The MAINTAINERS file is at best an approximation. I use a subset of the get_maintainer output plus my own parsing of MAINTAINERS to try to organize patches. The results tend to be somewhat okay, but there are still bouncing addresses, or MIA maintainers. And then a patch isn't met with silence, it might get met with an "Ack", but no attention from a committer. Having a representation of the "tree" of maintainership would be much more helpful. In other words, for every section with an "M:" line, also something "U:" ("upstream"?) that indicates either another section or a person that is the "upstream" for that maintainer. This would allow for a sane set of "Cc"s not based on git log guessing, and provide an obvious "escalation" path in the face of silence (or uncommitted Acks). 3) Maintainers (sanely) balk at getting a massive dump of patches all at once. It would be nice to document "batch limits" in the MAINTAINERS file too. (For example, davem asked me after I sent him 60 patches in a single day if I could please limit the batch size to 12 between commits (i.e. only send the next batch after the prior batch has been applied/processed). "H:"ow many at once, maybe? 4) I've taken from the example of akpm and -tip commits to include "Cc:" lines before my S-o-b. This helps me record who should be notified about patches when emailing them, but it is a bit bulky. What are best practices here? 5) When sending a large series, it's infeasible to either repeat the massive cover letter (or patch #1) description in every follow-up patch, or to Cc everyone to the 0/N cover letter. Suggestions from some people have been, "I don't care, CC me to everything" and "OMG, don't CC me about all these other subsystem patches I don't care about". My understanding was that everyone should be subscribed to lkml, and it acts as the common thread archive, so when a maintainer gets a few patches out of a /N series, they can trivially go look at the 0/N patch for more context. However, I've regularly gotten "please CC me on the 0/N patch" which puts me back to square one. What should be the definitive way to deal with this? (And if there's no one way, do we have to include CC preferences in MAINTAINERS on a per-person basis?) 6) Dealing with silence. This is not unique to other patch submissions, but silence can block an API conversion, or feature coverage. I've ultimately just used my best judgement and carried dependent patches in my own tree if they go ignored for too long. It seems to be implicitly okay for some contributors to do this (and I tenuously count myself in that list now), but I think it'd be nice to have some kind of more well defined hierarchy of escalation (see #2) that doesn't end in silence or a catch-22 (e.g. while I tend to include akpm in my escalation list, akpm has (correctly) wanted VFS changes to go through Al, but I only went to akpm because Al was busy, so then I'm stuck without a way forward). Now, I realize this is somewhat "by design" (see #3): if a maintainer is overloaded, we don't want things going unreviewed into the kernel. I think we need a bottleneck-detection process, so we can more quickly deal with maintainer silence. That said, it's not like people are falling over themselves to offer to share maintainership of areas that get saturated, so ... I don't have even a straw-man suggestion for this one... 7) As seen in this topic thread, some maintainers absolutely do not want stuff landing from "outside" their tree. This doesn't seem feasible at all, and we do regular treewide conversions at -rc1. It would be nice to declare, explicitly, "you need to deal with external changes to your tree when you merge -rc1". I thought this was already an implicit understanding. (Though in fact, sfr suggested to me that maintainer trees should be based at least on -rc2, and I've seen some maintainers continue to merge -rc releases, which I thought created ugly merge commit hell when sending a pull request to Linus later, but now I've digressed.) 8) Whatever the results of this, I'd really like to get _something_ documented as an adjunct to the SubmittingPatches document. Maybe named TreewideChanges or MultiSubsystemChanges or something. I'm happy to DO this documentation, I just want to have consensus on the ways to do things, and then I can point maintainers to the document to explain why I did something the way I did. That's all that jumps to mind at the moment... -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 0:54 ` Kees Cook @ 2017-10-25 4:21 ` Julia Lawall 2017-10-25 4:29 ` Joe Perches 2017-10-25 6:05 ` Martin K. Petersen ` (4 subsequent siblings) 5 siblings, 1 reply; 42+ messages in thread From: Julia Lawall @ 2017-10-25 4:21 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit On Tue, 24 Oct 2017, Kees Cook wrote: > On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: > > On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: > >> On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley > >> <James.Bottomley@hansenpartnership.com> wrote: > >> > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > >> > > Appendix: Other topics that were brought up > >> > > [...] > >> > > Developing across multiple areas of the kernel > >> > > >> > I've got a couple of extra possibilities > >> > [...] > >> > 2) Trivial patches (again). > >> > >> Given that the "trivial patches" topic's discussion ended up boiling > >> down to a discussion about developing across multiple areas of the > >> kernel, maybe we should make space for a "tree-wide changes" > >> discussion? Even after the earlier thread about it, I tripped all over > >> this in the last couple months while doing timer conversions, so I > >> would at least have some more strong opinions on the subject. ;) > > > > It's a ripe area (like months old limburger cheese) for discussion. > > > > There's currently no good way to do tree-wide changes. > > Some things stand out for me: > > 1) I would like a standard way to distinguish patch submissions > between "please ack this (it's going into my tree)" and "please apply > this to your tree." I have tried post-"---"-line notes, cover letter > notes, etc, and maintainers still miss it. It can sometimes be very > disruptive (to both me and the maintainer) to have a maintainer take a > patch out of the middle of a series that was intending to land via a > different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or > "[MY-TREE]" or something? Nothing is going into my tree, since I don't have one. Most changes I do are independent, so I hope that the recipient of the patch will take it. I only send such patches to the maintainers of the patch, with the cover letter CCd to some superset of all relevant mailing lists. I don't really know what to do with dependent patches. Sending all patches to the union of all maintainers can lead to a huge CC list. In that case, I would have to hope that someone who step up to pick up the patch, perhaps the person who is maintaining the dependency part, or when someone asked for the change, the person whoc asked for it in the first place. > > 2) When you have a 200+ patch series, it is outrageously difficult to > figure out where to send things. The MAINTAINERS file is at best an > approximation. I use a subset of the get_maintainer output plus my own > parsing of MAINTAINERS to try to organize patches. The results tend to > be somewhat okay, but there are still bouncing addresses, or MIA > maintainers. And then a patch isn't met with silence, it might get met > with an "Ack", but no attention from a committer. Having a > representation of the "tree" of maintainership would be much more > helpful. In other words, for every section with an "M:" line, also > something "U:" ("upstream"?) that indicates either another section or > a person that is the "upstream" for that maintainer. This would allow > for a sane set of "Cc"s not based on git log guessing, and provide an > obvious "escalation" path in the face of silence (or uncommitted > Acks). I send things to maintainers and mailing lists only. My hypothesis is that the things affected by treewide canges are typically not things that other developers feel a strong ownership of. > 8) Whatever the results of this, I'd really like to get _something_ > documented as an adjunct to the SubmittingPatches document. Maybe > named TreewideChanges or MultiSubsystemChanges or something. I'm happy > to DO this documentation, I just want to have consensus on the ways to > do things, and then I can point maintainers to the document to explain > why I did something the way I did. Documentation would indeed be very helpful. Another question is how a patch series should be cut up? Some people have complained about it being cut up by file, if the changes are all going into the same tree. And of course there are complaints if files from two trees are mixed into a single patch. I normally cut them up by unique set of maintainers, but sometimes quite different files get put into a single patch, or files that are very similar get split between different patches just because there is one extra maintainer on one of them. Would it be better to follow the T: entry in MAINTAINERS, if there is one? That information doesn't seem to be complete. julia ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 4:21 ` Julia Lawall @ 2017-10-25 4:29 ` Joe Perches 2017-10-25 4:36 ` Julia Lawall 0 siblings, 1 reply; 42+ messages in thread From: Joe Perches @ 2017-10-25 4:29 UTC (permalink / raw) To: Julia Lawall, Kees Cook; +Cc: James Bottomley, ksummit On Wed, 2017-10-25 at 06:21 +0200, Julia Lawall wrote: > > On Tue, 24 Oct 2017, Kees Cook wrote: > > > On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: > > > On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: > > > > On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley > > > > <James.Bottomley@hansenpartnership.com> wrote: > > > > > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > > > > > > Appendix: Other topics that were brought up > > > > > > [...] > > > > > > Developing across multiple areas of the kernel > > > > > > > > > > I've got a couple of extra possibilities > > > > > [...] > > > > > 2) Trivial patches (again). > > > > > > > > Given that the "trivial patches" topic's discussion ended up boiling > > > > down to a discussion about developing across multiple areas of the > > > > kernel, maybe we should make space for a "tree-wide changes" > > > > discussion? Even after the earlier thread about it, I tripped all over > > > > this in the last couple months while doing timer conversions, so I > > > > would at least have some more strong opinions on the subject. ;) > > > > > > It's a ripe area (like months old limburger cheese) for discussion. > > > > > > There's currently no good way to do tree-wide changes. > > > > Some things stand out for me: > > > > 1) I would like a standard way to distinguish patch submissions > > between "please ack this (it's going into my tree)" and "please apply > > this to your tree." I have tried post-"---"-line notes, cover letter > > notes, etc, and maintainers still miss it. It can sometimes be very > > disruptive (to both me and the maintainer) to have a maintainer take a > > patch out of the middle of a series that was intending to land via a > > different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or > > "[MY-TREE]" or something? > > Nothing is going into my tree, since I don't have one. Me too. > Most changes I do > are independent, so I hope that the recipient of the patch will take it. And generally I will only send such a patch series once. > I only send such patches to the maintainers of the patch, with the cover > letter CCd to some superset of all relevant mailing lists. I don't really > know what to do with dependent patches. Sending all patches to the union > of all maintainers can lead to a huge CC list. In that case, I would have > to hope that someone who step up to pick up the patch, perhaps the person > who is maintaining the dependency part, or when someone asked for the > change, the person whoc asked for it in the first place. I generally send treewide patches by second-level directory, third if it's drivers/net/ > > 2) When you have a 200+ patch series, it is outrageously difficult to > > figure out where to send things. More like impossible. > > This would allow > > for a sane set of "Cc"s not based on git log guessing, and provide an > > obvious "escalation" path in the face of silence (or uncommitted > > Acks). More likely a treewide maintainer for the obvious/trivial but acceptable would help more. > I send things to maintainers and mailing lists only. My hypothesis is > that the things affected by treewide canges are typically not things that > other developers feel a strong ownership of. Unfortunately, that's also the class of patches that no one cares much about. > > 8) Whatever the results of this, I'd really like to get _something_ > > documented as an adjunct to the SubmittingPatches document. Maybe > > named TreewideChanges or MultiSubsystemChanges or something. I'm happy > > to DO this documentation, I just want to have consensus on the ways to > > do things, and then I can point maintainers to the document to explain > > why I did something the way I did. > > Documentation would indeed be very helpful. > > Another question is how a patch series should be cut up? Some people have > complained about it being cut up by file, if the changes are all going > into the same tree. And of course there are complaints if files from two > trees are mixed into a single patch. I normally cut them up by unique set > of maintainers, but sometimes quite different files get put into a single > patch, or files that are very similar get split between different patches > just because there is one extra maintainer on one of them. Would it be > better to follow the T: entry in MAINTAINERS, if there is one? That > information doesn't seem to be complete. It's not and it's also incomplete when overlap of ownership occurs. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 4:29 ` Joe Perches @ 2017-10-25 4:36 ` Julia Lawall 0 siblings, 0 replies; 42+ messages in thread From: Julia Lawall @ 2017-10-25 4:36 UTC (permalink / raw) To: Joe Perches; +Cc: James Bottomley, ksummit On Tue, 24 Oct 2017, Joe Perches wrote: > On Wed, 2017-10-25 at 06:21 +0200, Julia Lawall wrote: > > > > On Tue, 24 Oct 2017, Kees Cook wrote: > > > > > On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: > > > > On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: > > > > > On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley > > > > > <James.Bottomley@hansenpartnership.com> wrote: > > > > > > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > > > > > > > Appendix: Other topics that were brought up > > > > > > > [...] > > > > > > > Developing across multiple areas of the kernel > > > > > > > > > > > > I've got a couple of extra possibilities > > > > > > [...] > > > > > > 2) Trivial patches (again). > > > > > > > > > > Given that the "trivial patches" topic's discussion ended up boiling > > > > > down to a discussion about developing across multiple areas of the > > > > > kernel, maybe we should make space for a "tree-wide changes" > > > > > discussion? Even after the earlier thread about it, I tripped all over > > > > > this in the last couple months while doing timer conversions, so I > > > > > would at least have some more strong opinions on the subject. ;) > > > > > > > > It's a ripe area (like months old limburger cheese) for discussion. > > > > > > > > There's currently no good way to do tree-wide changes. > > > > > > Some things stand out for me: > > > > > > 1) I would like a standard way to distinguish patch submissions > > > between "please ack this (it's going into my tree)" and "please apply > > > this to your tree." I have tried post-"---"-line notes, cover letter > > > notes, etc, and maintainers still miss it. It can sometimes be very > > > disruptive (to both me and the maintainer) to have a maintainer take a > > > patch out of the middle of a series that was intending to land via a > > > different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or > > > "[MY-TREE]" or something? > > > > Nothing is going into my tree, since I don't have one. > > Me too. > > > Most changes I do > > are independent, so I hope that the recipient of the patch will take it. > > And generally I will only send such a patch series once. Likewise. julia > > > I only send such patches to the maintainers of the patch, with the cover > > letter CCd to some superset of all relevant mailing lists. I don't really > > know what to do with dependent patches. Sending all patches to the union > > of all maintainers can lead to a huge CC list. In that case, I would have > > to hope that someone who step up to pick up the patch, perhaps the person > > who is maintaining the dependency part, or when someone asked for the > > change, the person whoc asked for it in the first place. > > I generally send treewide patches by second-level directory, > third if it's drivers/net/ > > > > 2) When you have a 200+ patch series, it is outrageously difficult to > > > figure out where to send things. > > More like impossible. > > > > This would allow > > > for a sane set of "Cc"s not based on git log guessing, and provide an > > > obvious "escalation" path in the face of silence (or uncommitted > > > Acks). > > More likely a treewide maintainer for the obvious/trivial but acceptable > would help more. > > > I send things to maintainers and mailing lists only. My hypothesis is > > that the things affected by treewide canges are typically not things that > > other developers feel a strong ownership of. > > Unfortunately, that's also the class of patches that no one cares much > about. > > > > 8) Whatever the results of this, I'd really like to get _something_ > > > documented as an adjunct to the SubmittingPatches document. Maybe > > > named TreewideChanges or MultiSubsystemChanges or something. I'm happy > > > to DO this documentation, I just want to have consensus on the ways to > > > do things, and then I can point maintainers to the document to explain > > > why I did something the way I did. > > > > Documentation would indeed be very helpful. > > > > Another question is how a patch series should be cut up? Some people have > > complained about it being cut up by file, if the changes are all going > > into the same tree. And of course there are complaints if files from two > > trees are mixed into a single patch. I normally cut them up by unique set > > of maintainers, but sometimes quite different files get put into a single > > patch, or files that are very similar get split between different patches > > just because there is one extra maintainer on one of them. Would it be > > better to follow the T: entry in MAINTAINERS, if there is one? That > > information doesn't seem to be complete. > > It's not and it's also incomplete when overlap of ownership occurs. > > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 0:54 ` Kees Cook 2017-10-25 4:21 ` Julia Lawall @ 2017-10-25 6:05 ` Martin K. Petersen 2017-10-25 6:55 ` Kees Cook 2017-10-25 6:45 ` Frank Rowand ` (3 subsequent siblings) 5 siblings, 1 reply; 42+ messages in thread From: Martin K. Petersen @ 2017-10-25 6:05 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit Kees, > 3) Maintainers (sanely) balk at getting a massive dump of patches all > at once. It would be nice to document "batch limits" in the > MAINTAINERS file too. (For example, davem asked me after I sent him 60 > patches in a single day if I could please limit the batch size to 12 > between commits (i.e. only send the next batch after the prior batch > has been applied/processed). "H:"ow many at once, maybe? I generally think 10-15 patches are reasonable. But it also depends on the patch size and the nature of the changes. For me, the deciding factors are: 1. What's the point of this series? 2. Can I complete review of this series within 30 minutes before my next concall. 3. Can I complete review of this series without my brain turning into complete mush. > 5) When sending a large series, it's infeasible to either repeat the > massive cover letter [...] My understanding was that everyone should > be subscribed to lkml, and it acts as the common thread archive, so > when a maintainer gets a few patches out of a /N series, they can > trivially go look at the 0/N patch for more context. First of all, as a subsystem maintainer I rely heavily on other people to review patches. Either individual driver maintainers or people with a vested interest in SCSI (enterprise distro developers). It's virtually impossible to entice people to review patches in the first place. Forcing people to go switch from their email context to go peruse the lkml archives in a web browser to decide whether a patch series is worth reviewing in the first place is a non-starter. People have really short attention spans. Realistically, reviews only happen when people see the mail in their inbox and they have N minutes to spare. After that point, your opportunity is essentially lost. If a reviewer has a particular interest in a file or area, they may tag it for later review. And then after a few days of working on something else they come back and realize they have no time this week and delete the series from their inbox so they don't feel bad about it over the weekend. As a subsystem maintainer, the burden then falls upon me. And if something has been collecting dust in patchwork for several weeks, there is absolutely no chance that I or anybody else will get to it. I'm reasonably sure that I'm the only person that ever visits the SCSI patchwork with the intent to clear out the queue. Consequently, the only way to revive interest is to resubmit. With a comprehensive cover letter (which, incidentally, it would be nice if patchwork would capture). -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 6:05 ` Martin K. Petersen @ 2017-10-25 6:55 ` Kees Cook 2017-10-25 7:34 ` Martin K. Petersen 0 siblings, 1 reply; 42+ messages in thread From: Kees Cook @ 2017-10-25 6:55 UTC (permalink / raw) To: Martin K. Petersen; +Cc: James Bottomley, ksummit On Tue, Oct 24, 2017 at 11:05 PM, Martin K. Petersen <martin.petersen@oracle.com> wrote: > Consequently, the only way to revive interest is to resubmit. With a > comprehensive cover letter (which, incidentally, it would be nice if > patchwork would capture). Oh, yes! I have repeatedly wanted this too (and maybe a way to select the entire series from the 0/N to make a bundle, instead of clicking each patch). -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 6:55 ` Kees Cook @ 2017-10-25 7:34 ` Martin K. Petersen 0 siblings, 0 replies; 42+ messages in thread From: Martin K. Petersen @ 2017-10-25 7:34 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit Kees, > Oh, yes! I have repeatedly wanted this too (and maybe a way to select > the entire series from the 0/N to make a bundle, instead of clicking > each patch). I believe the latter is in the pipeline. But it can't happen soon enough... -- Martin K. Petersen Oracle Linux Engineering ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 0:54 ` Kees Cook 2017-10-25 4:21 ` Julia Lawall 2017-10-25 6:05 ` Martin K. Petersen @ 2017-10-25 6:45 ` Frank Rowand 2017-10-25 7:56 ` Mark Brown ` (2 subsequent siblings) 5 siblings, 0 replies; 42+ messages in thread From: Frank Rowand @ 2017-10-25 6:45 UTC (permalink / raw) To: Kees Cook, Joe Perches; +Cc: James Bottomley, ksummit On 10/24/17 17:54, Kees Cook wrote: > On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: >> On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: >>> On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley >>> <James.Bottomley@hansenpartnership.com> wrote: >>>> On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: >>>>> Appendix: Other topics that were brought up >>>>> [...] >>>>> Developing across multiple areas of the kernel >>>> >>>> I've got a couple of extra possibilities >>>> [...] >>>> 2) Trivial patches (again). >>> >>> Given that the "trivial patches" topic's discussion ended up boiling >>> down to a discussion about developing across multiple areas of the >>> kernel, maybe we should make space for a "tree-wide changes" >>> discussion? Even after the earlier thread about it, I tripped all over >>> this in the last couple months while doing timer conversions, so I >>> would at least have some more strong opinions on the subject. ;) >> >> It's a ripe area (like months old limburger cheese) for discussion. >> >> There's currently no good way to do tree-wide changes. > > Some things stand out for me: < snip > > 3) Maintainers (sanely) balk at getting a massive dump of patches all > at once. It would be nice to document "batch limits" in the > MAINTAINERS file too. (For example, davem asked me after I sent him 60 > patches in a single day if I could please limit the batch size to 12 > between commits (i.e. only send the next batch after the prior batch > has been applied/processed). "H:"ow many at once, maybe? < snip > But patches sent to a list are not just for the maintainer. They are also for anyone else who may be affected or who may care to review the patches. Those other people have their own schedule issues. If you hold off sending a second patch set this week, then send it next week (when the maintainer once again has some bandwith), it is likely that someone other than the maintainer has time to look at that patche set this week, but may have no free time to do so next week. -Frank ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 0:54 ` Kees Cook ` (2 preceding siblings ...) 2017-10-25 6:45 ` Frank Rowand @ 2017-10-25 7:56 ` Mark Brown 2017-10-25 9:39 ` Laurent Pinchart 2017-10-31 19:19 ` Rob Herring 5 siblings, 0 replies; 42+ messages in thread From: Mark Brown @ 2017-10-25 7:56 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit [-- Attachment #1: Type: text/plain, Size: 1609 bytes --] On Tue, Oct 24, 2017 at 05:54:47PM -0700, Kees Cook wrote: > with an "Ack", but no attention from a committer. Having a > representation of the "tree" of maintainership would be much more > helpful. In other words, for every section with an "M:" line, also > something "U:" ("upstream"?) that indicates either another section or > a person that is the "upstream" for that maintainer. This would allow > for a sane set of "Cc"s not based on git log guessing, and provide an > obvious "escalation" path in the face of silence (or uncommitted > Acks). IME if you use all matching MAINTAINERS entries rather than the most exact one you'll usually find the upstream (though there are exceptions, including things like arm-soc which just isn't in MAINTAINERS at all). > 7) As seen in this topic thread, some maintainers absolutely do not > want stuff landing from "outside" their tree. This doesn't seem > feasible at all, and we do regular treewide conversions at -rc1. It > would be nice to declare, explicitly, "you need to deal with external > changes to your tree when you merge -rc1". I thought this was already > an implicit understanding. (Though in fact, sfr suggested to me that > maintainer trees should be based at least on -rc2, and I've seen some I think like a lot of these things this is a tradeoffs thing - sometimes everything will have to go in at once and we'll have to deal with it but it's better to at least try to coordinate with people's trees, if that's not possible it's annoying but understandable. It's more likely to be a problem when things just materialize without any warning. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 0:54 ` Kees Cook ` (3 preceding siblings ...) 2017-10-25 7:56 ` Mark Brown @ 2017-10-25 9:39 ` Laurent Pinchart 2017-10-31 19:19 ` Rob Herring 5 siblings, 0 replies; 42+ messages in thread From: Laurent Pinchart @ 2017-10-25 9:39 UTC (permalink / raw) To: ksummit-discuss; +Cc: James Bottomley Hi Kees, On Wednesday, 25 October 2017 03:54:47 EEST Kees Cook wrote: > On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: > > On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: > >> On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley wrote: > >>> On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: > >>>> Appendix: Other topics that were brought up > >>>> [...] > >>>> Developing across multiple areas of the kernel > >>> > >>> I've got a couple of extra possibilities > >>> [...] > >>> 2) Trivial patches (again). > >> > >> Given that the "trivial patches" topic's discussion ended up boiling > >> down to a discussion about developing across multiple areas of the > >> kernel, maybe we should make space for a "tree-wide changes" > >> discussion? Even after the earlier thread about it, I tripped all over > >> this in the last couple months while doing timer conversions, so I > >> would at least have some more strong opinions on the subject. ;) > > > > It's a ripe area (like months old limburger cheese) for discussion. > > > > There's currently no good way to do tree-wide changes. > > Some things stand out for me: > > 1) I would like a standard way to distinguish patch submissions > between "please ack this (it's going into my tree)" and "please apply > this to your tree." I have tried post-"---"-line notes, cover letter > notes, etc, and maintainers still miss it. It can sometimes be very > disruptive (to both me and the maintainer) to have a maintainer take a > patch out of the middle of a series that was intending to land via a > different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or > "[MY-TREE]" or something? When I receive patches from such series, I often assume (and often incorrectly it seems after reading this thread) that the submitter will want to merge the whole series through a single tree. I try to always ask when sending my ack whether I should take the patch in my tree or if it will be merged through another tree. This wastes bandwidth, and would be pretty painful for you if you had to tell 200 times maintainers to take the patches. I think documenting the expected default upstream path for tree-wide changes would help here. [snip] -- Regards, Laurent Pinchart ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-25 0:54 ` Kees Cook ` (4 preceding siblings ...) 2017-10-25 9:39 ` Laurent Pinchart @ 2017-10-31 19:19 ` Rob Herring 2017-10-31 19:28 ` Kees Cook 5 siblings, 1 reply; 42+ messages in thread From: Rob Herring @ 2017-10-31 19:19 UTC (permalink / raw) To: Kees Cook; +Cc: James Bottomley, ksummit On Tue, Oct 24, 2017 at 7:54 PM, Kees Cook <keescook@chromium.org> wrote: > On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: >> On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: >>> On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley >>> <James.Bottomley@hansenpartnership.com> wrote: >>> > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: >>> > > Appendix: Other topics that were brought up >>> > > [...] >>> > > Developing across multiple areas of the kernel >>> > >>> > I've got a couple of extra possibilities >>> > [...] >>> > 2) Trivial patches (again). >>> >>> Given that the "trivial patches" topic's discussion ended up boiling >>> down to a discussion about developing across multiple areas of the >>> kernel, maybe we should make space for a "tree-wide changes" >>> discussion? Even after the earlier thread about it, I tripped all over >>> this in the last couple months while doing timer conversions, so I >>> would at least have some more strong opinions on the subject. ;) >> >> It's a ripe area (like months old limburger cheese) for discussion. >> >> There's currently no good way to do tree-wide changes. > > Some things stand out for me: > > 1) I would like a standard way to distinguish patch submissions > between "please ack this (it's going into my tree)" and "please apply > this to your tree." I have tried post-"---"-line notes, cover letter > notes, etc, and maintainers still miss it. It can sometimes be very > disruptive (to both me and the maintainer) to have a maintainer take a > patch out of the middle of a series that was intending to land via a > different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or > "[MY-TREE]" or something? I've used To vs. Cc to distinguish that, but that seems to be not explicit enough. Perhaps a "Needs-Acked-by:" tag. That would have the advantage of being stored in the commit rather than having to be added when sending. It's also easy for the person needing to ack it to filter for it. The more we can automate the process from having a git branch of commits to sending mails, the less variation we have and the easier it will be for new people. > 2) When you have a 200+ patch series, it is outrageously difficult to > figure out where to send things. The MAINTAINERS file is at best an > approximation. I use a subset of the get_maintainer output plus my own > parsing of MAINTAINERS to try to organize patches. The results tend to > be somewhat okay, but there are still bouncing addresses, or MIA > maintainers. And then a patch isn't met with silence, it might get met > with an "Ack", but no attention from a committer. Having a > representation of the "tree" of maintainership would be much more > helpful. In other words, for every section with an "M:" line, also > something "U:" ("upstream"?) that indicates either another section or > a person that is the "upstream" for that maintainer. This would allow > for a sane set of "Cc"s not based on git log guessing, and provide an > obvious "escalation" path in the face of silence (or uncommitted > Acks). I think distinguishing between subsystem maintainers and maintainers of individual things (e.g. a driver) would be good. I think that's what you are saying. Ideally, that distinction would make it to the Cc list somehow. I usually add Cc's from get_maintainers.pl to commits, but then by the time I'm sending things I may not know who in the list has the upstream tree. The git log guessing is pretty useless for the purpose of Cc'ing people and should be off by default IMO. I've touched things tree wide a number of times and now get Cc'ed on things I've touched once 3 years ago. Rob ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [Ksummit-discuss] Maintainer's Summit Agenda Planning 2017-10-31 19:19 ` Rob Herring @ 2017-10-31 19:28 ` Kees Cook 0 siblings, 0 replies; 42+ messages in thread From: Kees Cook @ 2017-10-31 19:28 UTC (permalink / raw) To: Rob Herring; +Cc: James Bottomley, ksummit On Tue, Oct 31, 2017 at 12:19 PM, Rob Herring <robherring2@gmail.com> wrote: > On Tue, Oct 24, 2017 at 7:54 PM, Kees Cook <keescook@chromium.org> wrote: >> On Tue, Oct 24, 2017 at 4:41 PM, Joe Perches <joe@perches.com> wrote: >>> On Tue, 2017-10-24 at 16:03 -0700, Kees Cook wrote: >>>> On Fri, Oct 6, 2017 at 8:27 AM, James Bottomley >>>> <James.Bottomley@hansenpartnership.com> wrote: >>>> > On Thu, 2017-10-05 at 15:20 -0400, Theodore Ts'o wrote: >>>> > > Appendix: Other topics that were brought up >>>> > > [...] >>>> > > Developing across multiple areas of the kernel >>>> > >>>> > I've got a couple of extra possibilities >>>> > [...] >>>> > 2) Trivial patches (again). >>>> >>>> Given that the "trivial patches" topic's discussion ended up boiling >>>> down to a discussion about developing across multiple areas of the >>>> kernel, maybe we should make space for a "tree-wide changes" >>>> discussion? Even after the earlier thread about it, I tripped all over >>>> this in the last couple months while doing timer conversions, so I >>>> would at least have some more strong opinions on the subject. ;) >>> >>> It's a ripe area (like months old limburger cheese) for discussion. >>> >>> There's currently no good way to do tree-wide changes. >> >> Some things stand out for me: >> >> 1) I would like a standard way to distinguish patch submissions >> between "please ack this (it's going into my tree)" and "please apply >> this to your tree." I have tried post-"---"-line notes, cover letter >> notes, etc, and maintainers still miss it. It can sometimes be very >> disruptive (to both me and the maintainer) to have a maintainer take a >> patch out of the middle of a series that was intending to land via a >> different tree. Would "[ACK-PLEASE][PATCH]" be sufficient? Or >> "[MY-TREE]" or something? > > I've used To vs. Cc to distinguish that, but that seems to be not > explicit enough. Yeah, same for me. > Perhaps a "Needs-Acked-by:" tag. That would have the advantage of > being stored in the commit rather than having to be added when > sending. It's also easy for the person needing to ack it to filter for > it. The more we can automate the process from having a git branch of > commits to sending mails, the less variation we have and the easier it > will be for new people. I tend to be faced with not knowing which person I need for an Ack. :P The idea proposed at Kernel Summit was to add a new subject tag "Request for Ack", as: [RFACK][PATCH] subsystem: title... >> 2) When you have a 200+ patch series, it is outrageously difficult to >> figure out where to send things. The MAINTAINERS file is at best an >> approximation. I use a subset of the get_maintainer output plus my own >> parsing of MAINTAINERS to try to organize patches. The results tend to >> be somewhat okay, but there are still bouncing addresses, or MIA >> maintainers. And then a patch isn't met with silence, it might get met >> with an "Ack", but no attention from a committer. Having a >> representation of the "tree" of maintainership would be much more >> helpful. In other words, for every section with an "M:" line, also >> something "U:" ("upstream"?) that indicates either another section or >> a person that is the "upstream" for that maintainer. This would allow >> for a sane set of "Cc"s not based on git log guessing, and provide an >> obvious "escalation" path in the face of silence (or uncommitted >> Acks). > > I think distinguishing between subsystem maintainers and maintainers > of individual things (e.g. a driver) would be good. I think that's > what you are saying. Ideally, that distinction would make it to the Cc Yeah, exactly. And time times (wireless comes to mind) you have a couple levels of maintainers of the "individual thing" maintainers. > list somehow. I usually add Cc's from get_maintainers.pl to commits, > but then by the time I'm sending things I may not know who in the list > has the upstream tree. > > The git log guessing is pretty useless for the purpose of Cc'ing > people and should be off by default IMO. I've touched things tree wide > a number of times and now get Cc'ed on things I've touched once 3 > years ago. Yeah, I fear my inbox after timer conversions start landing... -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2017-10-31 19:28 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-05 19:20 [Ksummit-discuss] Maintainer's Summit Agenda Planning Theodore Ts'o 2017-10-05 20:13 ` Rafael J. Wysocki 2017-10-05 21:55 ` Jiri Kosina 2017-10-06 14:59 ` Takashi Iwai 2017-10-06 15:27 ` James Bottomley 2017-10-06 16:26 ` Josh Poimboeuf 2017-10-06 16:32 ` Jonathan Corbet 2017-10-06 16:51 ` Josh Poimboeuf 2017-10-06 16:56 ` James Bottomley 2017-10-06 17:16 ` Josh Poimboeuf 2017-10-06 20:11 ` Linus Walleij 2017-10-09 8:13 ` Mark Brown 2017-10-09 15:54 ` Jiri Kosina 2017-10-09 16:37 ` James Bottomley 2017-10-09 16:47 ` Joe Perches 2017-10-09 16:49 ` Julia Lawall 2017-10-09 16:56 ` James Bottomley 2017-10-09 17:04 ` Joe Perches 2017-10-11 18:51 ` Jani Nikula 2017-10-12 10:03 ` Daniel Vetter 2017-10-16 14:12 ` James Bottomley 2017-10-16 14:25 ` Jani Nikula 2017-10-16 16:07 ` Joe Perches 2017-10-17 8:34 ` Jani Nikula 2017-10-18 1:27 ` Joe Perches 2017-10-18 10:41 ` Jani Nikula 2017-10-16 18:52 ` Mark Brown 2017-10-10 8:53 ` Jiri Kosina 2017-10-24 23:03 ` Kees Cook 2017-10-24 23:41 ` Joe Perches 2017-10-25 0:54 ` Kees Cook 2017-10-25 4:21 ` Julia Lawall 2017-10-25 4:29 ` Joe Perches 2017-10-25 4:36 ` Julia Lawall 2017-10-25 6:05 ` Martin K. Petersen 2017-10-25 6:55 ` Kees Cook 2017-10-25 7:34 ` Martin K. Petersen 2017-10-25 6:45 ` Frank Rowand 2017-10-25 7:56 ` Mark Brown 2017-10-25 9:39 ` Laurent Pinchart 2017-10-31 19:19 ` Rob Herring 2017-10-31 19:28 ` Kees Cook
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.