On 13/02/11 13:48, Jelmer Vernooij wrote: > (Changing To: to the bzr-gtk mailing list) > > On Thu, 2011-02-10 at 09:09 +0000, Max Bowsher wrote: >> On 10/02/11 08:58, Jelmer Vernooij wrote: >>> On Wed, 2011-02-09 at 10:13 +0000, Max Bowsher wrote: >>>> There are a couple of problems with the bzr-gtk release process right now. >>> >>>> 1) The release process is documented at >>>> http://wiki.bazaar.canonical.com/bzr-gtk/releasing, but this is >>>> *incredibly undiscoverable* from the branch source code. I only found it >>>> because there's a reference to changing it in NEWS. >>>> >>>> Proposal: Move this documentation into the branch, as a file called >>>> RELEASING (or suggest alternative names) >> >>> I wouldn't mind merging it into the branch, but I also don't see the >>> issue with it at the moment. This page doesn't have to be particularly >>> discoverable - release managers are the only people who should care >>> about it, and new release managers get told about it. >> It's also of relevance to people trying to figure out how the official >> tarballs are built in order to understand bugs about missing files in >> them, and people pondering whether to volunteer to RM a release :-)
> Care to propose a MP that adds it to the branch. Will do. >>>> 2) bzr-gtk uses a file called 'credits.pickle', which is generated by >>>> bzr-stats. This needs to be done manually (by invoking 'setup.py >>>> build_credits') when building a release tarball, and has been forgotten >>>> twice in recent times: http://pad.lv/397526. Moreover, it means we can't >>>> do a daily recipe build of bzr-gtk (because we can't run arbitrary extra >>>> generation steps when building the source package, and we can't build >>>> the credits.pickle when building the binary package) >>>> >>>> Proposal: Just check the credits.pickle into the branch. Modify the >>>> releasing instructions to remind the release manager to manually update >>>> the checked in copy where they would normally build one just for the >>>> tarball. >> >>> Including credits.pickle in the branch seems reasonable, but why would >>> we leave it until the release to do so? I'd rather just update >>> credits.pickle every time we merge into trunk. > I'll propose an update to HACKING for this. > > It might also be interesting to start running an instance of tarmac that > can do this. Actually, now that we have a working recipe build, I'd favour leaving it out - having a generated file there was better than broken builds, but if we cover recipe builds via auto-generation, and release tarballs via clearer documentation for the RM, then I'd rather avoid having a binary(ish) file that won't merge well and just duplicates info from the branch history. Max.
signature.asc
Description: OpenPGP digital signature
-- bzr-gtk mailing list [email protected] Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/bzr-gtk
