[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:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2014-11-26 15:01:52
Message-ID: 2314983.VlUo7W05OH () late
[Download RAW message or body]


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.

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

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