Hi Marvin, I don't think there's anything you're stating here that isn't in accordance to processes we have been following. If I look at the current Traffic Control vote, the problems I see are:
- Assertion from the podling that they fixed the release, and votes from mentors indicating they fixed the prior release problems, but in actuality many of them are not fixed. - In the prior release vote (and I apologize, I missed that there was an RC8 passed our way), questions were raised by Justin asking for JIRA tickets for the open issues that were not addressed, without any response (hence I can only assume no JIRAs were filed) In general, I think what you're describing is what we're following. Its the uncommon case where an imperfect release is being revoted on, mostly because of the podling not following up with questions. I'll point out that the Singa vote is one where I feel the current legal advice is vague enough that I cannot make a clear statement whether or not allowing the release would put any legal strain on the ASF, in addition to it being vague enough on what we consider a build tool, or how to interpret the autoconf headers. One way to look at it - the ASF would produce GPL'd code which is a big no-no (and I wouldn't think would be acceptable as a JIRA ticket to fix later). - John On Wed, Feb 15, 2017 at 8:27 PM Marvin Humphrey <mar...@rectangular.com> wrote: > Greets, > > We take pains to advise downstream consumers that podling releases are > "incubating" because they may not live up to the standards expected of > Apache TLPs -- whether that is because the community is not mature, > because the release is not fully compliant with ASF policies, or what > have you. > > A while back, the IPMC arrived at a consensus about the circumstances > under which we might approve incubating release candidates which are > legal to distribute yet do not fulfill all aspects of Apache policy. > A test was proposed by IPMC member and ASF Board member Bertrand > Delacretaz: "Does it put the Foundation at risk?" > > https://wiki.apache.org/incubator/January2014 > > 3. Consensus was built for a controlled regime for relaxing policy on > incubating releases under appropriate circumstances, potentially > reducing the number of release candidates we force podlings to > cycle through. > > The first release candidate approved under that relaxed regime bundled > jar files in the source release. The podling promised to remove them in > the next point release (and subsequently followed through): > > * Exercising the new regime for controlled relaxation of policy, a > bugfix release by Spark (0.8.1) which bundled jar files was approved > by the IPMC after the podling presented a roadmap to eliminating > them in the next minor point release (0.9). > > For IPMC members evaluating a flawed release candidate (whether Mentors > or "freelance" IPMC reviewers on general@incubator), perhaps consider > the following workflow: > > 1. When policy violations which do not put the Foundation at risk > are discovered in an RC, vote -1 until tickets are filed. Once > they're filed, change vote to +1. > 2. If a release candidate has policy issues which were brought to > light on a previous RC and should reasonably have been fixed > already, vote -1. (We may be tolerant but we're still serious.) > > In particular, there are two common classes of problem that I think can > be handled this way: > > The first is licensing documentation bugs, such as missing "forwarded" > dependency licenses in LICENSE, and extra junk in NOTICE. (Actual > licensing violations which make the RC illegal to redistribute are a > different story.) > > The second is bundled compiled code, such as jar files. I've written at > length elsewhere on why we exclude these systemically (as have others > such as Roy Fielding), but they are a policy issue rather than a legal > issue. > > Finally, there's one other common case worth mentioning which requires > slightly different treatement: dependencies with unapproved licenses. > These may be OK for incubating releases, but first require approval by > VP Legal. > > Incubation disclaimers give us the flexibility to bring podlings into > compliance incrementally. At the same time, because podlings may not be > in compliance, incubation disclaimers are important -- two sides of the > same coin. > > Marvin Humphrey > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
