Re: CVS & Gettext

[Paul D. Smith]

%% address@hidden (Bruno Haible) writes:

  bh> Let me explain in depth why omitting intl/, po/Makefile.in.in,
  bh> m4/gettext.m4 etc. from a CVS is a bad idea.

I understand and agree that your reasoning is quite appropriate for a
number of packages.

However, I simply don't think it's appropriate for a tool such as
Gettext to essentially _require_ a specific way of doing things.  Make
it the default, by all means, but please allow for people with differing
needs and views of how they want _their own_ package development to
proceed to use them in a reasonable manner.

Let me give you a simple counter-point to your arguments: GNU make.

There is exactly one developer on the GNU make project.  There is no
confusion whatsoever about which versions of which tools are being used
during development, and no problem with keeping these tools in sync :).
The overhead of updating these files and keeping them correct is more
than the overhead of keeping the tools synced between multiple
developers, because there is zero cost associated with the latter.

These considerations should definitely appear in the documentation or
some kind of help file so people using these tools have some basis for
making a decision, and an idea of the issues involved.

  bh> This means that a new version of gettext *will* require changes to
  bh> the Makefile.in/configure.in/... infrastructure of a
  bh> package. There will therefore necessarily be a developer who makes
  bh> these changes and then commits them into the CVS. Now the
  bh> developers that use an older version of gettextize will be
  bh> hosed. I cannot build into an older version of gettextize the
  bh> logic to undo the configure.in changes that people will make for
  bh> the sake of the newer version - because I don't know the newer
  bh> version's characteristics at that moment.

Certainly.  I think the issue being raised here is not that gettextize
should do more, but rather that it does too much.  It's a
long-established principle that the more intelligent and heuristic an
automated tool tries to be, the more often it will be closer to annoying
than helpful.

Here is the very simple behavior that I (and maybe others) would like to
see in gettextize: either via a special flag, a separate script, or
whatever:

 1) Add missing files to the distribution, via symlinks or copying as is
    done now.

 2) Do not die if one or more of these files already exists.  Printing a
    message if the contents are different than expected would be nice.

 3) Do not make changes to any of the existing files, including
    changelogs, Makefile.am's, etc.

 4) (optional) Perform error _checking_ and generate warnings for
    incompatibilities that are so detected, but do not take any action
    to resolve these problems.  This could simply be another mode to
    whatever "fix-up" code exists in gettextize, which prints a message
    instead of trying to actually fix things.

  bh> a) You could say that gettext must avoid incompatible changes from
  bh> one version to the next.

Of course this is not acceptable.

  bh> b) The developer which upgrades the files in CVS could force the other
  bh> developers to use the newer version of gettextize.

You may not feel that this solution is appropriate, but I believe this
is for the development team of a given project to decide: they are in a
better position to know what works for them.

  bh> c) The developer who upgrades to a new gettext version commits all his 
  bh> changes to the CVS, including intl/* and m4/gettext.m4.

This is a good solution, particularly well-suited to larger and more
distributed development efforts.

  bh> 1) It copes well with incompatible changes between gettext releases,
  bh> whether intentional or accidental. It doesn't put a burden on the n-1
  bh> developers that didn't do the upgrade.

In the case above, n=1 so n-1=0.

  bh> 2) When it comes to making a release, it is more reliable. Imagine
  bh> that gettextize created files are omitted from CVS, and that developer
  bh> A makes the release with gettext release 1.A, while his codeveloper B
  bh> uses gettext release 1.B. If there is a portability problem of the 1.A
  bh> version on the B's platform, it will go undiscovered. Whereas in the
  bh> approach c) all developers would test the package with gettext release
  bh> 1.A in the weeks preceding the release and would thus likely detect
  bh> the problem.

In the case above, and I believe on many other projects, testing is done
is on the released package tarball.  No one ever tests out of the CVS
tree.

  bh> For these reasons, I will recommend c) in the gettext doc, and not
  bh> take any steps which are tantamount to encouraging a) or b).

I hope you will reconsider allowing development teams to make their own
choices about whether approach (b) is right for them or not.  Some of us
have been doing this a very long time and are fully capable of
understanding the issues involved and making our own choices.

Thanks!

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://www.paulandlesley.org/gmake/
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist