On Wed, Aug 7, 2013 at 5:48 AM, Daniel Shahaf <danie...@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
