On Feb 11, 2014 3:29 PM, "Josh Elser" <[email protected]> wrote: > > I think I mentioned this earlier/elsewhere already, but I'd prefer better communication by parties interesting in testing so that when the RC is called, we already have the day+ duration tests already run. > > IMO I don't think the voting time is the right time to be trying to find "distributed system" level bugs. That should be time focused on judging the release itself -- packaging (tarball, rpm, debs, etc), ASF requirements (signing, hashes), scripts (init.d, bin/*), basic user interaction, and the like. >
For this to work, we'd need a better way to denote what's getting tested. An RC tag provides an easy reference. At the very least, we'd need to enforce having the release manager for the branch act as a gatekeeper on additional changes once a before-rc-release-testing-phase got started. This wouldn't require starting the next dev branches while we're handling a release. Instead, blocked changes could just be stored as patches on their relevant jiras. For example, Avro does this for breaking changes.
