incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geertjan Wielenga <>
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. :-)


On Thu, Jun 13, 2019 at 10:29 PM Geertjan Wielenga <>

> 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 <> 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 for an intriguing chart.
>> Regards,
>> Dave
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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