I am aware that certain projects follow this [LAZY][VOTE] convention. But I am not able to read our release policy in such a way to allow that. What I would appreciate is that somebody pointing me to a certain part of the policy and explaining the legal room for this [LAZY][VOTE] act.
For the record, the release post you shared still has the following statement: *"This vote will close no sooner than 72 hours from now"* of which I am trying to cut down on. On Fri, Sep 1, 2023 at 8:56 AM Richard Zowalla <r...@apache.org> wrote: > The commons project often releases their parent pom with lazy > consensus, for example: > https://lists.apache.org/thread/34onls4fw189smx5gjznkk8z80t3j6lc > > Am Freitag, dem 01.09.2023 um 08:52 +0200 schrieb Volkan Yazıcı: > > 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? > >
