Kevin and Justin, This is spot on.
Disclaimer, signatures/checksums, Apache license, and a start to notes are the minimum. Acceptance of issues to fix is also a requirement. Full compliance with Apache Release and Distribution Policies are some of our agreed Incubation requirements for graduation recommendation. Do we need to confirm all requirements or should we limit to this discussion to Releases? Regards, Dave Sent from my iPhone > On May 31, 2019, at 8:45 PM, Kevin A. McGrail <kmcgr...@apache.org> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
