+1 -- I think users can pick and choose which providers to test and vote on. And since each vote would be in a separate email, a single provider bug in a particular provider won't derail conversation.
Regards, Kaxil On Tue, Mar 9, 2021, 11:38 Kaxil Naik <[email protected]> wrote: > +1 > > On Sat, Mar 6, 2021, 21:33 Ash Berlin-Taylor <[email protected]> wrote: > >> Just for absolutely clarity here: my -1 has nothing to do with the vote >> on the release, merely against adopting the proposed policy after this >> release/current set of votes. >> >> -a >> >> On 4 March 2021 11:04:13 GMT, Ash Berlin-Taylor <[email protected]> wrote: >>> >>> (Split out proposal from voting thread here >>> https://lists.apache.org/thread.html/r47daa0e594eb01c8196a96b62c40d5282b25c41ca1520781934e9236%40%3Cdev.airflow.apache.org%3E >>> .) >>> >>> I don't like the idea of changing what a vote means mid way through. To >>> take an extreme case: >>> >>> "+1 if you like ice cream" >>> >>> *people vote* >>> >>> "Vote now changed to +1 if you kick dogs". >>> >>> Now clearly that is not what you are proposing, but changing what the >>> vote is on at all opens a slippery slope and I'd rather we didn't >>> continue/codify this precedent. >>> >>> *This gets a -1 from me on adopting this part of the proposal.* >>> >>> Not changing the vote is also why I favour many smaller releases/votes: >>> a problem with one doesn't block the others, and additional I feel it is >>> easier for non-core contributors to get involved and test just the provider >>> they are interested in, without feeling daunted that they would have to >>> test all the rest to cast their vote. >>> >>> Much of the release process is already automated, up-to-and including >>> sending emails (dev/send_email.py -- may need tweaking for provider release >>> votes.) so this is can be achieved with little extra work to the release >>> manager. >>> >>> To be clear, I do not have a problem with batch releases and batch votes >>> (even if it is not my first choice, and I would rather N parallel votes as >>> default.) >>> >>> -ash >>> >>> >>> On Wed, 3 Mar, 2021 at 22:44, Jarek Potiuk <[email protected]> wrote: >>> >>> I just wanted to use the opportunity to describe the current process for >>> deciding providers, because apparently not everyone is aware that we >>> already have an established and documented process for provider's releases >>> that was discussed on the devlist and it is documented in our release >>> process description. >>> >>> Possibly we will extract it into a separate policy and maybe discuss >>> some aspects of it (the discussion was raised today at the dev call of ours >>> but I wanted to make sure that we are all referring to the same "starting >>> point" and the "process" I based my recent actions on. >>> >>> *1) Batching the providers as the default* >>> >>> The decision on when to release and particularly preference for >>> releasing providers in batches is described in the >>> https://github.com/apache/airflow/blob/master/dev/README_RELEASE_PROVIDER_PACKAGES.md#decide-when-to-release >>> >>> >>> > Decide when to release >>> > You can release provider packages separately from the main Airflow on >>> an ad-hoc basis, whenever we find that >>> a given provider needs to be released - due to new features or due to >>> bug fixes >>> You can release each provider package separately, but due to voting and >>> release overhead we try to group >>> releases of provider packages together. >>> >>> *2) Possibility of excluding certain packages from the release.* >>> >>> The possibility of excluding certain packages which (for whatever >>> reason) we decide to remove at the discretion of release manager is >>> described here: >>> https://github.com/apache/airflow/blob/master/dev/README_RELEASE_PROVIDER_PACKAGES.md#prepare-voting-email-for-providers-release-candidate >>> <https://github.com/apache/airflow/blob/master/dev/README_RELEASE_PROVIDER_PACKAGESmd#prepare-voting-email-for-providers-release-candidate> >>> >>> Prepare voting email for Providers release candidate >>> ... >>> >>> > Due to the nature of packages, not all packages have to be released as >>> convenience packages in the final release. During the voting process the >>> voting PMCs might decide to exclude certain packages from the release if >>> some critical problems have been found in some packages. >>> >>> And the process of removing it is part of the described release process: >>> >>> > In case you decided to remove some of the packages. remove them from >>> dist folder now: >>> >>> > ls dist/*<provider>* >>> > rm dist/*<provider>* >>> >>> The issue of excluding certain packages have been discussed in this >>> thread in the mailing list : >>> https://lists.apache.org/thread.html/rc620a8a503cc7b14850c0a2a1fca1f6051d08a7e3e6d2cbdeb691dda%40%3Cdev.airflow.apache.org%3E >>> - where we had a -1 veto from a PMC member on the whole batch of providers >>> where we found a cncf.kubrenetes and google providers had critical >>> problems. >>> >>> We discussed it then and the two PMC members proposed a solution that >>> was not objected to by anyone in the VOTE thread - to remove the packages >>> from the batch. >>> >>> I continued this in the continuation of the voting thread >>> https://lists.apache.org/thread.html/r752c5d5171de4ff626663d30e1d50c4b0d2994f66bf8918d816dabd8%40%3Cdev.airflow.apache.org%3E >>> with the following message which specifically pointed out to my proposal >>> where I specifically linked to the message above and asked for comments. >>> >>> > As discussed before: -1 on a single provider does not invalidate the >>> whole >>> vote (from >>> >>> https://github.com/apache/airflow/tree/master/dev#vote-and-verify-the-backport-providers-release-candidate >>> ): >>> >>> > "Due to the nature of backport packages, not all packages have to be >>> released as convenience packages in the final release. During the voting >>> process the voting PMCs might decide to exclude certain packages from the >>> release if some critical problems have been found in some packages." >>> >>> > We will merge the fix and most likely release a new google package >>> right >>> after this one. Looking at the super-localized problem here my current >>> decision will be to release 2020.10.29 'google package" - together with >>> other packages and release 2020.11.01 (or smth) - but only the google >>> one - >>> right after we merge the fix. >>> >>> > Any comments to that? >>> >>> >>> >>>
