Yeah,
thanks for bringing this up … this is actually something I brought up in the
last board meeting.
I also think it’s not ok to release stuff like parent poms with lazy consensus
and was currently following up with ASF Legal on that matter.
Just because some projects might be doing it, doesn’t mean it’s ok … possible
outcome of this might be that this practice will explicitly be forbidden.
My personal reasoning for this:
* With a parent pom, I can
* Manage dependencies to get in vulnerable versions
* Include additional dependencies
* Re-Configure plugins configuration
* Add plugin executions that might do bad stuff
So I think especially for parent poms we should pay extra attention.
Chris
Von: Jarek Potiuk <ja...@potiuk.com>
Datum: Freitag, 1. September 2023 um 09:24
An: dev@community.apache.org <dev@community.apache.org>
Betreff: Re: Releasing with lazy consensus
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?
>
