On 10/11/13 09:04, ant elder wrote:
How about simply changing the rules for Incubator releases so that they don't require at least three binding votes, but instead make it at least three votes only one of which must be binding. That would mean there would still be the element of oversight that a mentor vote gives but avoids all the problems with not having three mentors. I'm sure the board would grant the Incubator authority to implement that change....ant
Having some mechanism to give real, effective value to the PPMC votes seems like an excellent idea. Whether it is this exact proposal or something else, I don't know. At the moment, the PPMC votes are not essential which I find a bit odd.
Maybe make some/all the mentor votes being votes on the process of the release (IP checking included), not the content. (Or maybe different mentor vote classes is just complexity.)
Doing IP the first time seems to come a surprise for podlings (in my very limited experience). But once one or two people on the PPMC "get it", it's time to handover that responsibility to the PPMC.
Andy
On Sun, Nov 10, 2013 at 8:00 AM, Alex Harui <aha...@adobe.com> wrote:IMO, there are two problems: 1) We're trying to train folks to manage IP for their community but they have to seek approval from folks are aren't as vested in their community. My analogy is telling a new city council member: "Welcome to the city council. For the next year all of your decisions will require ratification by 3 state senators". 2) Release voting takes a long time. It would seem like tools should be able to reduce the time on several of the steps, except for this one from [1] "compile it as provided, and test the resulting executable on their own platform". Sometimes I think about trying to get on the IPMC and helping some podling get a release out but: A) Really, I just want to help check the legal aspects of a podling's release and don't have bandwidth to want to take on the other roles implied by being on the IPMC. B) I don't want to take the time to figure out how to build and test a release that I have no vested interest in. Now, incubating releases are not official releases, right? So why have such time- consuming requirements to get approval from the IPMC? Let's assume that the podling folks tested the building and operation of the source package. Could we build an ant script that any IPMC member or any PMC member from any TLP (to expand the pool of potential helpers to folks who supposedly know how) can run just to check: 1) source package has the name "incubating" 2) source package is signed 3) unzip source package 4) grab a tag from SVN/Git 5) Diff 6) Run Rat (without any fileset exclusions) Then some podling writes to general@ and says: "can we get legal approval to release? Please run the release checker ant script with the following inputs <url to package> <url to SVN/Git> <tag>" Then it could run while I read through all of the other ASF emails and eventually I get a report that contains mainly a list of non-Apache files in the RAT report that I review and comment on if needed. To me, if you're reviewing a RAT report, you are a building inspector who has looked around inside. Can we make it that "simple"? For sure, if any podling member is qualified for IPMC before graduation they should be nominated and added, and I suppose we could also approve them to cast binding votes as a release checker which may be a lower bar and maybe less of a time commitment, but I think if it is possible to have a larger group of folks approve incubating releases mainly be reviewing RAT reports that might make it easier for a podling to get a release out the door and still assist in the training of the podling's future PMC members. [1] http://www.apache.org/dev/release.html#approving-a-release My two cents (probably more), -Alex On 11/9/13 9:38 PM, "Marvin Humphrey" <mar...@rectangular.com> wrote:On Sat, Nov 9, 2013 at 4:11 AM, Dave Brondsema <d...@brondsema.net> wrote:On 11/09/2013 02:23 AM, Jake Farrell wrote:If mentors are not performing their duties to vote on a given releases for a podling, then it is up to the IPMC as a whole to help that podling by doing the do diligence and casting a vote. We all asked to be apart of the IPMC or where honored by a nomination and accepted the role. It is up to us to show these podlings what the Apache was really means. These projects have all come to the ASF and we (the IPMC) have openly voted them into incubation, its up to us to help them succeed.While this is true in theory it's hard in practice to wrangle those votes together.That's not the only problem. While IPMC volunteers who perform "freelance" release reviews keep the Incubator from grinding to a halt, our reliance on them undermines the Incubator's effectiveness as an IP clearinghouse. I wish that we would redirect those volunteer energies elsewhere. IPMC members who vote +1 on an initial incubating release are endorsing the the code import and IP clearance process[1], as well as any work done in-house since incubation started. Votes on subsequent incubating releases are less weighty because they chiefly endorse work done in-house since the last release. Non-Mentors who swoop in at the last minute to vote +1 on a codebase they've never looked at produced by a community they've never interacted with are not in a position to make such endorsements, particularly for the first incubating release. They are like building inspectors who never go inside.Merit stands above all else, and the contributors that you have pointed out are all exceptional individuals that have advanced their projects and continued to do so after graduation within the ASF. There are no short cuts here, merit is earned. I am 100% behind helping individuals that show exceptional merit within a podling and deserve to be apart of the IPMC and have a binding vote.Yes, lets do this. No new structures, minimal risks.True. It seems that a number of people find this approach attractive. Let's focus on the challenges: 1. Candidates have to be nominated. 2. The votes have to pass. Not all of them, but most of them. In order for the votes to pass, those IPMC members who have misgivings will have to lay them aside. But maybe this isn't such a big problem, because my sense is that there are a number of candidates out there that even the skeptics would feel pretty comfortable with. I can't believe we let Marmotta escape the Incubator without nominating any of its contributors! So how do we solve the problem of nominating people? Ideally, Mentors would proactively identify and propose candidates -- even when, as would have been the case throughout Marmotta's incubation, the podling has no immediate need for additional Mentors. And maybe that will happen more often if it's less contentious. Still, there will be podlings where the nominations won't happen -- and here, maybe the IPMC at large can play a role. * Diagnose Mentor attrition sooner, using report sign-off and shepherd review. (Or even better, mailing list archive scans.) * Ping podling Mentors on private@incubator asking why the release manager who handled that last release so well hasn't been nominated. * ...The IPMC can fulfill their duty (when appropriate) by identifying people that merit IPMC membership, so less people will have to invest the significant effort of assessing all the many many details for new releases.Right now, when a release candidate shows up on general@incubator without three +1 Mentor votes, here's what we do: 1. First, wait for an outsider to cast a "freelance" +1 IPMC vote. 2. Finally, explore the possibility of nominating a standout podling contributor for the IPMC -- but only when all else fails. How about we reverse that: look for a podling contributor whose vote deserves to be binding *first*, and only consider bringing in an outsider as a last resort? Marvin Humphrey [1] http://incubator.apache.org/guides/mentor.html#initial-ip-clearance --------------------------------------------------------------------- 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--------------------------------------------------------------------- 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
