Perhaps one approach is to maintain a list of "release issues" which are deemed "minor offences". As long as there are bugs raised against such "release issues", then no further permission would be required. Anything outside the "minor offences" would require explicit permission.
As others have mentioned, such release bugs would be labelled as blocking for graduation. Ideally the bug ticket numbers would be listed in a disclaimer file within the release. This would make it easier for reviewers and act as a reminder for project members and users. IANAL, but I think it would help too in terms of legal shield etc. to have such a file within the release not just a generic disclaimer "on some web site at one point in time". Cheers, Paul. On Tue, Jun 4, 2019 at 7:16 PM Justin Mclean <justinmcl...@me.com> wrote: > Hi, > > > Historically, demonstrably, we have applied a different policy to > "podling > > releases" that is a bit more lenient. Once the podling graduates, it must > > conform to the formal Apache release guidelines. > > 1. There is no seperate incubator release policy for podling/IPMC > releases, well no formal written down one anyway. > 2. The IPMC does currenly give podlings a lot of leeway and treats IPMC > releases differently to TLP releases. A look at recent IPMC release votes > will find +1 votes on issues that would probably be -1 on a TLP release. > > Perhaps read what going in the board report [1] (still draft) as I think > that captures it well. > > Thanks, > Justin > > 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019
