+1

On Wed, Mar 29, 2023 at 8:29 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> The consensus will be reached in 72H on Saturday 1st of April 8.30pm
> CEST (unless there is a dissent).
>
> On Wed, Mar 29, 2023 at 8:18 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > Hello everyone,
> >
> > Here is a formal ask for consensus on the new process of suspending
> > some providers that hold us back from upgrading old dependencies.
> >
> > It has been discussed in
> > https://lists.apache.org/thread/j98bgw9jo7xr4fvjh27d6bfoyxr1omcm and
> > since it seems we have a consensus, I am calling for one (you do not
> > have to respond +1, this is what lazy consensus is about - but feel
> > free to do so).
> >
> > The proposed wording is in the PR:
> https://github.com/apache/airflow/pull/30359
> >
> > Copying it below for reference (might get slightly modified during
> review):
> >
> > --------------------------
> >
> > ### Suspending releases for providers
> >
> > In case a provider is found to require old dependencies that are not
> > compatible with upcoming versions of
> > the Apache Airflow or with newer dependencies required by other
> > providers, the provider's release
> > process can be suspended.
> >
> > This means:
> >
> > * The provider's status is set to "suspended"
> > * No new releases of the provider will be made until the problem with
> > dependencies is solved
> > * Sources of the provider remain in the repository for now (in the
> > future we might add process to remove them)
> > * No new changes will be accepted for the provider (other than the
> > ones that fix the dependencies)
> > * The provider will be removed from the list of Apache Airflow extras
> > in the next minor/major release
> >   (2.7.0, 2.8.0, 3.0.0 etc.)
> > * Tests of the provider will not be run on our CI (in main branch)
> > * Dependencies of the provider will not be installed in our main
> > branch CI image nor included in constraints
> >
> > The suspension might be triggered by any committer, providing that:
> >
> > * The maintainers of dependencies of the provider are notified about
> > the issue and are given a reasonable
> >   time to resolve it (at least 1 week)
> > * Other options to resolve the issue have been exhausted and there are
> > good reasons for upgrading
> >   the old dependencies in question
> > * Explanation, why we need to suspend the provider is stated in a
> > public discussion in the devlist. Followed
> >   by LAZY CONSENSUS or VOTE (with the majority of the committers
> > agreeing that we should suspend the provider)
> >
> > The suspension will be lifted when the dependencies of the provider
> > are made compatible with the Apache
> > Airflow and with other providers.
> >
> > J.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
> For additional commands, e-mail: dev-h...@airflow.apache.org
>
>

-- 
Eugene

Reply via email to