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> >> >> 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? > > >
