+1 On Sat, Mar 6, 2021, 21:33 Ash Berlin-Taylor <a...@apache.org> 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 <a...@apache.org> 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 <ja...@potiuk.com> 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? >> >> >> >>
