Maybe the next question is: Are all release policy violations showstoppers? I
suspect the answer is no. And thus, if any TLP can punt release policy
violations to a future release, then so can podlings, and the IPMC can let more
things go without really needing another decision from the board. Or maybe the
only question for board or some authority is: Can the IPMC be authorized to
allow CatX in podling releases?
Ted gave an example in this thread of a legal issue where an attribution
required by a dependency's license is missing. I believe I've seen some
long-timers say that those are not showstoppers. Nobody is going to sue the
ASF over that legal mistake as long as we respond positively towards fixing it
in the next release.
I also think Ted explained in this thread the "why" behind many release
policies more clearly and in fewer words than I recall from incubator
documentation when I was in the incubator in 2012. And that might better
educate podlings and TLPs on how to make good choices on what can be deferred
to a future release.
Seems like the only showstoppers for TLPs are:
1) content we have no right to distribute
2) content that distribution would break a law (maybe export restrictions,
adult content)
3) CatX content
Maybe other legal issues like missing attributions MUST be fixed in the next
release.
Other release policy violations SHOULD be fixed in the next release.
Not sure where to put inclusion of CatB source. Would that also be a
showstopper?
Podlings would be given flexibility on CatX/CatB, but also have showstoppers for
A) missing DISCLAIMER
B) missing "-incubating" in the source artifact package name.
My 2 cents,
-Alex
On 6/12/19, 11:44 PM, "Hen" <bay...@apache.org> wrote:
On Sun, Jun 9, 2019 at 4:11 PM Justin Mclean <jus...@classsoftware.com>
wrote:
> Hi,
>
> > I agree with other respondents that 'serious' seems bad here. To me the
> > serious ones are the only ones they can't release with.
>
> So we just continue as is then? You have any suggests to what we change?
>
I don't think we're using the same word meanings.
I think that serious = release blocker; but I equally think there are very
few items that are serious.
>
> > ReleaseBlocking: Has a LICENSE. Legally permitted to release and
> complies
> > with the license via some mechanism.
>
> We currently allow releases that are not strictly legal. This would be a
> step backwards.
>
>
I'd love to hear some examples. I suspect they are all legal.
Speculating hypothetically:
* We should never make a release that we know there is some content in that
we explicitly do not have permission to publish.
* We should never make a release that we know contains content that is
criminal (for whatever that would mean).
Other than that... I'm not sure what else would come under 'all legal'
label.
> > GraduationBlocking: Everything else; including complying with the
> license
> > via our preferred mechanism (i.e. we might want the MIT license text in
> our
> > LICENSE file, but would accept it being in the source header of the
files
> > themselves).
>
> We currently allow podlings to graduate with some issues as longs as the
> PPMC is dealing with them. This would be a step backwards.
>
>
Yeah. We need a third category for "MehNotBlockingPleaseFix".
> > I don't see a need to go to the board on this :)
>
> If we don’t want to change anything - sure there's no need to go to the
> board.
>
I'd definitely like to see change. My feeling is that there's a lot we can
make that falls comfortably within the scope of the Incubator PMC. IIRC the
release policies came out of the Incubator; I don't recall there being a
request for the board to ratify them, but I might be failing to remember
something a decade+ ago :)
>
> >> issues have been fixed. The IPMC will add additional information to the
> > incubator DISCLAIMER to cover that podling release may not abide by all
> >
> > The IPMC? That sounds like a people scaling problem. The podling
> committee
> > should handle it.
>
> I mean just changing this page [1] , podlings can update their own
> disclaimers.
>
Gotya :)
>
> > "This release still has the following issues that will need to be
> resolved
> > before the Foo Project can graduate to an Apache vetted Top Level
> Project”
>
> What about unknown issues?
>
By that are you suggesting that the text implies a guarantee that those are
the only issues? (Otherwise I'm off into philosophy of whether the unknown
can exist when the only test makes it known :) ).
"The Foo Project have currently identified the following issues that will
need to be resolved before the project can graduate to an Apache vetted Top
Level Project”
Any better?
> > Are the board lawyers? :) Until you have a well-defined list, I doubt
> > anything could be confirmed. I'd go with: "Conceptually what you
> describe
> > could lead to a situation where a PPMC releases a project fully
compliant
> > with the ASF's expectations. “
>
> I assume you mean “not fully compliant”?
>
Nope.
I was being defensive in my broad statements. For the given question; sure,
someone might manage a perfect release someday :)
Hen
