incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: Incubation Pain Points
Date Mon, 17 Jun 2019 09:39:09 GMT
I can see how this can be annoying, 

But I also have to see the IPMC workload ... we're raising quite a number of podlings. 
Having the votes start in parallel on the podling dev and the general incubator list 
would probably not decrease the number of cancelled votes. I would be fine with 
allowing parallel votes, if the podlings mentors have voted in favor of the release. 

So you start a vote in the podlings dev list and as soon as the mentors have voted +1
You could start the vote in the general incubator list, but not before that. 

I mean It's one of the most important jobs of the mentors to thoroughly check the RCs.
If there are realy valid issues for which the vote in the general list is -1ed, that's actually

not really the fault of the Incubator, but could considered the fault of your mentors.
And if these RCs are waived through with serious issues over and over again, I would
Instead start thinking of getting mentors on board, that do the checks before you carry 

For exactly that reason I asked Justin to mentor PLC4X when it entered incubation.
He did raise quite a lot of issues, but on the project list and prior to carrying over the
Vote to the general incubator list. And I can't remember a single RC cancelled because 
Of IPMC votes on the incubator list.


Am 17.06.19, 11:15 schrieb "Geertjan Wielenga" <>:

    I agree and that’s how I see it too — coming to Apache means the assumption
    that you’re wanting to adopt its culture. However, there are definitely
    very frustrating aspects to that culture. The biggest fix I’d suggest for
    the incubator is parallel voting — i.e., start the PPMC vote and IPMC vote
    at the same time.
    I cannot tell you how many times I’ve wanted to stab myself with a blunt
    instrument in the eye after having to restart the PPMC vote yet again (with
    less and less enthusiasm from the community and thus less voting and more
    time wasting) after an IPMC vote failed yet again on some aspect that the
    community is not interested in at all (but should be, but still isn’t).
    On Mon, 17 Jun 2019 at 10:24, Christofer Dutz <>
    > 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 Apache
    > and that there's no discussion on if they have to follow them.
    > We have to make them understand that the ASF is more than a GIT repo, CI
    > Server and Mailing lists.
    > 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 there.
    > I would say it's sort of like emigrating to another country: You probably
    > move for some reasons.
    > 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.
    > 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 clearly
    > communicated prior to entering incubation and not have to listen to
    > complaints all the time.
    > 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 podlings.
    > 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:
    >     >
    >     >

View raw message