incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Post mortem request for the handling of the Corinthia podling (was Re: FYI, I have subscribed to this list and to your private list)
Date Wed, 20 Jan 2016 05:25:52 GMT
The qt discussion was a community process during incubation. It was not known in advance. This
process Marvin describes would not have caught the issue. The community wanted to find a way
more slowly and focus on code efforts. When asked to help slow the discussion someone heated
it up instead.

Regards,
Dave

Sent from my iPhone

> On Jan 18, 2016, at 8:07 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> 
>> On Fri, Jan 15, 2016 at 6:55 AM, Peter Kelly <pmkelly@apache.org> wrote:
>> The big takeaway from my experience, in terms of suggestions, is to make it
>> *very* clear on both the incubator website, and impressed upon anyone
>> considering joining incubator, exactly what can and cannot be done in within
>> the context of an ASF projects.
> 
> In the incubation proposal template, there is a space for listing the
> dependencies of the project.
> 
>    http://incubator.apache.org/guides/proposal.html#template-external-dependencies
> 
>    External dependencies for the initial source is important. Only some
>    external dependencies are allowed by Apache policy. These restrictions are
>    (to some extent) initially relaxed for projects under incubation.
> 
>    If the initial source has dependencies which would prevent graduation then
>    this is the right place to indicate how these issues will be resolved.
> 
> This catches most problematic dependencies.  However, in Corinthia's case, it
> seems that because Qt was a *future* dependency, it wasn't listed.
> 
>    http://wiki.apache.org/incubator/CorinthiaProposal#External_Dependencies
> 
> To be clear, I don't think anybody's at fault here -- glitches arise naturally
> and inevitably from complex requirements, and preparing an incubation proposal
> is a complex undertaking.  What I'm saying is that the proposed safety
> mechanisms already exist, yet were not fully effective.
> 
> This is not the only time that there's been an issue with licensing which was
> discovered only after incubation started.  When Groovy came to the ASF, a
> significant portion of the Groovy documentation was under CC-BY-SA.  The ASF
> allows CC-BY but not CC-BY-SA, but the Groovy team was mistakenly informed on
> a non-ASF list that CC-BY-SA was not a problem, and regrettably none of the
> ASF participants in that discussion (including me) caught the mistake.  And so
> that potential blocker was not dealt with until incubation was already
> underway.
> 
> Fortunately, after substantial effort, Groovy's documentation was able to be
> relicensed -- there were only 15 or so contributors to that particular section
> and they were contactable and willing to give consent.  But if that had not
> been the case, it would have been a big deal, because a lot of effort had
> already gone into moving Groovy to the ASF.
> 
>> stuff like this needs to be made really, really clear right from
>> the beginning, before large amounts of time are invested in podlings that
>> later discover themselves doomed to fail from the start.
> 
> It seemed that volunteer goodwill boiled away very quickly with Corinthia's
> crisis reached critical mass, for a variety of reasons.  Complexity of
> requirements does seem to have been a contributing factor, and I accept that
> we have work to do.
> 
> Best regards,
> 
> Marvin Humphrey
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message