I would love to hear about it, but I believe releasing any software is an "act of Foundation" and requires 3 explicit PMC members to say "+1" in order for it to have legal repercussions.
So I am not so sure if releasing "software" of any kind that can be "ASF software" should be done without voting and 3 PMC members saying +1. In fact even the roll calls done by the board when the projects are not active is to check "Is there enough (3) active PMC members for the PMC to make a release). I believe in justified cases however, you can shorten the voting period or even vote in "secret" and announce the voting later (for example when you have security release). The process says that there SHOULD be 72 HRs (not MUST) and if there are good reasons, it can be shortened. But the act of voting and 3 +1 from the PMC members is - I believe - obligatory. A comment on how we deal with possibly similar cases in Airflow - where we often release up to 90(!) packages 2 times a month (!). Maybe that can help with designing a similar process. * we allow "bulk" voting. We prepare the "up to 90" provider packages as a single "pack" of things we vote on. We have automation and tooling that allows us to both release and verify (by PMC members) all those packages together. We also involve the contributors and those who raised relevant issues in testing those packages (also heavily automated - example issue generated here https://github.com/apache/airflow/issues/33305 ) - this is nice because it allows us to streamline the process and release multiple things together, whil allow individuals to focus on testing all such packages individually and report it back in that single place where we discuss the whole "release pack". * when a bug / release/packaging/sources/problem is found in only one of those packages (which does not invalidate the rest) the release manager can decide to withdraw those faulty packages from that release "pack" but this does not remove +1 votes that were given for the ones that are good. * after releasing the "good" packages (and parallel fixing of the broken ones) - the broken ones are released with fixes as RC2 candidates. In most cases the fixes are really small, so the "user" testing (i.e. what has been tested and confirmed working so far) status is carried over to the RC2 candidates. The PMC voting for those RC2 is restarted (i.e. we need three new +1 from the PMC) . But this time we turn on "accelerated" voting. We agree to the rule that in this case 24H (and 3 PMC +1s) is enough for the vote to complete. * the 72HR -> 24 HR is only done when there are really small and few fixes since RC1 This has been discussed at the devlist, agreed and captured in our processes. For those interested: Discussion about introducing RC2+ accelerated voting : https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16 Lazy consensus on approving it: https://lists.apache.org/thread/cv194w1fqqykrhswhmm54zy9gnnv6kgm Example recent vote result where two packages have been excluded due to bugs but where release manager decided not to accelerate the voting due to big number of fixes coming since RC1: https://lists.apache.org/thread/1kovpkx0t2pm2xrwf61ycqdynp0kdl19 Example vote where we had 24 HR accelerated vote: https://lists.apache.org/thread/ndm71tjdd3mmx7s904ds6sqxy84vb1fw (BTW We also had RC3 for google provider as another bug was found in RC2). - those rules are transitive. RC3 was also accelerated. I hope it helps. J. On Fri, Sep 1, 2023 at 8:53 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > Is such a thing possible? It is pretty common that many Java projects have > multiple modules having their own release cycles. Some of these modules are > miscellaneous "utilities" to support the rest of the code base. Common > examples I can think of are > > - BOM project covering a dozen other projects (e.g., `log4j-bom` for > `log4j-core`, `log4j-layout-template-json`, etc.) > - Utilities (e.g., `log4j-changelog` used to maintain a changelog and > release notes for Java-based Logging Services projects) > > `log4j-core` release takes 72 hours due to voting. Once that is done, > waiting another 72 hours for `log4j-bom` feels like a waste of time. > Similarly, `log4j-changelog` is an internally used tool, yet we need to > publish it to Maven Central and such. Wouldn't it be possible to release > such projects (e.g., `log4j-bom`, `log4j-changelog`) with lazy voting? That > is, *"unless there are objections within 24 hours, I'll assume a lazy > consensus, and release it".* Can the Release Policy > <https://www.apache.org/legal/release-policy.html> and/or the Voting > Process > <https://www.apache.org/foundation/voting.html> accommodate such a > practice? >
