This is a bit of a grey area, so I would love to hear the opinion of others.
From my perspective a vote is only needed when doing a release of the source code, all the other things fall under the “convenience binaries/artifacts" So things like docker images/BOM/packaging based on the source code do not need to be voted upon. We usually combine all these things because if something isn’t working a change to the source would be required which would result in a new vote. There are other things we do which do not require a vote. We do not vote on documentation/site changes (thy might or might not be linked to a release). A BOM project is not really a mandatory thing to build/use the software so I would say just like a website it could fall outside of what you are releasing and thus not need a vote…. Kr, Hans On 1 Sep 2023 at 09:24 +0200, 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? > >
