incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
Date Tue, 13 Aug 2019 23:26:44 GMT
Here's an idea... The IPMC focuses on supporting mentors to do their job rather than forcing
project developers and their mentors to jump through arbitrarily defined hoops.

That means stay out of the way until the mentor asks for a graduation vote. The IPMC doesn't
need to enforce policy of any kind, except at the point of graduation. Policy is set and enforced
by VP Legal, infra marketing, trademarks etc. The mentor can work directly with them as necessary.

I know holding mentors accountable is a tough job in itself, but if we quit accepting vanity
mentors and instead focus on supporting mentors who have a personal interest in the success
of the podling it shouldn't be too hard.

When things change for individuals and they can no longer be good mentors then the IPMC  needs
to make it a priority to help find a new, truly dedicated mentor. It's a problem that needs
to be solved, but let's worry about that when it's actually a problem rather than a hypothetical



Sent from my phone, you know what that means - sorry

From: Justin Mclean <>
Sent: Tuesday, August 13, 2019 3:04:46 PM
To: <>
Subject: Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)


> I am for option (F) with the addition of Myrle’s [REVIEW] until such time as the podling
is fully compliant with Apache Release Policy and goes through the usual process. Abiding
by the Apache Release Policy would remain a Graduation Requirement.

I’ll note not a single podling has asked for a [REVIEW].

> So, we treat these releases as not fully approved the same way we treat Binary Conveniences.

They are not the same as binary conveniences, as they are derived from a voted on approved
release. Thinking about (F) if they are not official releases could a podling:
a) Call them Apache releases? (Not doing may have a number of implications including naming
of artefacts, package names and the like),
b) Place tham on a download page on their ASF provided website? If so what would be required
to make it clear they are not approved releases?

We might want to check with branding and legal and get their input on this.

My concerns are that:
a) As IPMC votes are not required, less IPMC people (including mentors) look at the releases
or are less thorough in doing so, and things slip through
b) This become a hard gate at the worse time i.e. graduation. What happens if a community
proposed graduation and it found it’s releases have serious issue?

To unsubscribe, e-mail:
For additional commands, e-mail:

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