[Ksummit-discuss] Maintainer's Summit Agenda Planning

Daniel Vetter daniel.vetter at ffwll.ch
Thu Oct 12 10:03:30 UTC 2017

On Wed, Oct 11, 2017 at 8:51 PM, Jani Nikula <jani.nikula at intel.com> wrote:
> On Mon, 09 Oct 2017, James Bottomley <James.Bottomley at 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 Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

More information about the Ksummit-discuss mailing list