Packaging scripts for frameworks

[Albert Astals Cid]

El Dissabte, 28 de desembre de 2013, a les 16:36:24, David Faure va escriure:
> On Saturday 21 December 2013 12:38:17 Albert Astals Cid wrote:
> > Can I suggest removing the tr() calls in ThreadWeaver? As far as I can see
> > they are only in setObjectName and in tests, not very useful really, so
> > it'd be good if you can remove them and then we can say "i18n is done"
> > since basically there's none to do :D
> 
> Done.
> 
> > We kind of have three, they are the PACKAGING_HOWTO, RELEASE-CHECKLIST and
> > RELEASE_PROMOTION files from the release-tools.git. I'd say the ones from
> > the 4.12 branch are the most up to date.
> 
> Thanks.
> 
> You'll merge this into master at some point?

I guess yes, was waiting for Torgny/other people opinion on them, since they 
are not what we used to use (i.e. master and 4.11 are the "old" ones). If you 
can have a look at the old ones and agree the 4.12 ones are simpler, it'd be a 
good thing to help me merge them to master.

> I have the patch below to commit, but apparently no permission to push, can
> I get that?

Ask it to someone that knows how to do that :D Sysadmin?

> 
> --- a/RELEASE-CHECKLIST
> +++ b/RELEASE-CHECKLIST
> @@ -20,3 +20,7 @@ For each release (i.e. x.y.z)
>   * kopete/libkopete/kopeteversion.h - KOPETE_VERSION_*
>   * kdepim/CMakeLists.txt - KDEPIM_DEV_VERSION / KDEPIM_VERSION
>   * kdepim-runtime/CMakeLists - KDEPIM_RUNTIME_DEV_VERSION and
> KDEPIM_RUNTIME_VERSION +
> +For KDE Frameworks releases
> + * */CMakeLists.txt - KF5_VERSION
> + * kservice/src/sycoca/ksycoca.cpp --> KSYCOCA_VERSION
> 
> $ git push
> FATAL: W any sysadmin/release-tools dfaure DENIED by fallthru
> (or you mis-spelled the reponame)
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.

Where do you want to push that master? or a kf5 branch?

> > I still don't have a script for creating a tag in the git repo since git
> > does not allow tag creation without a clone so you'd have to use the info
> > that is written to the versions/ folder manually. (Well actually I do have
> > a ugly script that does the git tags and assumes I have a clone in a
> > certain path, i guess i could try to clean it up and put it up there too
> > if
> > we end up deciding it makes sense for you to use these scripts)
> 
> Ah, the new scripts don't even do a local clone anymore since they use git
> archive.... maybe they should still make a local clone, for the purpose of
> tagging? Otherwise ok for using the existing clones.

The awesomeness of not using an existing clone for the archiving is that you 
don't mess up with some local changes you may have had for the tagging, the 
old scripts sorted that out by forcing you to have a separate "clean" 
checkout, but even with that it has happened that we fucked up something, 
that's why i went the git archive route. Tagging on the other hand is kind of 
hard to make a mistake even if you use an existing clone since it's just about 
tagging an existing hash.

> I also see that the source tarballs are .tar.xz, but Windows users would
> surely prefer the option to use .zip files ...  which requires another `git
> archive`, or to zip the local clone.

If you don't want to stress the server much you can always untar and zip it 
locally.

> In any case - yes, these scripts make a lot of sense, we should work on
> automating the tagging, and I can help with that.

This is the silly script i have, it needs some work to integrate it better 
with the exisitng stuff, but basically it does the job.

Cheers,
  Albert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: script-tag.sh
Type: application/x-shellscript
Size: 406 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/release-team/attachments/20131228/2340c050/attachment.sh>