(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 <gst...@gmail.com> wrote: > On Tue, Nov 10, 2009 at 13:11, William A. Rowe Jr. <wr...@rowe-clan.net> > 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
