incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Podling releases and release policy
Date Tue, 04 Jun 2019 10:47:09 GMT
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 <justinmclean@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message