Future releases

[Boudewijn Rempt]

I've made a new test tarball today, and put it on my own web server since I
didn't want to repeat the problems with the one I put on downloads.kde.org:

http://www.valdyas.org/~boud/calligra-3.0.0.1.tar.xz

Extra weirdness: last week, during the krita release, I could use gpg to sign,
this week, with no updates or whatever, and the same plasma 5 environment,
signing fails again:

boud at thinkstation:~/kde/src/createtarball> gpg2 --output calligra-3.0.0.1.tar.xz.sig --detach-sig calligra-3.0.0.1.tar.xz

You need a passphrase to unlock the secret key for
user: "Boudewijn Rempt <foundation at krita.org>"
4096-bit RSA key, ID 722EA3BD, created 2016-09-06

gpg: problem with the agent: No pinentry
gpg: no default secret key: Operation cancelled
gpg: signing failed: Operation cancelled

And gpg-agent is running:

boud at thinkstation:~/kde/src/createtarball> ps ax | grep gpg-agent
 1806 ?        S      0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 /etc/X11/xinit/xinitrc
 1808 ?        Ss     0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 /etc/X11/xinit/xinitrc
 1809 ?        Ss     0:00 /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/boud/.gnupg/agent.info-thinkstation:0 /etc/X11/xinit/xinitrc
On Tue, 20 Dec 2016, Dag wrote:

> I'd like to discuss how to handle future releases, we don't want to continue
> to burden Boudewijn with it.
> 
> To summarize, I see two problem areas:
> - Who can generate the final release tarball. (pnt 4 below)
>   It must be someone with a trusted pgp key (I'm not trusted, so can't do it).
>   It should take <30 minutes, so is there somebody out there who could help?
> 
> - Somewhere to upload tarball for testing/checking before released to
> download.kde.org.
>   I thought about ftp://upload.kde.org/incoming but I don't think that is
> possible?
> 
> To ensure (as much as possible) that things will go smoothly I'm working on a
> release script
> and also plan to add more autotesting of the messages generation framework.
> We can't have another mess like this time.
> 
> So I propose a release cycle like this:
> 
> 1. ~2 weeks before release; string freeze and feature freeze
> 2. Closer to release some of us (I) create tarball, test and check if ok.
> 3. When ok, tag git
> 4. Create release tarball, upload for testing
> 5. Somebody (I) download tarball, build and test to verify it is ok
> 6. Publish tarball on download.kde.org (or possibly upload.kde.org)
> 7. Notify packagers and wait some time (a week?) for feedback
> 8. Announce to the world
> 
> What have I missed?
> Solutions (and comments) are welcome
> 
> Cheers,
> Dag
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org