On Mon, Dec 30, 2013 at 9:09 AM, Albert Astals Cid <[email protected]> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/release-team Thanks, Ben _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
