ink especially for parent poms we should pay extra attention.
>
> Chris
>
>
>
>
>
> Von: Jarek Potiuk
> Datum: Freitag, 1. September 2023 um 09:24
> An: dev@community.apache.org
> Betreff: Re: Releasing with lazy consensus
> I would love to hear about it, but I belie
> "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 anot
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
rele
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
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 votin
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 reco
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
> m
