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. Regards, KAM 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 issues. > > 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: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
