incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin A. McGrail" <>
Subject Re: Podling releases and release policy
Date Sat, 01 Jun 2019 03:45:22 GMT
Hi Justin,

Before putting it to the board, have we ever had a IPMC vote on the
matter?  I think the board wants to delegate because legally, there
isn't a chance in hell they are going to vote on it any way but
negatively because to me, they have no choice but to formally say no. 
This is a possible example of purposefully turning a blind eye because
it's hard for podlings to come up to speed.

So perhaps if we set an incubator policy of a podling release being a
little more lenient, the board would delegate because the legal issues
are about nil.  It's like making a law where 20% of America is a
criminal.  Is it really enforceable and especially without prejudicial
or preferential treatment? 

What I like to see from a podling is: acknowledgment of the issues,
tickets on the issues, and consistent improvement.

What we cannot see is: a podling NOT saying "incubating" in a release or
saying no, we will not fix these issues.

Perhaps we need a podling disclaimer for all podling releases that
explains more about what is a podlings and what is an incubating
release.  Perhaps it can contain appropriate caveats that the release
may have issues that are being worked on that up to and including
licensing issues.  Links to Jira as well would be good.  Then if we
enforce tickets about known issues, we can both hold podlings
accountable and enlighten users about the risks.

I agree there are some examples where podlings are pushing our good
faith on not fixing issues.  But there are others that are just
overwhelmed and we need to help more with the podlings where English is
a second language.  Perhaps something to ask the new D&I committee to
assist with.  Lots of discussion about overcoming language barriers of
late on board-chat too.

On 5/31/2019 11:28 PM, Justin Mclean wrote:
> Hi,
> It been suggested a few times by several people on several lists that podling releases
(particularly early one’s) don’t need to comply with release and distribution policy even
if they have serious issues. The question has been asked to the board several times but we’ve
never got a clear answer (as the question is hypothetical) or the answer is no that’s not
allowed. The incubator does not set those policies, the board and infra do. I’m going to
ask the board to give us a clear answer on this to see if they are OK to grant an exception
to those policies for podling releases and if our current DISCLAIMER covers those sort of
> Anyone have anything to add or any objections to this before I ask them?
> The serious issues I’m talking about here include compiled source or inclusion of GPL
(or other Category X) code in a source release or a Category X dependancy or include code
that the podling doesn’t have permission to distribute i.e.  the ones that people constantly
vote -1 for. Last time I calculated the stats for 300+ released I found 1 in 5 podling releases
had a serious issue like this.
> If the board (and infra) does say this is OK, podlings would still have to have releases
that copy with policy on graduation, so this puts more responsibility on the mentors and the
projects themselves. Worse case the IPMC may have to reject graduation of a project that hasn’t
got its releases in order.
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project - 703.798.0171

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message