RE: Insanity (of the release process)
1) PPMC must vote for the release according to their rules (which should at least match the 3 +1 / majority rule requirements) 2) at least one PMC member must vote +1 (usually the mentor) Well.. let's call this the expedited form of release. It leaves the PPMC a bit more self-sufficient. I don't believe that this flies. The PPMC is an Incubator artifact, not part of ASF legal governance. I'd really want Roy to review some of this thinking. The real question is just how far the Incubator PMC can delegate their oversight and authority. Exactly. Mind you, I don't believe that getting 3 +1 votes has been a real issue of late, and personally, I would vote against the proposal because in many cases, when a new project brings up a release vote to the PMC and people have looked at the release artifacts, issues are found and fixed. And such problems are not code related, they are IP related. Later releases don't suffer from the issues. This seems a good thing. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
Leo Simons wrote: Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. Mechanically, it's possible to recharter Incubator PMC as a board committee which has the authority to assemble and dissolve fully empowered PPMCs so they could begin binding votes from the outset. The 'P' would change from 'pre' to 'provisional'. I don't know if this is what we want to do, or not. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Leo Simons wrote: Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. Mechanically, it's possible to recharter Incubator PMC as a board committee which has the authority to assemble and dissolve fully empowered PPMCs so they could begin binding votes from the outset. The 'P' would change from 'pre' to 'provisional'. I don't know if this is what we want to do, or not. The Board is trying to move away from Board committees. 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. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein gst...@gmail.com wrote: On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Leo Simons wrote: Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. Mechanically, it's possible to recharter Incubator PMC as a board committee which has the authority to assemble and dissolve fully empowered PPMCs so they could begin binding votes from the outset. The 'P' would change from 'pre' to 'provisional'. I don't know if this is what we want to do, or not. The Board is trying to move away from Board committees. 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. Ok, that is interesting (and probably more workable than a big reorg). I still think we should claim liability. Could we, for example, have a release process that is lazy-by-default from the IPMC side and still claim that the ASF gets liability? for example, to release: 1) PPMC must vote for the release according to their rules (which should at least match the 3 +1 / majority rule requirements) 2) at least one PMC member must vote +1 (usually the mentor) 3) if there are no -1 votes, the PPMC sends the general@ list a request for a release ACK, after they get that ACK from a PMC member, they wait for 72 hours, and if there are still no -1s, the release is approved. 4) if there are any -1 votes, then the rule becomes the normal 3 +1s from PMC members / majority Downside: * more complex * increased dependency on single person to teach the basics Upside: * better reflects relationship between incubator and PPMC * more responsibility for project * hopefully fewer stalled releases thoughts? Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
I like Leo's proposal. With PMC members mentoring multiple projects, it is really a burden to try and get 3 votes for a release. Shanti Leo Simons wrote: On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein gst...@gmail.com wrote: On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Leo Simons wrote: Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. Mechanically, it's possible to recharter Incubator PMC as a board committee which has the authority to assemble and dissolve fully empowered PPMCs so they could begin binding votes from the outset. The 'P' would change from 'pre' to 'provisional'. I don't know if this is what we want to do, or not. The Board is trying to move away from Board committees. 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. Ok, that is interesting (and probably more workable than a big reorg). I still think we should claim liability. Could we, for example, have a release process that is lazy-by-default from the IPMC side and still claim that the ASF gets liability? for example, to release: 1) PPMC must vote for the release according to their rules (which should at least match the 3 +1 / majority rule requirements) 2) at least one PMC member must vote +1 (usually the mentor) 3) if there are no -1 votes, the PPMC sends the general@ list a request for a release ACK, after they get that ACK from a PMC member, they wait for 72 hours, and if there are still no -1s, the release is approved. 4) if there are any -1 votes, then the rule becomes the normal 3 +1s from PMC members / majority Downside: * more complex * increased dependency on single person to teach the basics Upside: * better reflects relationship between incubator and PPMC * more responsibility for project * hopefully fewer stalled releases thoughts? Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 11:22, Leo Simons m...@leosimons.com wrote: On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein gst...@gmail.com 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. Ok, that is interesting (and probably more workable than a big reorg). I still think we should claim liability. Could we, for example, have a release process that is lazy-by-default from the IPMC side and still claim that the ASF gets liability? Unfortunately, no. The IPMC has to be *active* in some way, in order to show oversight and responsibility. So the lazy-by-default won't work. But your suggestion below might. for example, to release: 1) PPMC must vote for the release according to their rules (which should at least match the 3 +1 / majority rule requirements) 2) at least one PMC member must vote +1 (usually the mentor) This basically states, The PPMC has followed our guidelines and processes, has been conducted under the purview of the IPMC, and at our direction. The IPMC hereby directs the PPMC to continue with their release. 3) if there are no -1 votes, the PPMC sends the general@ list a request for a release ACK, after they get that ACK from a PMC member, they wait for 72 hours, and if there are still no -1s, the release is approved. 4) if there are any -1 votes, then the rule becomes the normal 3 +1s from PMC members / majority Any -1 votes within the PPMC or from the IPMC should be a trigger. Downside: * more complex * increased dependency on single person to teach the basics Upside: * better reflects relationship between incubator and PPMC * more responsibility for project * hopefully fewer stalled releases Well.. let's call this the expedited form of release. It leaves the PPMC a bit more self-sufficient. I'd think that any first release would follow the standard release mechanic. After that, the expedited can be used unless a -1 arises. At that point, they have to follow the standard process (even if it all restarts). After that release concludes, they can switch back to expedited. I'd really want Roy to review some of this thinking. The real question is just how far the IPMC can delegate their oversight and authority. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
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. Again, I still am not suggesting we want to take this one way or another. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
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. -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
(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
Re: Insanity (of the release process)
On Mon, Nov 9, 2009 at 3:24 PM, Justin Erenkrantz jus...@erenkrantz.com wrote: On Mon, Nov 9, 2009 at 4:03 PM, Leo Simons m...@leosimons.com wrote: Also, to be clear, as an IPMC member I spend quite a bit of time with projects where I am not a mentor, casting (binding) votes on things like their releases. I will continue to do that, inline with procedure and policy and common sense. I'm pretty sure you're not really meaning to question that :) This is where I think the Incubator has gone awry: the claim that you are an IPMC member implies that you have merit on a project (in the form of a binding vote) is false. Not merit, just binding vote. I agree that it sucks, but it is not something where the incubator has gone awry, it has _always_ been messed up like this. Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC 4) a lot of incubating projects have difficulty getting enough +1s, or even any qualified help sorting out releases 5) from #3 and #4 it follows that a lot of incubating projects get stuck 6) since #5 sucks rather badly, I and many others try and fill this gap so projects can do some releases, attract some attention, gain critical mass, and get out of here 7) we have further optimized by making the incubator PMC very very large and by making it really easy (for ASF members) to get on the incubator PMC, creating a large pool of potential voters. If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. ciao, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Mon, Nov 9, 2009 at 11:16, Leo Simons m...@leosimons.com wrote: ... Not merit, just binding vote. I agree that it sucks, but it is not something where the incubator has gone awry, it has _always_ been messed up like this. Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s I think those -1s are more where Justin in concerned, rather than a bunch of IPMC people jumping in with *support*, providing a +1 where a podling doesn't have enough active IPMC members. It's the *negative* support -- the hurdles and process and checklists, some of which make zero sense for the particular podling. These can be just as bad as a bunch of people jumping in with -1 votes. For example: make a release. If that doesn't make sense, then why does it imply a bunch of -1 votes from the IPMC to prevent graduation? Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Mon, Nov 9, 2009 at 4:48 PM, Greg Stein gst...@gmail.com wrote: On Mon, Nov 9, 2009 at 11:16, Leo Simons m...@leosimons.com wrote: ... Not merit, just binding vote. I agree that it sucks, but it is not something where the incubator has gone awry, it has _always_ been messed up like this. Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s I think those -1s are more where Justin in concerned, rather than a bunch of IPMC people jumping in with *support*, providing a +1 where a podling doesn't have enough active IPMC members. It's the *negative* support -- the hurdles and process and checklists, some of which make zero sense for the particular podling. These can be just as bad as a bunch of people jumping in with -1 votes. Yes, it is really bad. But in some cases, what is the alternative? Given this situation: *) project has rolled a release and voted on it (+1s everywhere, yay, cool stuff!) *) one mentor has voted +1 (well done folks) *) wait for other mentors, no response *) the project comes to the general@ list to ask for additional votes *) I look at the release candidate, and I find a reasonably serious problem (usually legal crap, for example, let's say it ships LGPL code) What would you expect me to do at that point? This is a pretty common situation, and it sucks to be in it, for everyone. Some options: 1) don't say anything, let someone else deal with it 2) explain the problem, don't vote. This typically results in the vote stalling (because no-one else is going to vote +1 after I've pointed out the problem). 3) explain the problem, vote -1. This typically is enough to kill the vote (because no-one else is going to vote +1 after I voted -1). 4) don't say anything, vote +1, claim ignorance later if someone points out the problems. 5) explain the problem, vote +1, ask that the project fixes it later (but can't claim ignorance...). a) one of the above, and also go poke the AWOL mentors for not doing their part (usually followed by mentor resigning, or staying AWOL) I would like to have option #5 be a realistic option, but it requires that I have some ability to do a legal risk assessment (and a brief to take those risks), which I don't. So usually I go for #2 or #3. That's not me being a pencil-licking process-loving bureaucrat, it is me trying to make the best of a messed-up situation. I can try very hard to write my e-mails nicely (and I do), but usually at this point in the time the EDUCATION is just not well-received because it is tied to NOT ALLOWING THE RELEASE. There is no carrot, just a stick. I don't know what Justin was talking about, but I will bet you that a significant part of the friction that incubating projects experience is due to some variant of the above scenario [1]. Can you think of a way to fix the mess? cheers, Leo [1] That, and AWOL mentors - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
