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. 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. Kind regards, Justin --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
