incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [DISCUSS] Merits of pTLP idea
Date Sat, 15 Jun 2013 10:50:45 GMT
On 14 June 2013 18:11, Mattmann, Chris A (398J)
<> 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

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message