There's been a lot of discussion on relaxing requirements, but I don't recall
any long-time ASF person explaining how fragile or durable the legal-shield and
the insurance rates for it are.
Ted and Roy (in other threads) seem to have said that Ted's bucket #1 is the
only thing that is a true showstopper. And Ted's adds a bucket #2 for TLPs.
So maybe even for TLPs, all other issues can be punted to a next release.
Maybe that's the only clarification that is needed from the board. That no TLP
will be frowned upon for deferring anything outside of bucket #1 and #2 to a
future release and additionally no Podling will be frowned upon for deferring
anything in bucket #2 to a future release.
Unless someone can explain why that would ruin the legal-shield or raise
insurance rates, I think that would save lots of community time getting
releases out. Otherwise, we might be expending precious energy overzealously
trying to protect a legal-shield that doesn't need that level of protection.
Does anybody truly know what will and will not ruin the legal-shield? I have
to imagine that releases have been shipped by the ASF and later found to be
non-compliant with policy and that didn't ruin the legal shield or raise
insurance rates.
Of course, I could be wrong...
-Alex
On 6/9/19, 9:13 PM, "Greg Stein" <gst...@gmail.com> wrote:
On Sun, Jun 9, 2019 at 8:27 PM Justin Mclean <jus...@classsoftware.com>
wrote:
>...
> Hi,
>
> > It takes a new mindset. What is the *bare* minimum MUST? Two items?
> > maaaaaaaybe three?
>
> Given this is probably a radical departure, would it be best to do as an
> experiment with a couple of podlings? Small reversible steps. Would you be
> willing to work on a proposal to the board and act a mentor on one or more
> podlings who took this path?
>
Not me. Any of my spare/hobby time goes to supplement my work for Infra.
There is no way that I could sustainably mentor a podling.
> And keep the IPMC out of it. No votes on releases. Stop second-guessing
> the
> > mentors and the podling communities.
>
> I don't see how IPMC votes are second guessing. IPMC votes are required.
"required"? Said who?
Be honest now. We are not talking a TLP release. This is "some code" from a
podling. It may have stuff in it that would make a Director stroke out
(maybe not Ted, it seems :p ) ... Why does the IPMC feel a need to put its
"imprimatur" on the release? And who/when said they must? And let's say we
can dig that up from the past ... why not remove/relax it?
It seems there is some consensus that podling releases are getting jammed
up by IPMC rules. Assuming that is true, then why not question the vote
process itself?
Let's say at least ONE of a podling's Mentors MUST give a +1. Then the PPMC
gets at least (2) more, majority blah blah. Then they throw some code into
the release directory. Go out for a beer.
Wouldn't that be acceptable?
>...
> That's ASF policy / bylaws not incubator policy.
Again: I disagree. This is not a TLP release. It is "some code" from a
podling.
> We could look into changing this, but probably best discussed in another
> thread.
>
Seems to apply here. Aren't we talking about releases from podlings?
> Not all mentors (who are IPMC members) vote on releases and podlings in
> most cases need to ask for extra votes from the wider IPMC. I would guess
> 90% of them, so I’m not sure how your proposal deals with that.
Just stop having the IPMC vote. No need to ask for votes. Done. Easy Peasy.
>...
> The IPMC already added one way for releases to get reviewed by the IPMC
> without a vote, but so far no podling has taken the IPMC up on the offer.
>
What other way? Link? Publicity for this? Never heard of it. One wonders
how podlings could do this, if they never learn of it. Now, I'm not
"steeped" in Incubator like you are, and apparently missed this. But I do
tend to follow much of the goings-on ...
And:
On Sun, Jun 9, 2019 at 9:30 PM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
>...
> > I would expect that any graduating podling has this under control before
> > graduating and will not make any TLP releases with this kind of defect.
>
> I would suggest we make it a policy to document those exceptions in
> the DISCLAIMER file.
>
I would posit that most are not known at release time, but yes: it would be
a Best Practice to add those to a project's DISCLAIMER when found, to
inform downstream on the next release. And let's please not hold a
podling's release until things get added. ("no! stop! add to disclaimer".
rinse. repeat.)
Cheers,
-g
