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,
-Alex
On 6/18/19, 10:33 AM, "Ted Dunning" <ted.dunn...@gmail.com> 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
documentation.
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 <aha...@adobe.com.invalid> wrote:
>
>
> On 6/18/19, 5:03 AM, "Jim Jagielski" <j...@jagunet.com> wrote:
>
>
>
> > On Jun 18, 2019, at 7:42 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> >
> > On Tue, Jun 18, 2019 at 1:18 PM Jim Jagielski <j...@jagunet.com>
> 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: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
