Since I wanted to reply to both of your emails I am re-quoting your original first.
> On Oct 26, 2025, at 11:09 PM, Justin Mclean <[email protected]> wrote: > > Hi, > > I had a casual chat with Brian, and he suggested that M&P could use this as > content > https://cwiki.apache.org/confluence/display/INCUBATOR/Release+Vote+Insights I read this blog post when I saw the commit email from your change. While you discuss the sources you use for your analysis - [email protected] emails with [VOTE] and [RESULTS] from 2015 to September 2025. You do not describe your methodology. Are you using AI at all? I’d like to understand what’s driving your analysis. Did you analyze any impacts from the number of podlings in incubation? There are fewer podlings active in the last 5 years than the prior 5 years. I know because I’ve had to fix the podling count minimum for clutch analysis more than once. See the podling chart at https://projects.apache.org > Here's the version I’ve created for M&P: > https://cwiki.apache.org/confluence/display/INCUBATOR/A+Decade+of+Learning+from+ASF+Incubator+Releases I think that this is a good summary version of your analysis. > On Oct 27, 2025, at 1:21 AM, Justin Mclean <[email protected]> wrote: > > Hi, > >> Others look good. But I'm considering what an ASF release promise can >> be important [1]. Otherwise, people would consider why you can't just >> cut the release with one click, and it takes so long - what do we >> gain? > > I’m not entirely sure what exactly you mean by this. But perhaps this may > help, for an external audience, I think the key is to convey why ASF > releases take the time they do, without diving into internal policy. I think that there is a simple way to describe our way of governing w/o providing all of the policy statements. - We require that a minimum of three PMC members approves each release. - We are a global volunteer community. We wait at lease 72 hours to allow all PMC members a chance to review. > I’ve fixed the week issue; it initially said a month-to-weeks, which I > thought was a bit of an exaggeration. > >> Also, not sure if we'd mention the ongoing ATR program [2] >> >> [2] https://tooling.apache.org/trusted-release.html > > I don’t know of any incubating projects currently using the ATR program (but > there might be some), and since it’s still quite new and in alpha, I’m not > sure we should mention it yet. It has value for other reasons, but I think > it’s not likely to catch many issues beyond what existing automation and > review already surface. We’ve got to teh point where most found issues > require human judgment. I challenge you to try ATR for yourself before you cast doubts on whether it is useful or not. 1. Yes, human judgment is always required. ATR allows for the RM to use their judgment before a VOTE is ever started. We use the very latest release of RAT for some of our license checks. 2. The ATR will be providing support for regulatory compliance like checking SBOMs and producing the attestations that will be necessary. Best, Dave > > Kind Regards, > Justin > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
