[Bug 211626] Review Request: xtide - Calculate tide all over the world

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: xtide - Calculate tide all over the world


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211626


dave at flaterco.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave at flaterco.com




------- Additional Comments From dave at flaterco.com  2006-11-12 20:38 EST -------
Upstream here.  I was AFK for two weeks.

In a message dated 2006-11-02 19:47+0900, Mamoru Tasaka wrote:
> A.
> Well, currently libtcd library are packaged in XTide tarball and
> only static archive are provided. libtcd is used not only for XTide,
> but also some utilities in tcd-utils and others, so I think
> providing libtcd seperately is a good idea.

The reason things are packaged the way they are is that 99% of users
are only interested in running XTide to get tide predictions.  They
have no interest in nor any need for an ability to generate or edit
the tide data, and anything I do to make that possible for them just
adds complexity, hurts performance, and makes them yell at me.  I have
been there and done that, and it was a mistake.

tcd-utils is for the other 1% who actually do know enough to edit tide
data in a meaningful way and have reason to do it.  It was never
cleaned up for the 99% market.  The people who use it (counted on one
hand) have never complained about having to compile it from ugly
source snapshots.

The inclusion of tcd-utils in Fedora was perhaps motivated by some
policy that discouraged shipping binary files?  For the legacy
harmonics data (still distributed by Bob Kenney, but not maintained),
the TCD was in fact built from text and XML source, so building a TCD
using tcd-utils might have made sense.  But that is all ancient
history.  harmonics-dwf now starts with scraping web pages from the
NOAA web site using software that has to be updated every year as
their web site changes, then these are processed into an SQL database
where they merge with other countries' data, then manual fixes are
made as needed to correct upstream errors, then eventually the whole
mess is exported directly to TCD.  The closest you could get to what
you want is to start with the SQL dump, but then you would need to
have PostgreSql running, and harmbase2, and ... just don't go there.
99% of users will not benefit from this approach.  They just want the
tide prediction part of the program to install easily and run easily.

I don't advise use of the legacy data.  harmonics-dwf from
http://www.flaterco.com/xtide/files.html is maintained by me.  The
legalese for harmonics-dwf is at
http://www.flaterco.com/xtide/harmonics_boilerplate.txt.  See
http://www.flaterco.com/xtide/faq.html#60 for background on why there
is so much of it.

> A-1: How do you think of providing libtcd shared dynamic library seperately?

This makes sense if you really do want to deliver tideEditor or other
extras in Fedora.  But do you *really* want to do that?

> A-2: If you agree with provide libtcd.so, how should we determine soname?

Deferred pending answers to previous.

> A-3: Related to A-2, should we provide libtcd.so (if you agree) with COMPAT114
>       defined or undefined? (Note: tcd-utils 2005-08-11 can _NOT_ be compiled
>       with COMPAT114 _defined_).

Do not define COMPAT114.  AFAIK only the Naval Oceanographic Office
ever used this, and they might not even still use it.

> A-4: Do you have any plan to provide seperate libtcd tarball?

Deferred pending answers to previous.

Separate maintenance of libtcd would help me in case libtcd needs
maintenance when XTide doesn't, but for the 99% of users it would be
an annoyance to have to do two installs instead of just one.

FYI, the libtcd bundled in XTide 2.9 DEVELOPMENT incorporates bug
fixes that are important ONLY to tideEditor, but for tideEditor they
are serious.  If Fedora wants to ship tideEditor as part of its
distribution, then we (including me) need to do whatever is necessary
to enable tideEditor to be linked with the newest libtcd, rather than
the one that is bundled with the stable XTide 2.8.3.

> B.
> Another issue of packaging are tideEditor issue. The reviewers of XTide says
> that tideEditor should belong to XTide package as:
> * the other binaries in tcd-utils (build_tide_db and restore_tide_db) are only
>   command line conversion tools and have less dependency.
> * on the other hand XTide, tideEditor is a graphical viewer (tideEditor is also
>   a viewer) and have a lot of dependency (especially tideEditor depends on Qt).
> 
> So,
> B-1: how do you think of moving tideEditor to XTide tarball?

It would make sense if it were used by more than 1% of users.  But I
don't think that it is, or would be, even if it were installed for
them automagically.  It is only potentially useful if an end user
manages to find some tide data that they want to add, and then only if
they know what they are doing.  This happy coincidence just doesn't
happen as often as you would hope.

FYI, I am currently in the midst of a 100% code review and cleanup for
XTide.  This is a good time to incorporate changes to make life easier
for Fedora, but not a good time to assume that the latest snapshot is
stable.

Patrice Dumas wrote:
> I guess that a full security audit of xttpd would be nice, however
> it would go beyond a review.

I will cooperate with a security audit of xttpd and implement any
mitigations that are indicated, but if it does show any problems that
are hard to address it might be better to retire it.  I constructed
xttpd as a proof-of-concept that you could put an HTTP interface on
XTide, hoping that web developers would pick up the ball and run with
it.  They didn't.  They preferred to stick with CGI, or nowadays with
PHP.

Other FYIs:

With respect to patching configure to do CFLAGS etc. as expected, I
have a guy who is supposedly reorganizing the whole thing according to
current best practices and making it NetBSD-friendly.  Haven't heard
from him in a month or so, but I can put you in touch to coordinate
changes.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.