incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Podlings, the Incubator, relationships and Apache
Date Mon, 24 Jun 2019 03:50:21 GMT
IMO, there's an actual test case going on right now.  On 6/14, the Weex folks asked about an
LGPL dependency which became LEGAL-464.  Personally, I think it could be classified as a "runtime/platform"
so that the CatX rules don't apply.  But they have been held up for 9 days and counting.

Who could/should make the call that they should just put their packages on dist.a.o assuming
it is a runtime and over time fix things, or must they wait for a careful analysis?

-Alex

´╗┐On 6/23/19, 8:26 PM, "Roman Shaposhnik" <roman@shaposhnik.org> wrote:

    On Sat, Jun 22, 2019 at 3:31 PM Rich Bowen <rbowen@rcbowen.com> wrote:
    >
    > A couple of thoughts:
    
    And a couple of thoughts on top of that.
    
    > Podlings are not permitted to call themselves "Apache Foo" because they are
    > not yet full Apache projects.
    
    Correct. The I way I see this thread is this: *when it comes to
    releases*, there's
    always been two camps in Incubator. One thinks that Incubator is a TLP just
    like Apache Commons that happens to produce release artifacts that have
    nothing in common (just like Apache Commons'  JXPath has very little to do
    with Compress and). A second camp thinks that Incubator is actually a special
    construct within a foundation (after all, if it was just like Apache Commons why
    would we make them put DISCLAIMER into release tarballs?).
    
    It seems that David is closer to the 1st camp, and Rich and I are
    closer to the 2nd.
    
    Looking at the community benefits, I really think we should acknowledge that
    Incubator is a special construct and optimize that special construct
    for a particular
    outcome: which is effectiveness of the graduation process.
    
    > While in the incubator we should expect podlibgs to fail at the rules.
    > They're new to them and many of them feel arbitrary, even capricious, to
    > those coming in from outside. We should make it safe to fail until they are
    > ready to graduate. We should nurture them as long as they are moving
    > towards that goal.
    
    Yup.
    
    > I cannot disagree with your reading of our resolutions. But I wonder if
    > that reality is producing good citizen projects or a bunch of resentful
    > people following rules they don't understand or embrace because they know
    > they have to.
    >
    > Zipkin is only the latest project which clearly didn't get it and has left
    > angry. I would rather a project realize that they don't fit and be able to
    > leave with their dignity without having also to leave hating what we stand
    > for.
    >
    > I want our new graduates to love and understand the ASF not merely tolerate
    > it.
    >
    > I want the incubator to respond to failure with gentle correction rather
    > than scoldings.
    >
    > Specifically I think podlings should be able to produce releases that are
    > not asf complient and have them clearly labeled as such. Because they are
    > not TLPs yet and so cannot be held to the same standard. This must be
    > accompanied by a movement towards being a TLP, not some eternal incubation.
    
    With my IPMC member hat on -- huge +1 to the above.
    
    With my VP Legal hat on: I have no dog in this race. The IPMC needs to make
    a *business* (well, community in this case) decision and then we can work
    with a risk profile of that decision.
    
    Like I said -- the decision to make is: 1st vs. 2nd camp.
    
    Thanks,
    Roman.
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
    For additional commands, e-mail: general-help@incubator.apache.org
    
    

Mime
View raw message