<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 17, 2017 at 3:39 AM, Emil Velikov <span dir="ltr"><<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 17 May 2017 at 05:04, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
<br>
> If we are genuinely making things more maintainable, then maybe deprecation<br>
> is reasonable.  However, of it's just churn, then it may just be a source of<br>
> new bugs to fix.  I think asking "why?" is perfectly reasonable.<br>
><br>
</span>Seems like I failed to state it clearly:<br>
The new code added is a few warning messages. Those in itself will<br>
flag up any existing bugs that we have failed to catch.<br>
Followed by some period X, those will be removed alongside the unused code.<span class=""><br></span></blockquote><div><br></div><div>What code?  I think a decent part of the communication problem is that this entire discussion is about a generic "deprecation period" that could theoretically be applied to any feature.  Could you please be specific about exactly what code you are itching to remove and why?  I firmly believe that untested code is broken code and should be removed, but you have yet to provide any details.  You said you have a branch.  Could you provide a link?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> On the other side, perhaps we should consider instead taking advantage of<br>
> the backwards comparability and dropping some of the old and unmaintained<br>
> drivers from the tree, put them on a critical-bugfix-only branch, and<br>
> recommend that distros build two mesas and only install the loader from the<br>
> newer one.  Dropping i915, r200, and other effectively unmaintained drivers<br>
> from the tree would make it much easier to do core state tracker cleanups<br>
> since there would effectively only be two state trackers: gallium and i915.<br>
> For example, there's a lot of code floating around for dealing with hardware<br>
> that doesn't have native integers.<br>
><br>
</span>FWIW I have patches for i915 and nouveau_vieux which add support for<br>
DRI2_FLUSH v4 and others.<br>
<br>
I tend to agree with your idea here, although it's somewhat orthogonal<br>
to what I'm suggesting.<br>
Can we move that to its own thread?<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br></div><div class="gmail_extra">If we're going to talk about generic deprication periods, then they're absolutely related.  If we're going to drop old drivers then the answer to the question becomes "never" for any versions they're using.<br></div></div>