On Mon, Dec 03, 2018 12:41:41 +0100, Kevin Kofler wrote: > Ankur Sinha wrote: > > Since correctness is really important here, if upstream does not test > > the toolboxes against Octave, we shouldn't either > > I think that if it runs at all, we should ship it. > > Some upstreams seem pretty conservative. E.g., SPM seems to have done a lot > of work on Octave compatibility already, and the page seems to imply that it > will more or less work, with some issues, they just do not support it still. > Fedora, in contrast, is a forward-looking distribution that is about > shipping Features First and with Freedom (i.e., no MATLAB!) included. No, I disagree with this. These are not user-end applications where an annoying bug may be fixed in a future release and make everyone happy. These are toolboxes that are used for analyses of data, and the results from the analyses contribute to science. Then, other studies will build on these results, and so on. If there's any hint of lack of correctness, being conservative makes sense---it is too much of a risk. A minor issue can undo years of work and progress. It would be very bad if an issue in our provision of the toolbox with Octave resulted in a retraction, later on, for example. If a researcher uses a MATLab toolbox with Octave, it is their responsibility to check for correctness. If we provide them, it is ours, and this is not a responsibility we have the man power to take on. We'd rather rely on upstream. > In addition, they also write that the issues are mainly in the GUI, not in > the computation backend where correctness is important. But they do not say that they test for correctness against Octave either. We are only speaking about SPM as an example here, and I can reach out to upstream to confirm, but there will be other toolboxes that do not discuss Octave compatibility at all and may not have the resources to look into it either---so this is more general issue. > > > - Use COPR to provide Matlab only toolboxes (as I think the above rule > > does not apply to COPR). > > > > Would that be OK? > > I think it is NOT OK, because software in Copr is also supposed to comply > with Fedora licensing policies: > https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr > > Now, arguably, the package itself is not improperly licensed, Not "arguably"--very clearly :) (We do not consider non free toolboxes at all) > but if the > Copr is documented as working only with an external proprietary interpreter > (whether or not that is actually true, though as far as I know you need to > actually compile the mex file against Octave for it to work with Octave, so > if you only package the binary for MATLAB, it won't work without MATLAB), > that is stretching the rules. Sure. I do agree with this. I've said before that we'd really prefer if we didn't have to use/support MATLab at all. But that's not the case, so we're trying to see what can be done here keeping the realities of the MATLab eco-system in mind. In the meantime, we will start by providing toolboxes that clearly document Octave support, and simply documenting that users must get the others themselves. -- Thanks, Regards, Ankur Sinha "FranciscoD" https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
