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
