incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: Airflow voting on release artifacts
Date Mon, 01 May 2017 21:42:24 GMT
Sorry for my ignorance, but is there no easy way with pip to uninstall the
package or force-install a new RC?

If a previous RC failed the vote, then it should be uninstalled by everyone
anyway. In fact if you test a RC by installing it globally, then you should
always uninstall it after testing as you don't know the result of the vote
yet and should revert to the latest official release (or your own build
from scm).

This is no different from Java/Maven - if you happen to test an RC by "mvn
install" (instead of "mvn verify") then you need to clean it out
afterwards. There is no easy command for it in mvn, although you can
usually just rm -rf the corresponding folder in .m2/repository.

On 1 May 2017 10:00 pm, "Bolke de Bruin" <> wrote:

> On 1 May 2017, at 22:39, Alex Harui <> wrote:
> On 5/1/17, 11:44 AM, "Bolke de Bruin" < <mailto:>> wrote:
>>> On 1 May 2017, at 17:36, Alex Harui <> wrote:
>>> On 5/1/17, 7:44 AM, "Hitesh Shah" <> wrote:
>>>> Hi Justin,
>>>> Currently, the podling has been modifying the contents and hence this
>>>> discussion.
>>> I agree with Justin and others that modification after the vote is not a
>>> good thing.  So my assumption was that if you add your 2a step and
>>> modify
>>> the binary before the vote, it will be acceptable.  IMO, all you need
>>> is a
>>> way to verify that the binary the voters test is essentially the same as
>>> the binary you want to actually release.
>>> -Alex
>> Hi Alex,
>> As mentioned earlier this is not possible in a clean way. Version
>> information is contained within the source package and it is required by
>> specification to be. Installation happens from this source package. There
>> are no “binaries”.
>> We understand the need to vote on the artefacts, however the way it is
>> required to work put us between a rock and a hard place: either our users
>> can end up with an outdated pre-release while reporting they have the
>> release installed or we need to vote 2+2 times (PMC+IPMC).
>> We are looking to optimize this process either technically or
>> procedurally, but until so far haven’t been able to distill anything that
>> really helps.
> Well, I'm quite confused now.  Hitesh seems to say there are binaries.
> And I have proposed a couple of ideas where you create different artifacts
> for voters vs. customers that I think get around all of these issues.
> AFAIK, nobody on this list has objected to those proposals.
> Maybe there is something about Python I don't understand, but if I had to
> ship a set of Javascript files with an embedded version number in one of
> those files, I would use what I proposed.  AFAICT, there is no obligation
> to make your customers (not your voters) consume the source package, it
> just has to be possible to generate what the customers use from the source
> package.

In Python we are used to install through so called source distributions
“sdist”. Package managers (e.g. pip) use the filename to determine whether
to download a new package and if they do they examine the contents of the
package to find out it they need to install the package. They do this by
examining the version contained inside the package. Thus while a different
filename will trigger a new download, it might not install updated parts of
the package. This is different from your example as no installer is
examining both the name of the tar ball and the contents of your javascript
files for a version identifier.

But maybe you have a point. We could just do a "git clone”, update the
version (not push it to git until final release), tar it. We then ask
people to vote on it. Then we could provide the convenience package (that
everyone will use) next to it. Or if we consider the “sdist” a binary
release officially we vote on that one as well after the first vote. Two
downsides to this are: if only option 1) nobody would user the tar, as the
sdist is essentially the same and works with the package managers. Might be
a bit excessive? 2) that would be a 2+2 vote again.

Option 1 could work, it isn’t ideal, but will satisfy the procedure.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message