incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <>
Subject Re: Insanity (of the release process)
Date Tue, 10 Nov 2009 20:35:07 GMT
(i'm really short of time ATM so apologies in advance if i'm very slow
to respond)

On Tue, Nov 10, 2009 at 6:18 PM, Greg Stein <> wrote:
> On Tue, Nov 10, 2009 at 13:11, William A. Rowe Jr. <> wrote:
>> Greg Stein wrote:
>>> The IPMC is in charge of its operation. It can redefine the rules of
>>> releases as it pleases. The three +1 rule was developed to show that
>>> the PMC is "in charge" of the release, and is therefore legally liable
>>> for it. The IPMC can do whatever it likes around releases, as long as
>>> that process specifically claims or disclaims liability.
>> The only individuals empowered to act on the foundation's behalf are
>> members of committees.  With the exception of board committees which
>> are empowered to form subcommittees, all such individuals must be
>> ratified (either by resolution or our favorite ACK game) by the BoD.
>> A vote by 3 PPMC members is therefore not binding, not unless the board
>> is prepared to ack/nak all appointments to PPMC's within Incubator.
> Understood. Nobody proposed that. I believe you missed the part of
> another +1 from an IPMC member.

IMHO the problem with getting 3 +1's is the time commitment required
from reviewers. i estimate that helping a project get the first
release right involves about 10 hours of my time. if i was certain
that the release process and code had been well been well audited then
i could be confident that i could just re-run the automated checking
tools, take a look at README to answer any questions and review the
mailing list to check that the PPMC was following it's own process.

i think (see below) that this could be achieved if the IPMC required
that a number of pre-requisites were passed (in order) before a
release was allowed:

1. all licensing issues resolved to IPMC's satisfaction
2. full source audit approved by IPMC
3. full artifact audit approved by IPMC

if this were done and documented then approving a release would only
involve checking that the PPMC followed it's own rules and could be
much more lightweight.

it would mean creating a less flexible track for podlings with
multiple hurdles. not sure whether that'd be better or not.

- robert

licensing issues
the legal team only approve licenses on demand. so, any licenses new
to apache need to be reviewed and categorised. usually, licenses are
first audited at release time. so, it's common for podlings to have
first releases rejected and told to go away and ensure all licenses
are approved but there's no real reason why this needs to happen.

the most efficient process would be for mentors to collect licenses
referenced by the code, compare each to the rules then propose a patch
adding the license to the appropriate classification.  this could all
be done before or on entry.

[source audit] headers etc
the bit everyone gets wrong is writing down the licensing for every
file that can't have a header so that auditors understand the
provenance of the file. the routine should be either to add a header
or add the file to some document.

this could be fixed by a source audit at any time by experienced
reviewers. IMHO it would be more convenient to schedule a source audit
window (a few weeks long) asking IPMC reviewers to +1 the source
before thinking about a release.

(IMO the ideal would be to run the automated reviewer on every project
and then post failure emails to this list but i ran out of energy for
this idea.)

[artifact audit] notices etc
there are a number of fiddly reporting requirements that are required
for apache releases. there isn't precise consensus on best practice
and the rules set out principles. so, there's a lot of scope for
arguments between members. this is doubly annoying for podlings. it's
unheard of for this to be done exactly right first time (and i suspect
that many apache projects wouldn't pass an IPMC audit on this one).

auditing this requires release artifacts but providing that the
podling has a solid, documented build process for releases then this
could be audited without a live release. IMHO again, the best approach
would be an audit window (after the source audit) for checking the
release artifact.

(IMO the  ideal process would be to integrate automated artifact
checking into the build bot stuff but again, i don't have the energy
to push this forward)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message