Voting takes three days or less if we decide we need an emergency release for a security issue for example. In reality, it can take weeks for a release manager to volunteer for a given component, review code, PRs, Jiras, an so on, before going through all the hoops to create a release candidate and then the release. So, the buffer of time should never be automatic. The issue should be made public only after a release in the case of security issues.
Gary On Mon, May 3, 2021, 08:59 Stefan Bodewig <[email protected]> wrote: > Hi (Fabian) > > by now we've resolved the first issues detected by ClusterFuzz (and I > forgot to credit it OSS Fuzz in Compress, my bad). What we observed is > that the issues became public automatically once the patch fixing the > issue was merged into master and ClusterFuzz reran the test. In the case > of Compress somewhere around 24 hours after fixing things in master. > > So far none of the issues we resolved would be deemed as a security > issue. But now we wonder, what if something indeed was a security issue > that we do not want to become public knowledge before we have cut a > release? Is there a way to prevent a verified and fixed issue from > becoming public automatically? > > Here at the ASF we vote on releases, and we vote on the code base in our > default branch (master for most if not all components). Voting takes at > least three days, so the current behavior would mean the issue became > public knowledge a few days before a release fixing it was available. > > Can you shed any light on this? > > Thanks > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
