[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: i18n and direct builds from a source repository
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2014-11-26 23:22:40
Message-ID: 1901441.gOa2hQKINg () xps
[Download RAW message or body]


El Dimecres, 26 de novembre de 2014, a les 16:01:52, Thomas Friedrichsmeier va 
escriure:
> Hi,
> 
> On Wednesday 26 November 2014 14:43:32 Luigi Toscano wrote:
> > On Wednesday 26 of November 2014 14:09:36 Thomas Friedrichsmeier wrote:
> > > There seems to be no uniform answer to this for all (or even most)
> > > projects
> > > in KDE. Manually copying pos from svn and adjust CMakeLists for that may
> > > just work, if you are really familiar with KDE infrastructure. releaseme
> > > is
> > > a great way for extragear apps to (among other things) fetch
> > > translations,
> > > but - as the name is already indicating - is quite obviously _not_
> > > targetted at casual curious bystanders: It is a rather complex
> > > additional
> > > step for users to take - unless of course they are already knee-deep
> > > into
> > > KDE repos - it takes several minutes just to fetch the translations of a
> > > single catalog, it produces a lot of noise along the way, it does not
> > > give
> > > you an easy way to keep tracking after the initial "clone", ...
> > > All of these are non-issues for the actual use-case of releaseme:
> > > Creating
> > > releases. But it's just not targetted at tracking development.
> > 
> > So why not just fixing releaseme to remove those issues (which I see as
> > small)?
> 
> it would be possible to fix the "noisiness" of releaseme. I do not see any
> obvious way for a significant speed-up (the slowness comes from picking lots
> of individual files from individual directories, i.e. a lot of SVN
> transactions). I do not see a good way of making fetching translations a
> trivial operation to an external user, short of copying releaseme into the
> project repo (which has similar issues to copying the .po's).
> 
> > Is the goal here:
> > User launch script -> find a source directory with translations -> compile
> > it?
> 
> I'm trying to cover several use cases, here:
> - User want's to follow git
> - Developer want's to follow git, and give translation xy a try
> - Make it easy to set up builds from the repo (master, branch, or tag) in
> build systems that support it (macports, emerge, ...). _Without_ the need to
> copy in releaseme. There are limits on what scripts can _reasonably_ be
> integrated into a build recipe.
> - As an important sub-item of that, support "recipe" builds on launchpad
> (which rest on importing one or more repos and running the debian rules on
> them).
> 
> > Release scripts partially cover this, it's mostly a matter of changing the
> > output
> 
> Output is the least of the problems, here. The central problems are:
> - Dependency on a significant chunk of logic to download from a separate
> repo - Multi-minute wait on any message update.
> 
> > It's much easier IMHO then duplicating content in SVN, which I would
> > personally oppose.
> 
> Easier only in that releaseme already exists, my suggestion does not yet.
> It's essentially just copying files around.
> 
> I do see that there are other reasons going against copying files in SVN.
> Solutions without that requirement would not be hard to come up with (simply
> export to some non-versioned but rsyncable location would be one of them).
> SVN would have the advantage of being easily importable on launchpad, which
> is why my suggestion assumes that.

Sincerely, i don't see ourselves having yet another copy of the translations 
in another part of SVN.

Other option is just asking sysadmin to run releaseme nightly on some server 
and storing it in ftp.kde.org.

Cheers,
  Albert

> 
> Regards
> Thomas

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]