> Just because some projects might be doing it, doesn’t mean it’s ok
This precisely captures my thoughts too. Though I feel stuck at this point.
There are a significant number of projects reaching out to this practice,
yet it is officially not allowed. Then what? Who shall I consult to outline
(and implement?) a way forward that is both legal and convenient for PMCs?
On Fri, Sep 1, 2023 at 9:42 AM Christofer Dutz
wrote:
> 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
> 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 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
