You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Pierre Jeambrun <pi...@gmail.com> on 2023/03/07 20:11:47 UTC
[LAZY CONSENSUS] Allow shorter voting periods for subsequent RCs
Hi all,
*Context:*Having a 72h vote window on each subsequent RCs can slow down the
release process, bring some annoyance and add load on the release manager.
This could be avoided, especially when the new RC only ships a few extra
commits. This proposal would bring some flexibility to the voting process
against subsequent RCs. (rcX with X > 1)
*Proposal:*
For Airflow Core, Providers and API Clients, at the discretion of the RM,
subsequent RCs vote windows can be shortened down to a hard minimum of 24
hours. Also the sum of all voting windows for a specific release cannot be
shorter than 72h.
*Examples:*
- An issue was found on rc1 after 24h then rc2 voting window can be
shortened down to 48h.
- An issue was found on rc1 after 70h then rc2 voting window can be
shortened down to 24h. (hard minimum)
- An issue was found on rc1 after 12h then rc2 voting window can be
shortened down to 60h.
- An issue was found on rc1 after 12h and an issue was found on rc2 after
24h then rc3 voting window can be shortened down to 36h. If an issue is
then found on rc3 after 24h, rc4 can be shortened down to 24h. (hard
minimum again)
*Discussion thread:*
https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
After 72 hours, unless there is an objection, this proposal will be adopted
and we can start applying it to our releases.
Thanks,
Pierre
Re: [LAZY CONSENSUS] Allow shorter voting periods for subsequent RCs
Posted by Elad Kalif <el...@apache.org>.
Added reference for this thread in relevant release docs
https://github.com/apache/airflow/pull/30037
On Fri, Mar 10, 2023 at 10:12 PM Pierre Jeambrun <pi...@gmail.com>
wrote:
> 72 hours have passed, we will start using this policy for our future
> releases.
>
> Thanks
>
> Le mar. 7 mars 2023 à 21:29, Ferruzzi, Dennis <ferruzzi@amazon.com.invalid
> >
> a écrit :
>
> > +1 (non-bindingly lazy)
> >
> >
> > ________________________________
> > From: Pierre Jeambrun <pi...@gmail.com>
> > Sent: Tuesday, March 7, 2023 12:11 PM
> > To: dev@airflow.apache.org
> > Subject: [EXTERNAL] [LAZY CONSENSUS] Allow shorter voting periods for
> > subsequent RCs
> >
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you can confirm the sender and
> know
> > the content is safe.
> >
> >
> >
> > Hi all,
> >
> >
> > *Context:*Having a 72h vote window on each subsequent RCs can slow down
> the
> > release process, bring some annoyance and add load on the release
> manager.
> > This could be avoided, especially when the new RC only ships a few extra
> > commits. This proposal would bring some flexibility to the voting process
> > against subsequent RCs. (rcX with X > 1)
> >
> > *Proposal:*
> > For Airflow Core, Providers and API Clients, at the discretion of the RM,
> > subsequent RCs vote windows can be shortened down to a hard minimum of 24
> > hours. Also the sum of all voting windows for a specific release cannot
> be
> > shorter than 72h.
> >
> > *Examples:*
> > - An issue was found on rc1 after 24h then rc2 voting window can be
> > shortened down to 48h.
> > - An issue was found on rc1 after 70h then rc2 voting window can be
> > shortened down to 24h. (hard minimum)
> > - An issue was found on rc1 after 12h then rc2 voting window can be
> > shortened down to 60h.
> > - An issue was found on rc1 after 12h and an issue was found on rc2 after
> > 24h then rc3 voting window can be shortened down to 36h. If an issue is
> > then found on rc3 after 24h, rc4 can be shortened down to 24h. (hard
> > minimum again)
> >
> > *Discussion thread:*
> > https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
> >
> > After 72 hours, unless there is an objection, this proposal will be
> adopted
> > and we can start applying it to our releases.
> >
> > Thanks,
> > Pierre
> >
>
Re: [LAZY CONSENSUS] Allow shorter voting periods for subsequent RCs
Posted by Pierre Jeambrun <pi...@gmail.com>.
72 hours have passed, we will start using this policy for our future
releases.
Thanks
Le mar. 7 mars 2023 à 21:29, Ferruzzi, Dennis <fe...@amazon.com.invalid>
a écrit :
> +1 (non-bindingly lazy)
>
>
> ________________________________
> From: Pierre Jeambrun <pi...@gmail.com>
> Sent: Tuesday, March 7, 2023 12:11 PM
> To: dev@airflow.apache.org
> Subject: [EXTERNAL] [LAZY CONSENSUS] Allow shorter voting periods for
> subsequent RCs
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> Hi all,
>
>
> *Context:*Having a 72h vote window on each subsequent RCs can slow down the
> release process, bring some annoyance and add load on the release manager.
> This could be avoided, especially when the new RC only ships a few extra
> commits. This proposal would bring some flexibility to the voting process
> against subsequent RCs. (rcX with X > 1)
>
> *Proposal:*
> For Airflow Core, Providers and API Clients, at the discretion of the RM,
> subsequent RCs vote windows can be shortened down to a hard minimum of 24
> hours. Also the sum of all voting windows for a specific release cannot be
> shorter than 72h.
>
> *Examples:*
> - An issue was found on rc1 after 24h then rc2 voting window can be
> shortened down to 48h.
> - An issue was found on rc1 after 70h then rc2 voting window can be
> shortened down to 24h. (hard minimum)
> - An issue was found on rc1 after 12h then rc2 voting window can be
> shortened down to 60h.
> - An issue was found on rc1 after 12h and an issue was found on rc2 after
> 24h then rc3 voting window can be shortened down to 36h. If an issue is
> then found on rc3 after 24h, rc4 can be shortened down to 24h. (hard
> minimum again)
>
> *Discussion thread:*
> https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
>
> After 72 hours, unless there is an objection, this proposal will be adopted
> and we can start applying it to our releases.
>
> Thanks,
> Pierre
>
Re: [LAZY CONSENSUS] Allow shorter voting periods for subsequent RCs
Posted by "Ferruzzi, Dennis" <fe...@amazon.com.INVALID>.
+1 (non-bindingly lazy)
________________________________
From: Pierre Jeambrun <pi...@gmail.com>
Sent: Tuesday, March 7, 2023 12:11 PM
To: dev@airflow.apache.org
Subject: [EXTERNAL] [LAZY CONSENSUS] Allow shorter voting periods for subsequent RCs
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Hi all,
*Context:*Having a 72h vote window on each subsequent RCs can slow down the
release process, bring some annoyance and add load on the release manager.
This could be avoided, especially when the new RC only ships a few extra
commits. This proposal would bring some flexibility to the voting process
against subsequent RCs. (rcX with X > 1)
*Proposal:*
For Airflow Core, Providers and API Clients, at the discretion of the RM,
subsequent RCs vote windows can be shortened down to a hard minimum of 24
hours. Also the sum of all voting windows for a specific release cannot be
shorter than 72h.
*Examples:*
- An issue was found on rc1 after 24h then rc2 voting window can be
shortened down to 48h.
- An issue was found on rc1 after 70h then rc2 voting window can be
shortened down to 24h. (hard minimum)
- An issue was found on rc1 after 12h then rc2 voting window can be
shortened down to 60h.
- An issue was found on rc1 after 12h and an issue was found on rc2 after
24h then rc3 voting window can be shortened down to 36h. If an issue is
then found on rc3 after 24h, rc4 can be shortened down to 24h. (hard
minimum again)
*Discussion thread:*
https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
After 72 hours, unless there is an objection, this proposal will be adopted
and we can start applying it to our releases.
Thanks,
Pierre