On Mon, Feb 4, 2019 at 6:43 PM Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Mon, Feb 4, 2019 at 7:38 PM Jason Ekstrand <ja...@jlekstrand.net> > wrote: > > > > On Mon, Feb 4, 2019 at 6:25 PM Alyssa Rosenzweig <aly...@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 <aly...@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.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
