[Mesa-dev] Merge criteria for glsl2 branch

[Dave Airlie]

On Thu, Jul 22, 2010 at 11:53 AM, Ian Romanick <idr at freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> As everyone knows, a group of us at Intel have been rewriting Mesa's
> GLSL compiler.  The work started out-of-tree as a stand alone compiler.
>  We moved all of our work to the glsl2 branch in the Mesa tree as soon
> as we had some actual code being generated.  This was about month ago.
> Since that time we have implemented quite a bit more code generation and
> a complete linker.  The compiler is not done, but it gets closer every day.
>
> I think now is the time to start discussing merge criteria.  It is well
> known that the Intel graphics team favors quarterly releases.  In order
> to align with other people's release schedules, we'd really like to have
> the new compiler in a Mesa release at the end of Q3 (end of September /
> beginning of October).  That's just over two months from now.  In order
> to have a credible release, the compiler needs to be merged to master
> before then.  A reasonable estimate puts the end of August as the latest
> possible merge time.  Given how far the compiler has come in the last
> month, I have a lot of faith in being able to hit that target.
>
> We have developed our own set of merge requirements, and these are
> listed below.  Since this is such a large subsystem, we want to solicit
> input from the other stakeholders.
>
>  * No piglit regressions, except draw_buffers-05.vert, compared to
>    master in swrast, i965, or i915.
>
>  * Any failing tests do not crash (segfault, assertion failure, etc.).

How about when you hit this goal, you merge master on that day into
your branch, retest and let everyone know.

Give people a week for testing other drivers, I'm sure some of us r300
people can do some regression tests at that point,

I'm sure if it all just builds in the branch someone will get around
to doing regression tests on r300 before then anyways.

I think testing softpipe at least would be worth doing, its not so
different from swrast, you just build it and point LIBGL_DRIVERS_PATH,
though I'm not sure if you'd be expected to go fixing things that may
turn up but it might be good to publish some piglit comparisons if
there are many problems.

btw I haven't had time to check, but do you completely remove the old
compiler? just wondering for testing if its a matter of running two
separate trees or not.

Dave.