----- Original Message ----- > On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca <jfons...@vmware.com> > wrote: > > Matt, > > > > I see you went ahead and just disabled it. Please remove it all > > together. > > > > Touching code that is not built nor tested ends just silently > > introduces bugs, so keeping this around won't help bring it back > > one day in any way. > > > > Jose > > I talked with both Marek and Christoph, and they both said they'd > prefer to simply disable the build. I don't feel strongly, but if > someone is to revive it it'd be nice if we didn't make the git > history > harder to follow.
I suppose they have their arguments, and I hope they include making this build again shortly. What I don't understand is why these talks didn't happen within this email thread. I'd expect at least a heads up email before committing this... > Applying your reasoning (which I tend to agree with) to some other > parts of Gallium makes for interesting conversation. The VAAPI state > tracker and targets aren't built. Should we also nuke them? How about > something like the xorg-i915 target (which installs a > 'modesetting_drv.so')? I don't know enough about this code or the ongoing autotool-ification process to tell whether this is a short term or long term condition. But yes, In general I see no point in carrying around stuff that doesn't minimally work or can't even be built. If something is unusable/unmaintained over one Mesa release cycle, then it should be chopped off. Every dead code we remove means that cleanups and refactorings of the good code becomes easier. And if it is broken, then there's no loss to the end user either. This is not the first or last time we'd remove code BTW. There are many precedents. Jose _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
