I think it's no difference than 'non-individual` - generally speaking in the ASF all responsibilities and "expectations" are towards individuals, not organization - so having two people who commit to be "stewards" of particular provider are I think the requirement - their name / ids will be recorded and we will add some tooling to notify them and to make it easy for them to see open issues per provider and PRs that should be reviewed.
The idea is that each provider eventually has **someone** who says "I am willing to make sure issues and reviews are handled in a somewhat timely manner and I am willing to be the person who signed up for this". This cannot be enforced, and of course it's voluntary, but I think a good thing could be that whoever is listed there will pay attention and in case they stop having incentive they will find someone to take care of it - even by announcing that in the devlist. And if we find that there is not enough interest in maintaining the provider, we will just move it to the attic (unless it reaches the "mature" state). We have discussed it at the last status meeting that the "mature" status will be added to the proposal of how we manage providers and something that PMC will be able to review and agree on a case-by-case basis. It's all about making sure there are at least a few people who are "OK" to be bugged about things in a provider, and that are at least initially committed to responding to issues and questions (subject to monitoring and decisions of the PMC). In some cases the PMC itself might be marked as "Stewards" (things like SMTP, HTTP and the like) - but in case of "other providers" - there needs to be someone who is clearly stewarding it. J. On Mon, Nov 17, 2025 at 8:33 AM <[email protected]> wrote: > Hey, > > I did go through the new proposal. I have few questions regarding new > provider, i.e, mariadb in my case. I am working on this along one of my > team member and we are ready to support this in future as well. Will that > suffice the proposal? Also was curious how someone as an individual > contribute provider in future? Open for discussions. > > Thanks, > Pratush > > On 2025/10/21 09:13:19 Jarek Potiuk wrote: > > I think once we go through the current bugfisinv process, we should > > come-back to the discussion. > > > > There are a couple of preparatory things in general that I think can > start > > happen regardless (there are a couple of unresolved questions in our > > provider process - such as dependent providers discussion), we need to > make > > a few changes to the release process to be able to handle parallel > > "batches" of providers, and we should "properly" produce source packages > > for the batches versioned with date of release ( > > https://github.com/apache/airflow/issues/47343 issue describing it). I > will > > attempt to make those things that are needed for the discussions to > > continue - to be addressed before - so I might start a separate > discussion > > or two - would love those interested to take part in those discussions in > > the meantime. > > > > J. > > > > > > On Wed, Sep 17, 2025 at 4:00 PM Vincent Beck <[email protected]> wrote: > > > > > Aside from a few details that still need refinement, I support this > idea. > > > I believe it’s the only viable way to continue expanding the number of > > > integrations Airflow supports without overloading the provider release > > > manager. The responsibility for releasing providers would be scaled > out, > > > rather than concentrated as it is today, which I see as a great > > > improvement. That said, I agree with Jarek’s comments—responsibilities > > > across individuals will need to be clearly defined, agreed upon, and > well > > > understood to ensure the Airflow ecosystem continues to function > smoothly. > > > > > > On 2025/09/17 12:39:45 Stephen Mallette wrote: > > > > As a more casual observer of what happens here in Airflow, I don't > have > > > any > > > > first hand knowledge of the problems faced beyond what was described > in > > > the > > > > Motivation section of the proposal. That said, I did read through it > and > > > > was curious about the deprecation path that was described. I > understand > > > > that the path leaves open room for exception and that the > quantitative > > > > definitions are likely there to help guide PMC decisions, but I > wonder if > > > > it would make sense to describe wider exceptions for more mature > > > providers > > > > that don't require lots of new features/maintenance. That might help > > > reduce > > > > the scope of the PMC quarterly provider review while also reducing > the > > > > chance of providers gaming the system and/or sparing them a bit of > worry > > > > that they miss a quarterly chance to discuss an exception with the > PMC. > > > > > > > > > > > > > > > > On Tue, Sep 16, 2025 at 9:14 PM Jarek Potiuk <[email protected]> > wrote: > > > > > > > > > Comment from my side: I think this is a really good idea to discuss > > > > > **what** we need from the community side to make it "easy" for > > > providers to > > > > > be contributed and maintained - without over-burdening the > maintainers. > > > > > This is by far the most important aspect of this proposal - and I > > > think it > > > > > would be fantastic if we hear feedback from Amazon, Google. > Astronomer, > > > > > Teradata and others who recently submitted providers to Airflow - > and > > > of > > > > > course all maintainers that might be worried about impact it will > have > > > on > > > > > our maintenance efforts. > > > > > > > > > > I think before we approve this one and start following it - all > parties > > > > > involved (maintainers, release managers ,contributors, PMC members, > > > > > stakeholders) will need to agree on understanding: > > > > > > > > > > * what is required from them (everyone - stakeholders, > contributors. > > > > > maintainers, PMC members, release managers will have their parts > in the > > > > > process). > > > > > * what they will have to commit to > > > > > * what kind of tooling will be needed to make it as efficient as > > > possible > > > > > without overburdening everyone > > > > > > > > > > We are way ahead with tooling and modularisation of airflow than we > > > were a > > > > > year ago and I think changes and improvements in the tooling and > > > process > > > > > updates needed to get the process in place are within our reach > now. > > > This > > > > > is the reason why I think it's the **right** time to discuss it. It > > > will > > > > > take a couple of months to complete all the needed changes, but it > all > > > > > seems doable. > > > > > > > > > > Also - I have discussed it with Apache Software Foundation > leadership > > > at > > > > > Community Over Code in Minneapolis - and they are interested and > > > supported > > > > > in us trying this approach where we want to get Stakeholders more > > > involved > > > > > and more accountable, while keeping the Apache Way approach, so we > > > should > > > > > have green light from the Foundation on it. > > > > > > > > > > J. > > > > > > > > > > > > > > > On Tue, Sep 16, 2025 at 12:02 PM Vikram Koka via dev < > > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > Dear Airflowers, > > > > > > > > > > > > Every few days, we get a request for adding a new Provider (aka > > > > > > Integration) into Apache Airflow. We would like to say yes to > most > > > if not > > > > > > all of these, but we have had challenges in being able to absorb > many > > > > > more > > > > > > providers into Airflow. > > > > > > > > > > > > We have had multiple conversations around this in the past, and > we > > > would > > > > > > like to discuss a proposal to enable us to adopt many more > > > integrations > > > > > to > > > > > > Airflow. At this stage, this is an early draft intended to get > your > > > > > > feedback. > > > > > > > > > > > > I know a lot of us are working on releasing Airflow 3.1.0, so I > don't > > > > > > expect a lot of conversation this week, but wanted to socialize > this > > > with > > > > > > the broader community at the same time. > > > > > > > > > > > > Proposal > > > > > > < > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/Provider+lifecycle+update+proposal > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/Provider+lifecycle+update+proposal > > > > > > > > > > > > Best regards, > > > > > > Vikram, Jarek, Kaxil, Pavan, and Ash > > > > > > -- > > > > > > > > > > > > Vikram Koka > > > > > > Chief Strategy Officer > > > > > > Email: [email protected] > > > > > > > > > > > > > > > > > > <https://www.astronomer.io/> > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > Sent from my iPhone
