I agree. For example it would help heaps if there was a list of violations podling releases make, and which are immediate showstoppers and which need to be noted (filed as tickets) and fixed in a release before graduation.
Certainly, having that list would help land this discussion a bit better. Justin, I think above all others you are the one sitting on a ton, the real wealth, of knowledge here. I appreciate the need to "know exactly what the rules are", but culturally I hope the emphasis remains on figuring out how the incubator can improve at helping podlings get to and through graduation without having to police them along the way. A lot of work has gone into improving the Incubator recently and it has been very much appreciated. I'm uncertain though as to whether seeking such explicit approval from the board and infra is but in the spirit of further policing podlings, or if in putting at ease some of the more serious concerns that the incubator has it allows it to better focus on what services it can better provide. I can't speak for all, but I know some folk really get the benefit from the public praise of catching podlings doing it right. The incubator's documentation isn't perfect, and it'll also be shifting sands and slightly out of date, so making it easy for newcomers in the incubator to know what are the good examples to be learning from always goes a long way. regards, Mick On Sat, 1 Jun 2019, at 13:55, Dave Fisher wrote: > 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
