<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 20, 2016 at 2:13 PM, Alberto Luaces <span dir="ltr"><<a href="mailto:aluaces@udc.es" target="_blank">aluaces@udc.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Robert Osfield writes:<br>
<br>
> Thoughts?<br>
<br>
In my opinion, a new repo implies extra maintenance duties (even they<br>
are likely low), but cannot guarantee that it is synced or working with<br>
the latest OSG version, so it has a little added value.<br></blockquote><div><br></div></div><br></div><div class="gmail_extra">Wasn't the entire point of having the dead code in a separate repo that it won't need to be maintained? If someone still wants to use it, it will be available, just not necessarily compiling with the current OSG and they would have to put some elbow grease in it to make it work again.<br><br></div><div class="gmail_extra">Personally I don't have an issue with it. There is little point in spending resources on things that are not being used but still have to be maintained only because someone could find the code potentially useful in the future. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">I would adopt a 2 step process for it, though - mark the bits to be removed as deprecated in version N first, including warning messages being printed, etc. and only remove it to a separate "attic" repo in release N+x, where x is to be defined. Not everyone that uses OSG follows the list or updates to the current version as soon as it is released, so that should give them an ample warning. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">J.<br></div><div class="gmail_extra"><br></div></div>