> "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.
Oh yeah. Those we have a fair share of. Even in the last release we had a chicken-egg problem of dependencies and we had to split and manually tweak the release process - that was a bit of a headache. Maybe what will help - in essence with Airflow we do keep two "separate" release trains a) core airflow <- single package release b) providers <- this is where the bulk voting happens (and here often happens that there are cross-dependencies between them - but when you release them together it's fine) But sometimes we release certain "providers" first even if they are not "usable" - precisely so that the later "core airflow" release makes use of them. So "smart" splitting the releases might also help. J On Fri, Sep 1, 2023 at 10:25 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > 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? > > > > > >
