On 14 June 2013 18:11, Mattmann, Chris A (398J) <chris.a.mattm...@jpl.nasa.gov> wrote:
> 2. It's harder to discharge a pTLP rather than a podling > > Jim, Ross: It's going to be harder to pick up the pieces if pTLPs are > unsuccessful, than > it would be for a podling. I think that is a misrepresentation of what has been said. It's not about "picking up the pieces" it's about providing adequate mentoring to give a project fighting chance. Picking up the pieces should a project fail is easy. Preventing a project from unnecessarily failure is less easy. I estimate I've worked with something like 50 new project teams over the years. More than half of them outside the ASF. In my experience the success or failure of a project (assuming a good engineering team and a genuinely useful product) is less to do with the people doing the development work and more to do with the guidance those smart people get at key decision points relating to the open source model. So it's not about "picking up the pieces" it's about spotting when the process is failing early enough to fix it and then having the right vehicle to provide support. In the majority of cases the mentoring model we have is perfect. It works far more than it fails. When it fails the problem is ISSUE 01 coupled with 03 (all other issues are symptoms of those issues in my opinion). pTLP can help address this but not, in my opinion, when coupled to your larger dismantling proposal. I want to explore pTLP as part of the existing incubation process, not as a replacement for it. Precisely how that will work requires some experimentation - hence the Stratos proposal. > 3. There isn't any benefit to implementing pTLPs > Jim: I see no real benefit to implementing pTLPs. > > Chris: The benefits would immediately be that they don't have to go in > front of a 170+ person > committee to get a decision. Chris, podlings that don't hit ISSUE 01 (that's the majority) don't have to go to the IPMC now. Why are you claiming they do? The process is one of *notification* that a vote has been conducted not one of review. If mentors allow the IPMC to get in the way that's a failing of the mentors not the process. In the 18+ projects I've mentored at the ASF we have only ever once had to request an IPMC member vote. Once. Even then it was painless because we had a brilliant mentor who had already addressed all the issues in the release (not me I hasten to add - thanks Ate). Sometimes it has taken some robust protection of the podling here in the IPMC lists (take a look at some of my posts relating to AOO for example), but that's part of the job of a mentor in my opinion. In my proposed experiment I want to take the advantages of the pTLP (specifically it clearly defines the role of the mentors and encourages faster empowerment of the podling committers and thus reduces the potential for ISSUE 01 (mentor atrophy) coming into play and thus ensuring ISSUE 03 (too many cooks) is no longer valid. I am not interested in using the pTLP concept to solve problems that I do not believe exist, like the one you discuss above. > Other benefits would also be in release VOTEs where those doing the > releases could > have their VOTEs be binding (which they will anyways) As a member of the foundation I only want people who have proven their ability to do the appropriate due diligence on releases to take on that responsibility. It takes time to understand both the process and the need for it. This is not a trivial thing, it is the sole reason why the ASF is trusted and thus why our software is so important. Do not underestimate this. Whilst academic institutions can afford to be somewhat lax in their management of IP (yes I have extensive experience of this) large corporations with bank balances and shareholders cannot. It would be irresponsible of the ASF membership to allow any action which dilutes the the IP management processes. As a Member I will insist that the Board refrains from taking actions such as automatically making podling "initial committers" full voting PMC members (although I very much doubt I'll need to express this opinion to the Board). > The board isn't responsible -- the pTLP ASF > members are. That statement is only true where ISSUE 01 (mentor atrophy) does not come into play. Regardless of whether you agree with this or not I suggest this is not relevant to the pTLP experiment I am proposing. It is not relevant because I am not coupling the proposal to the dismantling of the IPMC. Should ISSUE 01 come into play it is the IPMC that will be required to provide the necessary support (and I have already stated I will take that responsibility for the IPMC). I request that when we discuss the merits of the pTLP idea in the context of Stratos we focus on the pTLP as a part of the existing incubation project *not* as part of the dismantling proposal. If someone else wants to argue for pTLP as part of the dismantling then that's fine. But lets take incremental steps and not let this discussion get bogged down by one perceived end position - we won't progress if we take that route again. Once this experiment is complete then we will have more data upon which to build the next step. That step may be a step towards dismantling, at which point the argument about whether ISSUE 01 is fixed or not will become relevant. Ross --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
