incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Approving flawed release candidates
Date Thu, 16 Feb 2017 01:26:26 GMT

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?"

   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

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:
For additional commands, e-mail:

View raw message