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