Very good idea, thanks for the pointers. I will open a PR this week
to update our doc :)
Best regards,
Le mer. 14 déc. 2022 à 22:56, Jarek Potiuk a écrit :
> Good point. We should document such things every time in READMEs - and in
> this case it should not only be READMEs but also appropriate
Good point. We should document such things every time in READMEs - and in
this case it should not only be READMEs but also appropriate steps in the
release process IMHO.
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md
Initially it could be pretty vague - we usually perfe
Pierre do we have this decision documented in the README so users are aware
of the policy ? (also I guess better to be written in the release docs
procedure)
On Thu, Dec 8, 2022 at 7:50 PM Pierre Jeambrun
wrote:
> Hello all,
>
> 72h hours have passed without opposition, therefore the proposal is
Hey Denis,
> tests/providers/airbyte/hooks
> tests/providers/airbyte/operators
> tests/providers/airbyte/sensors
> tests/providers/airbyte/system
> tests/providers/airbyte/transfers
Yes. It could be done like that - but it would require merging some
packages (there are for example already "system
BTW. Welcome to the club Elad :)
gpg: assuming signed data in
'apache-airflow-providers-microsoft-azure-5.0.1.tar.gz'
gpg: Signature made Tue 13 Dec 2022 21:27:49 CET
gpg:using EDDSA key 8340EF04090A243BDBC3454586E088663ECCDEBE
gpg:issuer "elad...@apache.org"
gpg: G
+1 (binding) - tested licences, signatures, checksums. Verified that the
changes I implemented are in the release.
On Wed, Dec 14, 2022 at 1:01 AM Elad Kalif wrote:
> Hey all,
>
>
>
> I have just cut ad-hoc wave Airflow Providers packages. This email is
> calling a vote on the release,
>
> which
