incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: Incubation Pain Points
Date Mon, 17 Jun 2019 15:36:16 GMT
On Mon, Jun 17, 2019 at 1:24 AM Christofer Dutz
<> wrote:
> Hi Geertjan,
> not quite sure how to read this ... what are you referring to as "new culture".
> The existing project coming to the ASF? And this project should adopt the tradition of
the ASF.
> Or that the ASF should adopt the culture and tradition of the project joining?
> (Probably then meant more as: Allowing them to continue than the ASF to change)
> I think projects coming to the ASF have to be educated prior to entering incubation that
> there will almost always be things we are expecting them to change when they come to
> and that there's no discussion on if they have to follow them.

This! Also, I think we should stop being so uptight about communities
trying incubation
and deciding that ASF is not for them. It is a two-ways street when it
comes to education.

> We have to make them understand that the ASF is more than a GIT repo, CI Server and Mailing
> That the ASF has great things to provide (Legal Shield, Marketing, Infra, ...) but that
this only works
> If you play along with some rules we have. Also should we explain WHY these rules are
> I would say it's sort of like emigrating to another country: You probably move for some
> But also probably the rules are a little different at the country you are moving. There
will be things
> You will be allowed to do the same way you always did it, but there will be things expected
of you
> to simply follow and not ignore, because you think otherwise.

And sometimes you'd return back to your old place after all -- and
that's totally OK.


> We have to find a way to state the rules and what we expect before podlings enter incubation.
> Still we will have podlings that sort of remind me of small children simply not willing
to do something simple,
> Just cause a parent told them to: "No, I will not say thank you".
> Or converted to our world: "No, I will not add anything to any Notice", or "No, I will
not credit stuff I
> obviously borrowed somewhere" ... but this way we can always refer to the rules being
> communicated prior to entering incubation and not have to listen to complaints all the
> And for my point of view: If there are projects, that join the ASF, but don't want to
play according to the
> Rules - we're off way better without them. At least I don't want to invest my time (which
is already
> Spread out pretty thin with all the things I do for the ASF) to deal with rebellious
> Chris
> Perhaps creating a training session as part of the training podling
> Am 13.06.19, 22:29 schrieb "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:
>     >
>     >

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

View raw message