incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [IMPORTANT] Board proposal on podling releases
Date Mon, 10 Jun 2019 04:12:36 GMT
On Sun, Jun 9, 2019 at 8:27 PM Justin Mclean <>

> 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

> 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 ...


On Sun, Jun 9, 2019 at 9:30 PM Roman Shaposhnik <>

> > 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.)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message