Discussion:
gettext->gnulib sync conflicts
(too old to reply)
Karl Berry
2016-11-18 22:18:17 UTC
Permalink
Raw Message
Regarding the sync of gettext files into gnulib and the change to
iconv.m4.

Bruno, you updated iconv.m4 in the gettext dev repo with your change
made in gnulib. However, as I said, gnulib has been synced against
gettext releases, not gettext dev. This was a change I made at Daiki's
suggestion a couple years ago.

So I tried a sync of gnulib against gettext dev
(./config/srclist-update<config/srclist.txt), and a new difference
shows up, for Makefile.in.in. Diff below.

The changes in gettext's .in.in look reasonable to install now (that is,
to start syncing from gettext dev instead of gettext releases), but I
felt you or Daiki or someone should confirm. ?

I guess the immediate alternative is to stop syncing iconv.m4 (or to
make a gettext release :). --thanks, karl.

*** build-aux/po/Makefile.in.in Mon Jun 13 00:28:57 2016
--- /tmp/Makefile.in.in Fri Nov 18 08:58:03 2016
***************
*** 233,243 ****
test -f $(srcdir)/$(DOMAIN).pot || $(MAKE) $(srcdir)/$(DOMAIN).pot; \
test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \
! echo "$${cdcmd}$(MSGMERGE_UPDATE) $(MSGMERGE_OPTIONS) --lang=$${lang} $${lang}.po $(DOMAIN).pot"; \
cd $(srcdir) \
&& { case `$(MSGMERGE) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
! '' | 0.[0-9] | 0.[0-9].* | 0.1[0-7] | 0.1[0-7].*) \
$(MSGMERGE_UPDATE) $(MSGMERGE_OPTIONS) $${lang}.po $(DOMAIN).pot;; \
*) \
! $(MSGMERGE_UPDATE) $(MSGMERGE_OPTIONS) --lang=$${lang} $${lang}.po $(DOMAIN).pot;; \
esac; \
}; \
--- 233,245 ----
test -f $(srcdir)/$(DOMAIN).pot || $(MAKE) $(srcdir)/$(DOMAIN).pot; \
test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \
! echo "$${cdcmd}$(MSGMERGE_UPDATE) $(MSGMERGE_OPTIONS) --lang=$${lang} --previous $${lang}.po $(DOMAIN).pot"; \
cd $(srcdir) \
&& { case `$(MSGMERGE) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
! '' | 0.[0-9] | 0.[0-9].* | 0.1[0-5] | 0.1[0-5].*) \
$(MSGMERGE_UPDATE) $(MSGMERGE_OPTIONS) $${lang}.po $(DOMAIN).pot;; \
+ 0.1[6-7] | 0.1[6-7].*) \
+ $(MSGMERGE_UPDATE) $(MSGMERGE_OPTIONS) --previous $${lang}.po $(DOMAIN).pot;; \
*) \
! $(MSGMERGE_UPDATE) $(MSGMERGE_OPTIONS) --lang=$${lang} --previous $${lang}.po $(DOMAIN).pot;; \
esac; \
}; \
***************
*** 440,450 ****
echo "$$lang:"; \
test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \
! echo "$${cdcmd}$(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \
cd $(srcdir); \
if { case `$(MSGMERGE) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
! '' | 0.[0-9] | 0.[0-9].* | 0.1[0-7] | 0.1[0-7].*) \
$(MSGMERGE) $(MSGMERGE_OPTIONS) -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \
*) \
! $(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \
esac; \
}; then \
--- 442,454 ----
echo "$$lang:"; \
test "$(srcdir)" = . && cdcmd="" || cdcmd="cd $(srcdir) && "; \
! echo "$${cdcmd}$(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang --previous $$lang.po $(DOMAIN).pot -o $$lang.new.po"; \
cd $(srcdir); \
if { case `$(MSGMERGE) --version | sed 1q | sed -e 's,^[^0-9]*,,'` in \
! '' | 0.[0-9] | 0.[0-9].* | 0.1[0-5] | 0.1[0-5].*) \
$(MSGMERGE) $(MSGMERGE_OPTIONS) -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \
+ 0.1[6-7] | 0.1[6-7].*) \
+ $(MSGMERGE) $(MSGMERGE_OPTIONS) --previous -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \
*) \
! $(MSGMERGE) $(MSGMERGE_OPTIONS) --lang=$$lang --previous -o $$tmpdir/$$lang.new.po $$lang.po $(DOMAIN).pot;; \
esac; \
}; then \

compile finished at Fri Nov 18 08:58:04
Bruno Haible
2016-11-18 23:31:45 UTC
Permalink
Raw Message
Hi Karl,

Sorry for not having replied to your first mail on this topic.
gnulib has been synced against gettext releases, not gettext dev.
This was a change I made at Daiki's suggestion a couple years ago.
I fully support this: the maintainer of a package needs the ability to
have unstable changes in their git tree, without risking that they
cause trouble in other projects.

However, in periods where only small and safe changes are being made,
it's OK to propagate unreleased changes into gnulib, because a couple
of people are watching here with scrutiny.
Bruno, you updated iconv.m4 in the gettext dev repo with your change
made in gnulib.
...
I guess the immediate alternative is to stop syncing iconv.m4
Yes, please. The iconv.m4 change I would consider stable.
=> Stop syncing iconv.m4 with gettext for the moment.
So I tried a sync of gnulib against gettext dev
(./config/srclist-update<config/srclist.txt), and a new difference
shows up, for Makefile.in.in. Diff below.
The changes in gettext's .in.in look reasonable to install now
This particular change is also safe and stable. I wouldn't mind to
copy it into gnulib; it helps translators.
to start syncing from gettext dev instead of gettext releases), but I
felt you or Daiki or someone should confirm. ?
Daiki needs to decide. It depends on what kind of changes he'll do in
gettext next, and whether he is as shy as I am :)

Bruno
Karl Berry
2016-11-20 22:49:00 UTC
Permalink
Raw Message
However, in periods where only small and safe changes are being made,

The problem from my point of view is that I just see a change and can't
(don't want to) guess if it's "small and safe". If I can't blindly sync
the changes I see, that creates an additional burden that I can't (don't
want to) support.

This is not the first time this has come up wrt your gettext changes in
gnulib. (It's never come up wrt anything else.) The last time it
happened, the outcome we agreed on was to stop syncing gettext with
gnulib entirely, and you would do it manually, as you saw fit.

Then stopped having time to work on stuff for a while, and after
discussing with Daiki, I went back to the sync-with-releases regime,
since (not surprisingly) files had gotten out of sync -- the manual
sync by the maintainer is an easy thing to neglect.

I can sync against dev, or I can sync against releases, or I can not
sync at all, or I can quit being responsible for this job entirely and
someone else can figure out what to do :). I can't go back and forth
depending on development "periods". [Or gettext could be removed from
gnulib entirely, which I tend to think would tremendously simplify
everything for everyone, but doubt you like the idea.]

Sigh.

Daiki needs to decide.

Daiki? --thanks, karl.
Daiki Ueno
2016-11-21 09:50:57 UTC
Permalink
Raw Message
Hello,
Post by Karl Berry
I can sync against dev, or I can sync against releases, or I can not
sync at all, or I can quit being responsible for this job entirely and
someone else can figure out what to do :). I can't go back and forth
depending on development "periods". [Or gettext could be removed from
gnulib entirely, which I tend to think would tremendously simplify
everything for everyone, but doubt you like the idea.]
Sigh.
Daiki needs to decide.
Daiki? --thanks, karl.
I'm not really sure what I need to decide. Is there any room for
compromise between the sync-with-releases mechanism and manual
check-ins? I thought it would be possible to avoid unwanted overwrites
if srclist-update were aware of the serial numbers of the files.

Regards,
--
Daiki Ueno
Karl Berry
2016-11-21 22:42:26 UTC
Permalink
Raw Message
Hi Daiki (and all),

if srclist-update were aware of the serial numbers of the files.

1) Not all synced files have serial numbers.

2) It's not clear to me that the decision about syncing
should, in principle, be based on serial numbers (or timestamps).

3) Nevertheless I have no particular objection to the idea (it would
solve the immediate question, I guess), but I also don't feel like
implementing it. I doubt it's going to be the top of anyone else's
priority list either. Therefore I've disabled syncing of all
gettext<->gnulib files in gnulib/config/srclist.txt.

Feel free to revert/change as you like, at any time ... --best, karl.
Daiki Ueno
2016-11-22 08:58:09 UTC
Permalink
Raw Message
Post by Karl Berry
Hi Daiki (and all),
if srclist-update were aware of the serial numbers of the files.
1) Not all synced files have serial numbers.
2) It's not clear to me that the decision about syncing
should, in principle, be based on serial numbers (or timestamps).
3) Nevertheless I have no particular objection to the idea (it would
solve the immediate question, I guess), but I also don't feel like
implementing it. I doubt it's going to be the top of anyone else's
priority list either. Therefore I've disabled syncing of all
gettext<->gnulib files in gnulib/config/srclist.txt.
Feel free to revert/change as you like, at any time ... --best, karl.
Sorry, I probably do not understand the problem. Why can't we continue
syncing with the gettext releases, even if one checks in a change into
gnulib directly?

That would probably work, even without checking the serial numbers,
because gettext has a way to detect conflicts when making a distribution
tarball:
http://git.savannah.gnu.org/cgit/gettext.git/tree/Makefile.am#n62

I barely remember the last discussion, but my motivation was to
eliminate the manual procedure to propagate changes from gettext after
every release.

So, I would like to ask you to continue doing sync-with-releases
(ignoring the changes made in gnulib git repository), unless it is too
much burden for you.

Thank you,
--
Daiki Ueno
Paul Eggert
2016-11-22 15:50:01 UTC
Permalink
Raw Message
Post by Daiki Ueno
Why can't we continue
syncing with the gettext releases, even if one checks in a change into
gnulib directly?
I assume this is because Karl's procedure, which he runs periodically,
is to grab the latest release from various sources, and to copy the
relevant files to Gnulib.

It sounds like you are thinking that he runs his procedure for gettext
only immediately after a gettext release. Although that might be an
improvement on what we have now, it's not what his procedure does, and
changing his procedure to do that would be a pain.
Daiki Ueno
2016-11-22 17:17:11 UTC
Permalink
Raw Message
Post by Paul Eggert
Post by Daiki Ueno
Why can't we continue
syncing with the gettext releases, even if one checks in a change into
gnulib directly?
I assume this is because Karl's procedure, which he runs periodically,
is to grab the latest release from various sources, and to copy the
relevant files to Gnulib.
Ah, I see. Thank you for the explanation.
Then I will try to find another way around.

Regards,
--
Daiki Ueno
Daiki Ueno
2016-11-23 12:54:02 UTC
Permalink
Raw Message
Post by Daiki Ueno
Post by Paul Eggert
Post by Daiki Ueno
Why can't we continue
syncing with the gettext releases, even if one checks in a change into
gnulib directly?
I assume this is because Karl's procedure, which he runs periodically,
is to grab the latest release from various sources, and to copy the
relevant files to Gnulib.
Ah, I see. Thank you for the explanation.
Then I will try to find another way around.
How about this?

- introduce "release" option in srclist.txt

- check the dev tree, but if the "release" option is specified, also
check the most recently tagged revision in the git repository, before
reporting conflict

That can be done by the attached patch (though it's a bit ugly).

git clone git://git.sv.gnu.org/gettext.git
git clone git://git.sv.gnu.org/gnulib.git
cd gnulib
git am < 000*.patch
sed -i 's/^verbose=false/verbose=true/' config/srclist-update
grep GETTEXT config/srclist.txt | $PWD/config/srclist-update $PWD

## /tmp/codeset.m4:v0.19.8.1 m4/codeset.m4 # unchanged
## /tmp/gettext.m4:v0.19.8.1 m4/gettext.m4 # unchanged
## /tmp/iconv.m4 m4/iconv.m4 # unchanged
## /tmp/intl.m4:v0.19.8.1 m4/intl.m4 # unchanged
## /tmp/intldir.m4:v0.19.8.1 m4/intldir.m4 # unchanged
## /tmp/intlmacosx.m4:v0.19.8.1 m4/intlmacosx.m4 # unchanged
## /tmp/lcmessage.m4:v0.19.8.1 m4/lcmessage.m4 # unchanged
## /tmp/nls.m4:v0.19.8.1 m4/nls.m4 # unchanged
## /tmp/po.m4:v0.19.8.1 m4/po.m4 # unchanged
## /tmp/Makefile.in.in:v0.19.8.1 build-aux/po/Makefile.in.in # unchanged
## /tmp/remove-potcdate.sin:v0.19.8.1 build-aux/po/remove-potcdate.sin # unchanged

Regards,
--
Daiki Ueno
Karl Berry
2016-11-22 22:38:34 UTC
Permalink
Raw Message
I assume this is because Karl's procedure, which he runs periodically,

Nightly, for the record ... -k
Karl Berry
2016-11-23 23:49:17 UTC
Permalink
Raw Message
Hi Daiki,

That can be done by the attached patch (though it's a bit ugly).

Since you went to the trouble of writing the code, it's certainly
fine by me. Please go ahead and commit that? --thanks, karl.

Loading...