Re: Airflow voting on release artifacts

I think the problem is lying with "users cannot tell the difference"... Possibly that the term "release candidate" is not aligned/defined along the same semantics. "Users", as in outside the committers, are NOT to download any source/binary artifacts up for a vote. Before the vote artifacts are no

Re: Airflow voting on release artifacts

On 5/1/17, 2:00 PM, "Bolke de Bruin" wrote: > >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 th

Re: Airflow voting on release artifacts

I understand that concern. Why do you think your users install release candidates under vote? It might be time to think about splitting out a users@ list? Perhaps you can expand the instructions in the VOTE email with the exact commands to install and uninstall, or a special test script that enfor

Re: Airflow voting on release artifacts

Yes you can, but how do we verify it actually happened? Maven will, afaik, happily upgrade “apache-beam-1.0.0rc2” to “apache-beam-1.0.0” although they contain the exact same artefact. Pip won’t do that. If we use a release candidate named “apache-airflow-1.8.1rc2” while the package requires us

Re: Airflow voting on release artifacts

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

Re: Airflow voting on release artifacts

> On 1 May 2017, at 22:39, Alex Harui wrote: > > > > On 5/1/17, 11:44 AM, "Bolke de Bruin" > 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 podl

Re: Airflow voting on release artifacts

On 5/1/17, 11:44 AM, "Bolke de Bruin" 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

Re: Airflow voting on release artifacts

> 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

Re: Airflow voting on release artifacts

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 bina

Re: Airflow voting on release artifacts

Hi Justin, Currently, the podling has been modifying the contents and hence this discussion. thanks -- Hitesh On Thu, Apr 27, 2017 at 8:48 PM, Justin Mclean wrote: > Hi, > > > The implication here is that the release manager is being trusted by the > > PMC to release the modified convenience a

Re: Airflow voting on release artifacts

Hi, > The implication here is that the release manager is being trusted by the > PMC to release the modified convenience artifacts from the voted-upon > source without a new vote. How are the artefacts modified after the vote? IMO As long as the hashes and signature are the same there is no iss

Re: Airflow voting on release artifacts

I'm not on the IPMC, so I don't have an official vote, but for me, it would be ok if you include step 2a and the voters have a way to validate that the 1.8.1rc1 binary they tested is "the same"=="identical except for version numbers" as the 1.8.1 binaries you want to distribute to customers. Also,

Re: Airflow voting on release artifacts

Hi folks, Given that the source bits are the official release, would it be okay if the community as a whole decided on say the following approach: 1) Bundle source with version set to 1.8.1 2) Bundle binary convenience artifacts built using version set to 1.8.1rc1 3) Publish source and binary bit

Re: Airflow voting on release artifacts

> >3. There is no “separate” build script. Pip will just install a binary >(“wheel”) or uses the source package (as shown above). Both are used >interchangeable by users. We only distribute source packages at the >moment. > >@Alex: I have to think a little bit more about what you wrote, but it is

Re: Airflow voting on release artifacts

Would virtualenv help by avoiding the "Requirement already satisfied" complaints? On Tue, Apr 25, 2017 at 2:05 PM, Bolke de Bruin wrote: > Thank you thinking with us, that’s really appreciated. Unfortunately, many > of the assumptions from the Java world do not apply to the Python world: > > Ver

Re: Airflow voting on release artifacts

Thank you thinking with us, that’s really appreciated. Unfortunately, many of the assumptions from the Java world do not apply to the Python world: Version information inside the artefact needs to be in sync with the external filename. Examples: 1. Plain rename of the tar ball bolke$ pip ins

Re: Airflow voting on release artifacts

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 >>>vote >>> MUST be the

Re: Airflow voting on release artifacts

It is Java, but we have version references internally in all kinds of places. So, what happens is that the build creates the "expected final release", say "1.2.3" and sets all internal references to that. But the tarball will be -RCx, which is voted upon. And then, as Bertrand suggested, a rename o

Re: Airflow voting on release artifacts

I'll point out that this is a great conversation and set of questions to have with your mentors first, the IPMC later if they didn't respond/give you a clear path forward. Did you engage with them? I personally hate seeing rc's being put forward to the incubator. Most of us use git these days, b

Re: Airflow voting on release artifacts

Hi Niclas, Is this Java or Python? I can only find Java for Polygene. Furthermore, how do you manage this you repository? Do you have the release already set in one of your files, e.g. something like this: https://github.com/apache/incubator-airflow/blob/v1-8-test/airflow/version.py

Re: Airflow voting on release artifacts

We have a similar issue in Polygene, but the internal version is simply the expected version, say 1.2.3 and the RC has the different file name. No packagers will ever get the -RC named artifact and no confusion is among community members as they are aware of this. IF the RC passes, then the rename

Re: Airflow voting on release artifacts

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 vote >> MUST be the one that we actually release... > > Yes in terms of havin

Re: Airflow voting on release artifacts

Hi, On Mon, Apr 24, 2017 at 10:18 PM, Chris Riccomini wrote: > ...Hitesh recently raised the issue that the artifact that passes the vote > 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 fo

Re: Airflow voting on release artifacts

Hi John, Typically one handles a “release candidate” equal to a release, except for the fact that it hasn’t been fully tested and reviewed yet. In case everyone (all entities) is satisfied with the RC it is then just rebranded to Release. Unfortunately, in the python ecosystem the version infor

Re: Airflow voting on release artifacts

Do you need to cut a vote with something named rc? Why can't you just use the version #? On Mon, Apr 24, 2017 at 4:18 PM Chris Riccomini wrote: > Hey all, > > We've had a question arise in the Airflow project. We're currently cutting > release candidates (RCs), and voting on those. These RCs co

Airflow voting on release artifacts

Hey all, We've had a question arise in the Airflow project. We're currently cutting release candidates (RCs), and voting on those. These RCs contain an artifact with the suffix -rc0, -rc1, etc. The problem with this is that the final RC that passes the vote still has an -rcX in its version number.