[GIT PULL v2] mediatek drm next for 5.8

Dave Airlie airlied at gmail.com
Thu May 28 06:01:34 UTC 2020


On Sat, 23 May 2020 at 01:58, Matthias Brugger <matthias.bgg at gmail.com> wrote:
>
>
>
> On 20/05/2020 07:46, Dave Airlie wrote:
> > On Wed, 20 May 2020 at 15:44, Dave Airlie <airlied at gmail.com> wrote:
> >>
> >> On Mon, 18 May 2020 at 10:06, Chun-Kuang Hu <chunkuang.hu at kernel.org> wrote:
> >>>
> >>> Hi, Dave & Daniel:
> >>>
> >>> This include dpi pin mode swap, config mipi_tx current and impedance,
> >>> and some fixup. I drop drm_bridge patches in this version.
> >>>
> >>> The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
> >>>   Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
> >>> are available in the Git repository at:
> >>>   https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git
> >>> tags/mediatek-drm-next-5.8
> >>> for you to fetch changes up to 007d274a017bb4e2ef7b922c2f54f40cf2073664:
> >>
> >> Did you edit this by hand or pass it through some mailserver that
> >> chewed it up, I had to reconstruct this pull from the above bits, I've
> >> no idea why it's so messed up in the first place.
> >
> > and why does it contain an unexplained backmerge?
> >
> >  Merge tag 'v5.7-next-drm-stable' of
> > ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux
> > into mediatek-drm-next
> >
> > Please don't ever backmerge fixes into next pull, without a long
> > explaination or if you really need it ask us first,
>
> It's not fixes. I suppose my tagging strategy helps to create confusion. The tag
> is v5.7-*next*, which relates to v5.8 (next version after v5.7). Maybe not the
> best way to do it.
>
> We had to merge a series that changed the drivers/gpu/drm, drivers/soc and
> drivers/clk.
> So I took the series through my branch and Chun-Kuang merged a stable tag in his
> branch so that he can take commits on top of this changes.
>
> Maybe the explanation comes too late, but I just wanted to clarify.

Okay so whenever a submaintainer tree has a merge in it, two things
need to happen.

a) the merge needs a commit msg explaining what it is, why it's there.
b) the subsequent pull request should mention it's existence.

I'm not used to pulling trees from submaintainers with merges in them
and usually it's a red flag that they've backmerged something they
shouldn't have.

Dave.


More information about the dri-devel mailing list