incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geertjan Wielenga <geert...@apache.org>
Subject Re: Incubation Pain Points
Date Fri, 14 Jun 2019 10:57:51 GMT
Just as a quick follow up, I watched this YouTube recording of a session I
did last year on the NetBeans move to Apache again today and, it's been a
while since I watched it last, but I think it still really nails it in
terms of the pain/gain continuum of transitioning a project to Apache, in
all its bleakness. :-)

https://www.youtube.com/watch?v=Bnznard9Nls

Gj


On Thu, Jun 13, 2019 at 10:29 PM Geertjan Wielenga <geertjan@apache.org>
wrote:

> Speaking on behalf of myself only, though note I am PMC chair of NetBeans,
> which went through a protracted (nice way of saying ‘complex’) incubation
> because of its size (‘very large’) and history (20+ years) — the key to any
> new culture is to adopt its traditions and to fight them as little as
> possible. And one can’t really understand the culture until one is in it.
> It’s hard to really prepare — other than to admire projects like Maven or
> TomEE and to want and aim to be like them, regardless of the contortions
> required to get there.
>
> Gj
>
>
> On Thu, 13 Jun 2019 at 21:10, Dave Fisher <dave2wave@comcast.net> wrote:
>
>> Hi -
>>
>> Here are some thoughts I have to improving Incubation. These are not
>> really new, but I think we should discuss where and how best to apply these.
>>
>> (1) Champions need to very clear that the ASF expects Community decisions
>> not BDFLs. Burnout is one factor to highlight why community is important.
>> Vendor independence is important and part of why BDFLs don’t fly. In the
>> last few years we have deemphasized the role of Champion and I think we
>> need to list out some of the duties a Champion has to both the prospective
>> podling community and the Incubator.
>>
>> (2) We should help existing communities plan their entry into Incubation
>> with their proposals. Currently TVM is moving their community over before
>> repositories. That might be a better approach for many communities as it
>> will assure that (a) the existing community keeps its current velocity and
>> (b) they are making community decisions on list before actual development
>> is moved over.
>>
>> (3) Having a lower impedance to release and code changes would really
>> help. We are already having this discussion. A very radical idea might be
>> to move a lot of the License, Notice and Dependency work away from the
>> Release Vote and instead do periodic and potentially automated audits of
>> repositories. This would follow the REVIEW suggestion, but make it more
>> automated and based on tooling.
>>
>> (4) Relinquishing control of admin rights on GitHub repos is an
>> impedance. I understand why this is done from an Apache Infrastructure
>> perspective, but it is a surprise to podling communities. Making sure that
>> a new podling knows fully what to expect before transferring repos would
>> really help manage expectations.
>>
>> (5) Failure to incubate is not failure. Currently 63 podlings have
>> retired and there are two or three additional retirements soon. 4 or 5
>> podlings moved on or back to where they were. The why of retirement could
>> be analyzed, but it would need to look into mailing list archives because
>> the information in podlings.xml is not always clear and is sometimes more
>> diplomatic than the reality.
>>
>> See https://projects.apache.org for an intriguing chart.
>>
>> Regards,
>> Dave
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message