On 05/16/2017 09:04 PM, Jason Ekstrand wrote: > On May 16, 2017 18:30:00 Timothy Arceri <[email protected]> wrote: > >> On 17/05/17 02:38, Ian Romanick wrote: >>> What *actual* problem are you trying to solve? Honestly, it seems like >>> you're just trying to find stuff to do. We have a mechanism to make >>> this work, and it's not that hard. Introducing a deprecation period and >>> everything that involves will make it more work, not less. > > I think that's a fair question > >> To be fair aren't we in a stage in Mesa's life-cycle where the focus is >> on tidying-up / optimisations. It's not like there are large spec >> updates in the pipeline. > > If we are genuinely making things more maintainable, then maybe > deprecation is reasonable. However, of it's just churn, then it may > just be a source of new bugs to fix. I think asking "why?" is perfectly > reasonable. > > On the other side, perhaps we should consider instead taking advantage > of the backwards comparability and dropping some of the old and > unmaintained drivers from the tree, put them on a critical-bugfix-only > branch, and recommend that distros build two mesas and only install the > loader from the newer one. Dropping i915, r200, and other effectively > unmaintained drivers from the tree would make it much easier to do core > state tracker cleanups since there would effectively only be two state > trackers: gallium and i915. For example, there's a lot of code floating > around for dealing with hardware that doesn't have native integers.
r300 and r400 in Gallium do not have native integers. I don't know about NV30. I wanted to remove support for NV04 and NV05 last year because they are unused, unmaintained, and demonstrably *broken*, and I could not even get consensus on that. > --Jason _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
