incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <>
Subject Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))
Date Sat, 02 Mar 2019 00:42:26 GMT
Lots to distill here...

> On Mar 1, 2019, at 2:15 PM, Justin Mclean <> wrote:
> Hi,
> Thanks for taking to time to distill this.
>> Many PMCs contain what could be called inactive PMC members. The concern is if that
makes any difference or impedes the active IPMC members. I’m not sure how inactive IPMC
members are impacting the functioning of the IPMC.
> I also don’t think it is a concern, but as others have raised it as one, and it’s
something that can be easily changed (and undone if needed). Small reversible steps and all

I agree that it's not ideal but it is not a symptom of a big problem either. We have inactive
IPMC members who might become active again later if a community wants to join the incubator
but it's a hassle to leave and then join again. 
>> (1) The purpose of the Incubator is to introduce project communities of individuals
to The Apache Way and help them come into alignment with those principles.
> +1
>> Currently, I think that the "Legal Shield” value has been elevated above the Community
aspect.Communities are harmed because coming to the ASF can be a sharp, direct change in how
they operate and this is a negative disruption. In some podlings the Community aspect of the
Apache Way is harder than Legal and in others Legal is harder.
> Do we need to ask the board to spend more on the legal shield? (I don't know what we
pay now or how it is worded.) Do these suggested changes required it to be changed? Or do
we make need to make podlings aware that they do not have legal protections if's might assume
they have?

From my perspective, the legal issues discussed here are overblown. By the time a podling
graduates, they have to learn how to make a perfect release. During incubation, they have
to make releases, not all of which have to be perfect. That's what we need to keep in mind.
The podling releases have a disclaimer that the releases may not be perfect.

So my takeaway is that we should give podlings a bit more leeway on their first (few) releases.
Nothing bad will happen by noting what needs to be changed but letting out the release. As
long as the podling shows that they can fix bad releases in the next cycle, all's good.

But I don't think we gain anything by trying to bypass the three +1 rule for releases. The
IPMC must approve releases according to the rules that every PMC has to adhere to. If the
mentors are doing their job, podling releases should have had a good review before coming
to the IPMC for approval. And if there are three mentors voting on the dev list, they can
decide if a "bad" podling release should block external review/release. Once a podling has
three mentor reviews and three mentor +1 votes, the IPMC should step back.

But if a podling can't get their mentors to review and vote, that is the problem we should
focus on. But if the larger IPMC needs to review a podling release because mentors have not
done, we should give them a bit more leeway and allow e.g. binaries in the release, old copyright
notices in code, license files with too much information. As long as the podling understands
(in writing) why these are issues.
>> To graduate both must be accomplished.
> +1
>> (2) With this service orientation what are the duties of Mentors? Here is my non
exhaustive list.
>> - Boot the Podling Community by making sure that podling community is setup in Apache
Infra with Mailing Lists, CLAs, SGAs, LDAP, Code Repositories, Issue Trackers, etc. 
>> - Make sure that decisions are memorialized on the Mailing Lists and how that benefits
the community.
>> - Make sure that the PPMC is recognizing contributors and growing the community.
>> - Make sure that the podling’s releases meet ASF Legal, Distribution and Release
policies and why that is important.

I'd restate this: Review podling releases and document the deficiencies. Help move toward

>> - Make sure that the podling understands Branding issues in order to protect their
>> - Make sure that the podling understands the ASF committee structure in order to
find services.
>> - Do all of the above in a gentle, respectful manner.
>> - Keep track of the above to protect the podling.
>> - Guide the podling in how to report to the IPMC (and later the Board)
>> - Defend the podling if the IPMC or Apache is too demanding.
> Great list I’d also add:
> - Make sure the podling acts in a way that’s free from corporate influence
> - That the podling acts in a respectful manner to people on it list and the wider ASF
and is aware of our code of conduct
> - Makes sure they understand consensus and when to (and not to) vote
> - Make sure that releases are repeatable and the knowledge of how to do them captured

i.e. Document the release process in a public place.

> - That they recognises and vote in new committers and PPMC members
> - No BDFY in the making
> - Comply with incubator policy on making press releases while in incubation (see corporate
> - They don’t get avoid the ASF release policy by making release elsewhere and call
those ASF releases.
> And there probably a few other things that have slipped my mind.
> For the suggested changed it may be best to separate them out and have seperate discussion
and votes on each.
>> (A) On general@ replace [VOTE] on releases with [DISCUSS] or [REVIEW]. The podling
would do the release and the review would consist of both Release and Distribution Policy
>> - 3 or more PPMC votes are still required.
>> - It is an open question about how many IPMC votes we should require. Is it 0, 1,
or 3?
> I would say 3, lets not added yet another voting method, podling (and it seems old ASF
members) get confused as it is.

I agree. Once they graduate, they will need three binding +1 votes. Why confuse things?
>> (B) Explicitly evaluate Podling Proposals for the following:
>> - if the PPMC has several Apache Members the IPMC should recommend direct to TLP.
>> - explicitly make sure that
>> 	(i) there is at least one mentor who is experienced via successful incubation.
>> 	(ii) that the mentors all have a clear understanding of the Apache Way.
>> 	(iii) that they currently have enough free time to do the necessary work.
>> - confirm what SGAs will be required and assure that these will be signed quickly.
(Podlings and Mentors have trouble if it takes the better part of a year for the SGA to happen.)

I think that we need to take a closer look at the github repository migration. In the past,
it was easier to bring a code base into the incubator because it was always a copy operation,
not a move. So these things were explicitly possible: 

1. There were no questions about the legitimacy of copying a repository from an existing location
and starting work in Apache simultaneously with the old project committers working on the
old repository.

2. The old project could continue to make releases while the Apache podling was setting up

3. The SGA/ICLA was a gate to exiting the incubator not entering the incubator.

But with the new strategy of moving the github repository, we need to take care that the committers
on the old project are ok with losing their rights to commit to the repository pending the
podling setup. This is one reason for the lengthy migration. And why I recommend that the
podling decide on a repository-by-repository strategy for migration. And explicitly allow
continued releases from the old repository while the podling is setting up.

>> - the above may require updates to the proposal template.
> +1
>> (C) Formalize the Shepherd role as follows.
>> - Permanently assign a Shepherd to every podling.
>> - The shepherd tracks mentor engagement.
>> - The shepherd tracks progress of podlings and updates the content/podlings/${podling}.yml
>> - The shepherd “sends” report reminders and is a backstop for the Mentors. 
>> - Shepherds are IPMC members whose touch is generally very light like the Board is
with TLPs
> Podling already have shepherd they don’t tend to do much (with some exceptions) and
we have a shortage of them. How do we recruit more / ensure they do the task they are assigned?
Do we require sign off from them on the report for it to be accepted?

I would prefer that we continue on the path we are on with the podlings explicitly noting
whether they need more help from their mentors.
>> (D) Recruit Mentors.
>> - The IPMC should send periodic emails to members@
>> - The IPMC should periodically ask ComDev if there is anyone active there to recommend
as a Mentor.
> +1 and the IPMC has done several things recent to improve this. Others include:
> - identifying inactive mentors and asking them if they want to cary on
> - asking podlings if their mentors are active on the report
> - meeting people we may not be aware of propose themselves for consideration
>> (E) Change the IPMC structure (this depends on whether we change the podling release
VOTE rules)
>> - IPMC members are reduced to those who have successfully mentored a project through
to graduation and affirmatively wish to remain on the IPMC.
> I’ve not looked at the number but this may leave many existing podlings with a reduced
set of mentors. That may be unfair to mentors (and their podlings) who are active.

I honestly do not see how reducing the size of the IPMC solves anything. From what I've seen,
the biggest issue is how to get mentors to be more involved with their podlings. How does
reducing address mentor involvement?

Regards, Craig
>> - Other mentors are like committers and are either Apache Members or voted on by
the IPMC.
> On TLP only PMC members can approve releases, given the mentors are now committers can
their votes binding on release?
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Craig L Russell
Secretary, Apache Software Foundation <> <>

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