Bug 431125 - Translations not being committed upstream
Translations not being committed upstream
Status: CLOSED UPSTREAM
Product: Fedora Localization
Classification: Fedora
Component: Website (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Dimitris Glezos
A S Alam
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-31 15:54 EST by Miloš Komarčević
Modified: 2013-07-02 20:46 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-08 14:30:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miloš Komarčević 2008-01-31 15:54:21 EST
No new translations (sk, sr, sr@latin, nl, as) are getting through to
system-config-date for the past two weeks. Also, its seems that the last batch
of updated translations (not talking about recent update-po but gu, it, pt_BR)
were committed by the package maintainer on Fri Jan 18 17:29:17 2008 +0100
directly instead of coming through Transifex. Compare hg and transifex logs:

http://hg.fedorahosted.org/hg/system-config-date
https://translate.fedoraproject.org/submit/module/system-config-date
Comment 1 Dimitris Glezos 2008-02-07 18:00:49 EST
From what I see in the logs of the module in question, there have been some
successful commits. Maybe this is DUPE of #303991?
Comment 2 Miloš Komarčević 2008-02-07 18:36:04 EST
Where do you see that? I haven't seen anything coming from Transifex through to
hg for this module for a while, only direct commits to po/* by the maintainer.
The last successful one was on Jan 4: 

http://hg.fedorahosted.org/hg/system-config-date/rev/d005d8fab45a

The single Transifex commit that appeared yesterday by Fabian Affolter seems to
be borked (created po/de.po.orig and po/de.po.rej). Where are all the other
commits that showed up in the web log in the meantime?

Don't think this is (or was) a dupe of bug 303991, since I didn't get the 500
error. Everything seemed successful and logged on the web side, just nothing
came through to hg.
Comment 3 Dimitris Glezos 2008-02-19 17:07:13 EST
OK, I tracked this down today. The VCS user we are using didn't have permissions
to that repository, so pushed commits failed. This happened also in s-c-nfs, for
which I opened bug #433542.

Now, this is a serious problem, since we want to constantly keep Tx in sync with
upstream to avoid conflicts. However, mercurial is a bit picky in reverting
stuff back if they fail getting pushed.

If local commits stay in the repo and new stuff arrive upstream, all subsequent
pushes will fail because the introduce new remote heads. To battle this, we need
to check if a push fails, rollback the last commit right away.

FWIW, this is easily fixable, since a removal of the local repo copy and a new
Refresh will do the trick, albeit losing all unpushed commits so far.

Leaving the bug report open until we fix this properly.
Comment 4 Piotr Drąg 2009-07-03 16:07:27 EDT
Mass change of component from Transifex to Website, since all our websites are handled by Transifex now.

Note You need to log in before you can comment on or make changes to this bug.