[Users] Meeting Minutes

[Ian Hinder]

On 2 Jun 2015, at 16:59, Frank Löffler <knarf at cct.lsu.edu> wrote:

> On Tue, Jun 02, 2015 at 04:44:46PM +0200, Ian Hinder wrote:
>> Indeed.  If you (still) have access to Mathematica.
> 
> How many thorns are we talking about? If you don't intent to regenerate
> them, maybe this could be done once, by a script?

That's not what I'm getting at; we can of course fix all the ET Kranc-generated thorns to keep up with the ever-changing flesh.  It's a matter of policy regarding backward compatibility.

>> I just don't see the point of deliberately breaking backward
>> compatibility, even in the case where the old behaviour was not in
>> agreement with the documentation.  What is the benefit of doing this?
> 
> It prevents new code from using this. Old thorns cannot be expected to
> work forever with a changing framework.

I disagree completely.  Cactus should be a stable platform on which you can build application thorns.  New versions of this platform should still be able to run old code.  Especially in this case, where there is no benefit to the change apart from discouraging new thorns using the old way.  I think a warning should be enough.

> Leaving old stuff in for ever
> usually makes code unmaintainable, although I don't know how severe it
> would be in this case. We didn't intent to make this go away
> immediately, more like marking it deprecated and generating a warning
> now, and removing it from a release in a year at the earliest.

Usually this sort of change is very annoying. In isolation, you can just say "it's a simple change, why are you complaining?"  But when trying to resurrect an old thorn, it's unlikely that this is the only problem you're going to have, and each one makes life harder.  I agree that leaving in a huge amount of backward-compatibility code can make the code harder to maintain, which is why in the ticket I said that it could be removed if that were the case.  But I don't think that is the case here, and I don't see a benefit to removing the code.

-- 
Ian Hinder
http://members.aei.mpg.de/ianhin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150602/f930e1fa/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20150602/f930e1fa/attachment.bin