> Will we mark providers in incubation with a "Not Ready" state or will we seggregate them into a different folder hierarchy for the time-being in the repo?
I think some internal status/state will be needed - more than "not ready" - but I do not think we need to have separate folder - i think personally the status is important for two things: * tracking the progress and seeing how the provider is doing (and we should have a dashboard for that) * clear information in the docs and PyPI that the status of the software is "incubating" - but this should be "user" focused. Similarly it is likely important on how we expose the sources in "downloads.apache.org" (this is where we publish sources for downstream consumptions - for those who use sources). I think it's reasonable to assume that those users who actually look at our repo are already "contributors" and at least will know where to look for it, more important is what is in the package. In many ways Github Repo (and repo in general) when we are referring to users is treated as "work in progress" and "really used only for contributions" - but the sources published on downloads and especially for the "actual daily users" PyPI status and information are more important. So I guess "incubating" status in provider.yaml + dashboard with status + appropriate disclaimer in pypi README and possibly `-incubating-sources.tar.gz` name for the source artifact (or maybe we can figure different naming - we know naming is hard), should be quite enough. J. On Wed, Nov 26, 2025 at 8:05 PM Jens Scheffler <[email protected]> wrote: > I am "all in" with this. Looking forward to increase the ecosystem > assuming that with this approach we can also delegate into community. > > Will we mark providers in incubation with a "Not Ready" state or will we > seggregate them into a different folder hierarchy for the time-being in > the repo? > > On 11/26/25 18:38, Pankaj Koti via dev wrote: > > Sounds exciting. Thanks for sharing the proposal for the updated > governance > > process here, Vikram! > > > > On Wed, Nov 26, 2025 at 9:33 PM Vikram Koka via dev < > [email protected]> > > wrote: > > > >> With respect to the thresholds, that's exactly the intent. > >> As we measure and publish, we will be able to determine the right > >> thresholds. > >> > >> On Tue, Nov 25, 2025 at 4:24 PM Jarek Potiuk <[email protected]> wrote: > >> > >>> I have no more questions. I know the numbers will not be correct at the > >>> beginning and we will have to adjust it, but I think before we try, we > >>> won't know - so we have to start with something. A lot of decisions are > >>> eventually at the discretion of the PMC - and I think once we automate > a > >>> lot of those dashboard, stats etc. we will gradually learn what makes > >>> sense as thresholds to look at. > >>> > >>> On Tue, Nov 25, 2025 at 10:05 PM Vikram Koka via dev < > >>> [email protected]> wrote: > >>> > >>>> Oh, and for those who may be wondering how the dashboard metrics of > >>>> provider activity could potentially work, there is an early draft of > an > >>>> activity tracker is on the Airflow 3.x wiki page > >>>> <https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+3.x> > >>>> > >>>> > >>>> On Tue, Nov 25, 2025 at 12:26 PM Vikram Koka <[email protected]> > >>>> wrote: > >>>> > >>>>> Dear Airflowers, > >>>>> > >>>>> Following up the action item from the discussion in the dev call last > >>>>> week, I updated the AIP (Airflow Improvement Proposal) for the > >>>>> updated provider governance process. > >>>>> > >>>>> The summary of changes are: > >>>>> 1. Introduction of a "Mature" stage for Providers in addition to the > >>>>> proposed "Incubation", "Production", and "Attic / Deprecation" to > >>>> account > >>>>> for those integrations which are stable and therefore don't need to > >> have > >>>>> additional activity on a monthly basis. > >>>>> > >>>>> 2. Deferred to future possibilities, the idea of splitting the > >> Provider > >>>>> repo from the existing mono-repo, and also changing the release > >>>>> distribution policy. In other words, we will no longer be splitting > >> the > >>>>> provider repos from the existing mono-repo. > >>>>> > >>>>> > >>>>> > >> > https://cwiki.apache.org/confluence/display/AIRFLOW/Provider+lifecycle+update+proposal > >>>>> I deliberately didn't move the existing sections, so that I could > >>>> preserve > >>>>> the comments in the discussion. > >>>>> > >>>>> Please review this updated version of the document. > >>>>> If there are no further concerns, I plan to bring this up for a vote > >>>> next > >>>>> week. > >>>>> > >>>>> Best regards, > >>>>> Vikram > >>>>> -- > >>>>> > >>>>> 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] > >
