incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Piotrowski <>
Subject Re: New disclaimer text
Date Fri, 12 Jul 2019 08:36:19 GMT
> I think the question to be asked is does that add barries more than having to have 100%
compliant releases?

Is this a current requirement that is written down somewhere and
generally practiced?

Am Fr., 12. Juli 2019 um 09:49 Uhr schrieb Justin Mclean
> Hi,
> > Adding an additional disclaimer that we may have known issues adds additional barriers
to adoption and community growth.
> I think the question to be asked is does that add barries more than having to have 100%
compliant releases? I think the answer may depend on the podling. Have does that work out
for 50 odd podlings?
> > Here’s one way for the ASF Incubator: Apache’s key marketing point is the Apache
Way. Break down critical processes, determine key performance indicators against those processes,
and centrally track metrics (license compliance, community participation, release compliance,
notice, keys, whatever, whatever).
> I really like the idea, would you be willing to work on it further?
> Some things to consider. I don’t know it we have enough volunteer time to implement
something along those line or if we could come out with clear metrics to suit all podlings.
However in some ways this work has already been done with the maturity model. There are issues
this this as well a) not all IPMC members or podlings think it should be used so so it's optional.
b) we’ve had podlings fill it in and ask to graduate that were clearly not ready to graduate.
> >  The additional disclaimer communicates that Apache has little trust in its podlings,
at large.
> About 1 in 5 podling releases put up fro IPMC have serious issues and have previously
have attracted -1 votes by IPMC members. If we allow those to be released then I think we
need to add something to the the disclaimer, we just need to work out a balance.
> > -1. These are connected issues: Mentors are IMPCs "tip of the spear" for managing
compliance risk and for adding value to podlings. I have so much respect for Justin and other
IPMC regulars who tirelessly volunteer and monitor general@, dig into minor releases to test
builds and check compliance. It’s heroic, but heroes are a sign of struggling operations
in orgs, and heroes burn out.
> I’ve yet to see any proposal that deals with the issue of how it would get around that
only PMC members votes are binding. I don’t see voting in all PPMC member as PMC member
working (we get complaints that he IPMC is already too large) and I don’t think the board
would allow a TLP to ignore that particular bylaw. I’m open to suggestions.
> > Their valuable time is better spent institutionalizing knowledge and skills: making
mentors' jobs easier with templates, documentations, infrastructure projects.
> We do quite a bit of that as well.
> > IMHO: the thing the needs to be discussed in a different thread is how the Incubator
supports and incentivizes engaged mentors. Speaking from experience: engaged mentors are magical
gifts from above. Losing mentors during critical junctures is terrifying because there is
so much to learn and its hard to find documentation and examples for how to do things right.
> If you have engaged mentors then that should be no issue, the last checkbox before graduation
is that you don’t need mentors anymore and can wrk out things for yourself that are in line
with how other ASF projects operate and the Apache Way. If you feel like that then perhaps
your mentors haven’t completed their job.
> Thanks for your thoughts,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message