From kde-i18n-doc Wed Nov 26 15:01:52 2014 From: Thomas Friedrichsmeier Date: Wed, 26 Nov 2014 15:01:52 +0000 To: kde-i18n-doc Subject: Re: i18n and direct builds from a source repository Message-Id: <2314983.VlUo7W05OH () late> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=141701413811653 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart6848856.NFIfkmvZXV" --nextPart6848856.NFIfkmvZXV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi, On Wednesday 26 November 2014 14:43:32 Luigi Toscano wrote: > On Wednesday 26 of November 2014 14:09:36 Thomas Friedrichsmeier wrot= e: > > 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 tha= t may > > just work, if you are really familiar with KDE infrastructure. rele= aseme > > is > > a great way for extragear apps to (among other things) fetch transl= ations, > > but - as the name is already indicating - is quite obviously _not_ > > targetted at casual curious bystanders: It is a rather complex addi= tional > > step for users to take - unless of course they are already knee-dee= p 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 n= ot 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: C= reating > > releases. But it's just not targetted at tracking development. >=20 > 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=20 obvious way for a significant speed-up (the slowness comes from picking= lots=20 of individual files from individual directories, i.e. a lot of SVN=20 transactions). I do not see a good way of making fetching translations = a=20 trivial operation to an external user, short of copying releaseme into = the=20 project repo (which has similar issues to copying the .po's). > Is the goal here: > User launch script -> find a source directory with translations -> co= mpile > it? I'm trying to cover several use cases, here: =2D User want's to follow git =2D Developer want's to follow git, and give translation xy a try =2D Make it easy to set up builds from the repo (master, branch, or tag) = in=20 build systems that support it (macports, emerge, ...). _Without_ the ne= ed to=20 copy in releaseme. There are limits on what scripts can _reasonably_ be= =20 integrated into a build recipe. =2D As an important sub-item of that, support "recipe" builds on launchpa= d=20 (which rest on importing one or more repos and running the debian rules= on=20 them). > Release scripts partially cover this, it's mostly a matter of changin= g the > output Output is the least of the problems, here. The central problems are: =2D Dependency on a significant chunk of logic to download from a separat= e repo =2D Multi-minute wait on any message update. =20 > 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 ye= t. It's=20 essentially just copying files around. I do see that there are other reasons going against copying files in SV= N.=20 Solutions without that requirement would not be hard to come up with (s= imply=20 export to some non-versioned but rsyncable location would be one of the= m). SVN=20 would have the advantage of being easily importable on launchpad, which= is why=20 my suggestion assumes that. Regards Thomas --nextPart6848856.NFIfkmvZXV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlR162QACgkQEKRv+5DVNhgcmACfZ+b5wnkUfGr95U37tJiLFHR2 PH4An2k1kP4HR2wrlwhSPB9oEUBi9R3W =9Z/1 -----END PGP SIGNATURE----- --nextPart6848856.NFIfkmvZXV--