Packaging scripts for frameworks

[Ben Cooksley]

On Mon, Dec 30, 2013 at 9:09 AM, Albert Astals Cid <aacid at kde.org> wrote:
> El Diumenge, 29 de desembre de 2013, a les 20:05:20, David Faure va escriure:
>> On Saturday 28 December 2013 17:34:35 Albert Astals Cid wrote:
>> > 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.
>>
>> Yes, actually I tried the old ones first, since I had a master checkout and
>> initially forgot your recommendation to use 4.12.
>>
>> I agree that the 4.12 scripts are easier because they automate more things.
>>
>> I just had to disable the call to pack_l10n.sh since there's no l10n for
>> frameworks yet, apart from that it works great.
>>
>> > > 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?
>>
>> Yep, Ben was CC'ed in my previous mail :)

Which repository do you need commit access to?
sysadmin/release-tools I presume?

>>
>> > Where do you want to push that master? or a kf5 branch?
>>
>> 4.12, since that's what I was using, but with the idea of it getting merged
>> to master at some point.
>
> I think you should create a kf5.0 branch in the repo, that way you can kill
> the pack_l10n.sh and put the correct branches in the modules.git file, etc.
>
>>
>> > 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.
>>
>> Yep, exactly my thinking too.
>>
>> > > [providing ZIP sources for Windows users]
>> >
>> > If you don't want to stress the server much you can always untar and zip
>> > it
>> > locally.
>>
>> Oh. Great idea, thanks.
>>
>> What do you think about the doubled space requirements on the server though?
>> Well, maybe that's a question for sysadmin too...

A full copy of the XZ compressed tarballs, excluding Oxygen is 800mb
for an entire SC release.
Any ideas on what Zip compressed archives would take up in terms of space?

I do know that there are quite a few decent archiver programs for
Windows which do support tar and friends - so not sure if this is too
much of an obstacle.

In any case, another gigabyte for each release isn't much of a
problem, we'll have to archive releases sooner though - but we really
only need to offer the latest old stable, current stable series and
latest development release in any case.

>>
>> > > 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.
>>
>> OK, I'll look at that when doing the actual release.
>>
>> I guess it should not be triggered by the main pack_all.sh script though,
>> since that's "safe to play with locally" while tagging (and pushing the
>> tags) is for real, so I'll make it a separate tag_all.sh script.
>
> Yep. Also we usually do the tarballing, give them to packagers and then only
> tag on release (which is a few days later) in case we need to redo the
> tarballs, so pack and tag should be different.
>
> Cheers,
>   Albert
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team

Thanks,
Ben