Re: Security patches release process

On Wed, Aug 7, 2013 at 5:48 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:

> (v3)
> - Receive report
> - Come up with a fix
> - Gather 3 +1 votes via shadow status file
> - Send pre-notifications
> - Release a signed .diff file (instead of a tarball) as 1.8.(x+1)
> - Commit fix with a log message clearly outlining the security implications
> - Backport without going via STATUS (already has 3 +1s)
> - Tag and roll 1.8.(x+2) whenever we had scheduled the next release to.
>

I'm okay with choice 3 - however, the "release a signed .diff" should also
include a full release - including whatever normal things we include with a
standard release process. If 1.8.(x+1) is *only* available as a diff
against 1.8.x, that makes it hard for downstream users (or packagers) until
1.8.(x+2) is released. -- justin
Received on 2013-08-07 12:50:24 CEST