incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Incubation Pain Points
Date Wed, 19 Jun 2019 18:01:49 GMT
I know this isn't the latest posts on this thread, but this is the post that best suits what
I want to say.

Almost all of my posts recently have been about trying to determine if all policies must be
attached to the same pendulum.  I think I'm seeing from Ted, Roy (in the past), and Hen that
some policies are more important than others.

IMO, each policy could be graded under 4 categories:
1) inflexibility/ambiguity - are there different ways to interpret/implement the policy
2) effort to prevent non-compliance
3) cost/effort to fix non-compliance
4) cost/effort of non-compliance

I'm going to assume that the cost of canceling a release candidate is significant, not just
in person-time, but momentum, and time due to restarting the 72-hour vote clock.

When a policy has ambiguity, or requires effort to prevent non-compliance, including understanding
the policy and how to apply it, and it can result in a high cost effort to fix, you have the
perfect storm, and so you'll receive feedback to try to eliminate ambiguity or reduce effort
to prevent, or make the policy easier to understand and apply (or improve tools to find non-compliance).
 But if it turns out you can simply reduce the cost to fix by not having that policy be a
release breaker, then I don't think you'll get as much feedback asking for the policy or tools
to be more specific.

I think I see consensus that the only truly important release policies are around:
1) Legal right to distribute.  IMO, this is inflexible, and not ambiguous.  The policy is
easy to understand: you either have documentation that says you can distribute each line of
code or you don't.  There is effort required to check each line of code, but the cost of non-compliance
is significant.
2) No usage restrictions.  IMO, this is inflexible for TLPs.  It is ambiguous only in the
sense that new situations could come up that haven't been covered before, but I think we could
just list the most common things that cause usage restrictions and that would help folks get
a sense of what this is all about.

The only wiggle room in these two may be in the quality of the documents.  It should be ok
to ship something where there is general consensus that there is a right to distribute even
though the supporting documents aren't perfect.  For example, a file is not listed in an SGA
but doesn't really contain anything important, or the words chosen to document a re-licensing
from GPL to MIT could be better, or the license was changed from GPL to MIT in every file
but one due to a clerical error.

Everything else related to releases could be fixed later, significantly reducing the cost
to fix.

And then the only other thing I would suggest beyond that is trying to get advisors to preface
advice with "this is how I would (or have) done it", especially for the more ambiguous or
hard-to-understand policies.  And that, I think would stop the pendulum from swinging.

For Podlings, the cost of fixing a usage restriction issue can be significant if they have
been relying on, say,  a GPL dependency before coming to the ASF.  I hope someone with authority
(VP Legal, Board) finally decides that the DISCLAIMER is enough to let podlings have the time
to replace that dependency or make it optional.

IMO, the Maturity Model contains a lot of things that are ambiguous because there are multiple
ways to implement it.  I think that's totally fine: I thought the ASF was ok with diversity
in how projects execute.  And so the introductory materials about the Incubator should state
that you may get differing opinions and that is fine.  Maybe the MM should indicate which
ones are not flexible (where you shouldn't be getting different advice from different people
on how to execute).  I think it would be LC10-40, RE20&30.

To close with Justin's bread analogy:  A bread maker that just says "just add yeast and flour
and water, kneed, let rise and bake" and then makes you toss out the results and start over
is not going to attract nearly as many students as the bread making expert who can more clearly
provide instructions in a friendly way, helps you catch your mistakes before you go too far
down the road, and doesn't make you start over except in a few extreme cases.  For sure, if
you sign up to be a bread making apprentice at the most prestigious bakery, then you can expect
less leniency and stricter standards.  It is up to the ASF to decide if they want the reputation
of being that picky or not.  I hope not.

My 2 cents,

´╗┐On 6/18/19, 10:33 AM, "Ted Dunning" <> wrote:

    Alex, Jim, Bertrand,
    This discussion is re-inventing a discussion that has been had before. At
    one time, the incubator tried to present principles to incoming podling
    (albeit not in a very well documented fashion). The reaction was that
    podlings strongly wanted specifics, not general principles. The idea of "no
    category x" worked, but things like "no downstream constraints" were a bit
    too vague. And some mostly kind of sort of accepted Apache ideas like votes
    should mostly be used to record consensus rather than make decisions are
    definitely too vague.
    OK. So we learned that lesson. And the maturity model was created. And
    documentation was done.
    One very clear sub-lesson is the unwritten rules really don't work when
    there are a large number of new people. Peoples' understanding changes or
    varies even when there is apparent consensus. Unwritten rules are also just
    not visible enough and can't be passed from one newbie to another.
    And here we are. Folks are now saying that we need to be a lot looser. That
    there is a lot of leeway in how projects interpret the traditions we have.
    That we should just specify abstract invariants.
    A lot of that involves some good ideas. But we need to not just circle back
    to the exact same place we started.
    We can damp the pendulum a bit by the following going to a middle ground:
    1) *Add* the abstract principles (aka invariants) to an introduction to our
    2) Use the maturity model. But add a statement that a project could
    negotiate an alternative maturity model during incubation as long as the
    IPMC agrees and it meets the invariants.
    3) allow some non-conforming podling releases with special approvals.
    On Tue, Jun 18, 2019 at 9:32 AM Alex Harui <> wrote:
    > On 6/18/19, 5:03 AM, "Jim Jagielski" <> wrote:
    >     > On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
    >> wrote:
    >     >
    >     > On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <>
    > wrote:
    >     >> ...prepping the existing community regarding what "moving to the
    > ASF means" is the job of the Champion, no?...
    >     >
    >     > I agree but it has to be based on written docs, not oral tradition as
    >     > that does not scale.
    >     >
    >     Of course... but lack of it being on written docs does not make it
    > invalid nor not policy.
    > Just trying to follow these threads, it isn't clear there is agreement,
    > even among the "old-timers", as to what the invariants really are whether
    > written or oral.
    > For example, I'm a bit surprised that none of the old-timers disagreed
    > that there is an Apache Culture and that incubation is about assimilating
    > into that culture.  I thought I read many times on various ASF lists that
    > the ASF is comprised of many projects each with their own culture.  And
    > that the only common ground is a "Way" not a "Culture".  But then various
    > folks try to define the "Apache Way" and other folks disagree with their
    > definition.
    > At least in the US, there are many places where the residents have formed
    > or retained their own culture.  Folks immigrating to the US are not
    > required to assimilate into any particular aspect of US culture.  They are
    > only asked to obey certain laws.  And even then, the strictness of law
    > enforcement is somewhat influenced by the local culture and context.
    > What really are the invariants at the ASF that require strict inflexible
    > immediate enforcement?  I think there are really only a relatively small
    > number of them:
    > 1) No closed source in a release
    > 2) No CatX in a release
    > 3) No corporation owns decision making
    > 4) Majority vote on releases
    > 5) No advertising the general availability of non-releases.
    > 6) A protocol for handling security issues.
    > 7) ASF does not pay developers
    > 8) Don't violate US Non-Profit rules
    > A podling could be granted more flexibility around #2 and #5 with the
    > additional requirement of DISCLAIMER and -incubating labels.
    > Could everything else really be seen as goals for a community?  Then it
    > would be "Community over Code and Policy except these 8 things".
    > My 2 cents,
    > -Alex
    >     ---------------------------------------------------------------------
    >     To unsubscribe, e-mail:
    >     For additional commands, e-mail:
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail:
    > For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:
View raw message