Thanks for sharing insights from the Airflow land, much appreciated. "Bulk" voting is something I have heard before. Certainly can be a solution *if* the packages don't depend on each other. Otherwise I cannot see how it helps with the cases I shared earlier. That is, `log4j-core` needs to be released first so that `log4j-bom` can be updated and released. Put another way, both can't be released simultaneously.
On Fri, Sep 1, 2023 at 9:24 AM Jarek Potiuk <ja...@potiuk.com> wrote: > 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? > > >
