incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Airflow voting on release artifacts
Date Tue, 25 Apr 2017 15:33:42 GMT

On 4/25/17, 1:43 AM, "Bolke de Bruin" <> wrote:

>Hi Bertrand,
>> On 25 Apr 2017, at 09:04, Bertrand Delacretaz
>><> wrote:
>> Hi,
>> On Mon, Apr 24, 2017 at 10:18 PM, Chris Riccomini
>><> wrote:
>>> ...Hitesh recently raised the issue that the artifact that passes the
>>> MUST be the one that we actually release...
>> Yes in terms of having the same binary digests and signatures, but
>> renaming the files is fine IMO, especially for removing an -rc suffix
>> which makes total sense. I would just add that step to your release
>> process documentation to make it clear.
>>> ...Rename/rebuild after final vote (This is what Airflow is doing, and
>>> does this, I believe)...
>> I'd say rename yes but rebuild no, in order to keep the same digests
>> and signatures.
>As mentioned earlier, that seems not to be possible. The metadata
>(filename) and version information inside the package need to be in sync.
>This how the python build tools and python ecosystem works.

I'm not familiar with Python, but is it possible to have a command line
option that adds the "-rc" suffix in the right places?

IMO, there are two "audiences".  One is the voters, and one is your
customers.  The customers should not be using the RC until after it is
approved unless they are volunteering to be a voter.  Voters are primarily
supposed to examine a source artifact, but if you also release a
"convenience binary" artifact, there are some examinations of that
"binary" artifact required.  For many projects this "convenience" artifact
is the one that the vast majority of customers consume.  AIUI, Python
doesn't have binaries, but IMO, there is no requirement that this
"convenience" artifact actually contains binaries.  A "convenience"
artifact is just supposed to be the source artifact processed by a build
script since many of your customer may not have, or may not want to
configure their machines to run whatever build script engine you choose
for your project.  Further, there is no requirement that I know of that
voters must test the "convenience" artifact by actually running it.  It
just makes sense to do so in most cases.  But if Python is interpreted
source, you may be able to use this to your advantage.

So, your source package should consist of the source and build script
required to build this "customer"/"convenience" package, and the build
script should allow a command line option to add the "-rc" suffix.  Then
voters would be instructed to download the source package, and to test it,
build a "customer" package with the "-rc" suffix and test the results.
And voters would also be instructed to download the "customer" package
that doesn't have the -rc suffix.  But in order to test it, they only have
to diff that package against the "customer" package they built from the
source package.  It should be the same except for the metadata.

We'll see if others can find a problem with this plan, but IMO, that would
be good enough for me as an PMC voter.


View raw message