[NeXus-tech] code repository clean up proposal

[Herbert J. Bernstein]

Until we have actually finished the new code so that it can do what cbf2nx
does, which is not the case at present, I would keep cbf2nx.  -- Herbert


On Thu, Apr 17, 2014 at 5:50 AM, <Tobias.Richter at diamond.ac.uk> wrote:

>  Hi all,
>
>
>
> I’ve recently updated the NeXus Debian package and they have some new
> checks in place for incoming packages that triggered.
>
> And while investigating I found some other snags.
>
>
>
> ·         What was originally triggered was the fact the our “source”
> contains dynamic libraries in contrib/applications/nxplot/jnexus. It didn’t
> flag up the dlls in there. One of them is szlib where I have yet to be
> convinced that is actually legally distributable. The whole nxplot
> hierarchy hasn’t seen any commits in the last 4 years. The hdf5 version we
> ship in there is 1.6.5. As far as I am aware it is not in active use and we
> have no resources to maintain it. Given that e.g. Dawn does a reasonable
> job at plotting NeXus data deleting nxplot might be an option. But of
> course I am slightly biased towards Dawn. So I welcome other opinions.
>
>
>
> ·         There is also a congregation of dlls in bindings/java/bin/win32
> which is over 10 years old. That lot also includes szlib, but nothing for
> xml. I would just remove them all.
>
>
>
> ·         Then I stumbled across cbf2nx in contrib/applications. Is that
> still needed Herbert? I suppose that’s obsolete with Jonathan’s converters.
> Right?
>
>
>
> ·         Finally there is an ancient NXformat_dfn python project hanging
> in there, which at one point may have been used to generate documentation.
> I would be surprised if there was still interest in that.
>
>
>
> So all those I would opt to remove, unless we want to resurrect nxplot or
> avid users of the applications show up. In addition there are a number of
> other old files of dubious value around (vms, windows, third_party, etc.)
> There are also two copies of the LGPL (1999) and a number of scripts in the
> top level that could go into the scripts folder. The 11 READMEs might be
> better off in a doc/ folder.  Please have a look yourself, if you can find
> the time. We can discuss later in the telco.
>
>
>
> Regards,
>
>
>
> Tobias
>
>
>
>
>
> --
>
> This e-mail and any attachments may contain confidential, copyright and or
> privileged material, and are for the use of the intended addressee only. If
> you are not the intended addressee or an authorised recipient of the
> addressee please notify us of receipt by returning the e-mail and do not
> use, copy, retain, distribute or disclose the information in or attached to
> the e-mail.
> Any opinions expressed within this e-mail are those of the individual and
> not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> attachments are free from viruses and we cannot accept liability for any
> damage which you may sustain as a result of software viruses which may be
> transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England
> and Wales with its registered office at Diamond House, Harwell Science and
> Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
>
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/mailman/private/nexus-tech/attachments/20140417/0b7e1822/attachment-0001.html>