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