linux-next: build failure after merge of the mali-dp tree

[Daniel Vetter]

On Tue, Jan 15, 2019 at 1:23 PM Liviu Dudau <Liviu.Dudau at arm.com> wrote:
>
> On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 10:51:02AM +0000, Liviu Dudau wrote:
> > > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > > Hi Liviu,
> > > >
> > > > On Tue, 15 Jan 2019 10:12:19 +0000 Liviu Dudau <Liviu.Dudau at arm.com> wrote:
> > > > >
> > > > > That looks like the right fix, thank you for that!
> > > >
> > > > Thanks for your verification.
> > > >
> > > > > I will roll your patch into my tree.
> > > >
> > > > You can only do that when your tree is merged with the drm tree (and
> > > > it should be part of the merge resolution).
> > >
> > > I can also rebase on top of the latest drm-next tree, that should not be
> > > a problem.
> >
> > If you have a lot of patches already rebasing is kinda discouraged. There
> > might be other stuff that's conflicting and then making your entire tree
> > non-bisectable (maybe just on one platform that you missed in testing).
>
> My tree has always been "unstable", I have been rebasing it on top of
> latest drm or drm-next in preparation for sending pull requests. I've hoped
> that people don't depend on the linearity of my tree anyway and it hasn't
> been an issue so far.

"Don't unecessarily rebase" isn't only about screwing up people who
base their own stuff on your tree, it's also about invalidating
testing. E.g. if there's a silent conflict with latest drm-next, and
you rebase before sending out your pull request, but then don't notice
that new issue, then all these commit won't work in a bisect for a 2nd
issue.

But if you don't rebase, then only the merge commit will be broken
(until the bugfix was commit, which is hopefully not too long), and
all the commits on your branch still work.

So summary is that if you regularly rebase your pile of "ready for
linux-next" patches, then you're doing something wrong. And the bigger
your team (and hence the amount of work going on) the more wrong this
becomes. Ime you can rebase to squash in bugfixes with a bigger team
still, but rebasing to change the baseline stops being a good idea
pretty quickly.
-Daniel

> TBH, I should've based the latest update of my tree on drm-next anyway, I
> just started at the time when it was at v5.0-rc1 so I thought it will not
> matter.
>
> Best regards,
> Liviu
>
> >
> > In that case just send out a pull for drm-next and include the merge
> > resolution in the pull request so Dave/I can double-check we did it right.
> > -Daniel
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ¯\_(ツ)_/¯
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch