[Mesa-dev] [PATCH 1/2] panfrost: Initial stub for Panfrost driver

[Jason Ekstrand]

On Mon, Feb 4, 2019 at 6:43 PM Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand <jason at jlekstrand.net>
> wrote:
> >
> > On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig <alyssa at rosenzweig.io>
> wrote:
> >>
> >> > Actually, I just gave you (Alyssa) push access... Also, as you'll (as
> >> > far as I understand) basically be owning the panfrost bits in mesa,
> >> > you should be able to commit to them.
> >>
> >> Oh, thank you! :)
> >>
> >> >  1. Don't break the build
> >>
> >> Acked-by: Alyssa Rosenzweig <alyssa at rosenzweig.io>
> >>
> >> >  2. No merge commits
> >>
> >> Just to be clear, is the idea to just make sure everything applies
> >> cleanly / is a straightforward fast-forward, and if not, to
> rebase/squash
> >> so it does?
> >
> >
> > Roughtly?  I really did mean "no merge commits" which really just means
> linear history.  Ideally, you'd have something that roughly linearly works
> but that's a Panfrost quality thing. I'm sure there will be regressions all
> over the place as you work given that it's still a bit prototypey.
>
> An important point here is "bisectable". You shouldn't have commits
> like "fix this totally broken earlier commit in the series". Breakage
> can happen -- that's a fact of life -- but you should avoid having
> "known" breaking commits, since that will mess up bisects down the
> line.
>

Right.  I just didn't want to sound too draconian because I know what the
crazy prototype world looks like.  That said, the more linearly working and
bisectable the better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190204/62282ce8/attachment.html>