> On Sep 4, 2026, at 8:40 AM, Justin Mclean <[email protected]> wrote:
> 
> Hi,
> 
> You're right that releases may not be vetoed, and nobody is treating a -1 as 
> one. I’ll note the same paragraph goes on: "Generally the community will 
> cancel the release vote if anyone identifies serious problems, but in most 
> cases the ultimate decision lies with the individual serving as release 
> manager." That's what happened in this recent case. "Many of the things that 
> are wrong in one release should be fixed in the next release" isn't on that 
> page.
> 
> DISCLAIMER-WIP already exists. A podling that wants to make releases that may 
> not comply with all ASF policies can use it today. It asks them to list the 
> issues they know about, which is what makes it worth having.
> 
> Every ASF release already has to comply with the ASF licensing policy. You 
> asked what our goal is. It's podlings that can run an ASF project themselves, 
> and making a compliant release is part of that. Releases are how they learn 
> it, so deferring the requirement is not the right approach.

1disagree and think that deferring full compliance can be acceptable. These are 
Incubating project releases they don’t need to be fully compliant. Yes, a goal 
of incubation is to produce releases compliant with policy, but that’s not the 
only goal of incubation. I think that over-emphasis on legal compliance may 
slow community development.

> 
> Re the recent example - the bigger problem was the release publication. ASF 
> infrastructure published a canceled release under the Foundation's name; that 
> is a serious policy violation.

While Infrastructure has control of some Distribution channels like Maven 
Central, other channels are distributed to newer packaging systems through 
various GHAs provided by those ecosystems. I’m not surprised by this error in a 
new release process.

A future goal of ATR is too begin to handle Distribution Channel publishing at 
the same moment that the release is published to dist/release.

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]

Reply via email to