+1 (binding) - verified release signature and hashes - mvn install -Prelease runs smoothly - created a Quickstart against the staging repo - ran Quickstart with Flink local mode - ran Quickstart against a Flink 1.2 cluster
On Tue, Mar 14, 2017, at 01:44, Eugene Kirpichov wrote: > Conclusion (see JIRA): Not a release blocker (but still a bug in > TestPipeline). > > On Mon, Mar 13, 2017 at 5:40 PM Eugene Kirpichov <kirpic...@google.com> > wrote: > > > +Aljoscha Krettek <aljos...@data-artisans.com> > > > > On Mon, Mar 13, 2017 at 5:30 PM Eugene Kirpichov <kirpic...@google.com> > > wrote: > > > > +Stas Levin <stasle...@apache.org> +Thomas Groh <tg...@google.com> > > > > On Mon, Mar 13, 2017 at 5:30 PM Eugene Kirpichov <kirpic...@google.com> > > wrote: > > > > https://issues.apache.org/jira/browse/BEAM-1712 might be a release > > blocker. > > > > On Mon, Mar 13, 2017 at 4:53 PM Ahmet Altay <al...@google.com.invalid> > > wrote: > > > > Thank you for all the comment so far. > > > > On Mon, Mar 13, 2017 at 4:23 PM, Ted Yu <yuzhih...@gmail.com> wrote: > > > > > bq. I would prefer that we have a .tar.gz release > > > > > > +1 > > > > > > On Mon, Mar 13, 2017 at 4:21 PM, Ismaël Mejía <ieme...@gmail.com> wrote: > > > > > > > +1 (non-binding) > > > > > > > > - verified signatures + checksums > > > > - run mvn clean install -Prelease, all artifacts build and the tests > > run > > > > smoothly (modulo some local issues I had with the installation of tox > > for > > > > the python sdk, I created a PR to fix those in case other people can > > have > > > > the same trouble). > > > > > > > > Some remarks still to fix from the release, but that I don’t consider > > > > blockers: > > > > > > > > 1. The section Getting Started in the main README.md needs to be > > updated > > > > with the information about the creating/activating the virtualenv. At > > > this > > > > moment just running mvn clean install won’t work without this. > > > > > > > mvn clean install should run without any additional steps, including the > > creation of a virtualenv. tox will manage this process, and it is already > > integrated Maven. > > > > > > > > > > > > 2. Both zip files in the current release produce a folder with the > > same > > > > name ‘apache-beam-0.6.0’. This can be messy if users unzip both files > > > into > > > > the same folder (as happened to me, the compressed files should > > produce a > > > > directory with the exact same name that the file, so > > > > apache-beam-0.6.0-python.zip will produce apache-beam-0.6.0-python and > > > the > > > > other its respective directory. > > > > > > > > > > 3. The name of the files of the release probably should be different: > > > > > > > > The source release could be just apache-beam-0.6.0.zip instead of > > > > apache-beam-0.6.0-source-release.zip considering that we don’t have > > > binary > > > > artifacts, or just apache-beam-0.6.0-src.zip following the convention > > of > > > > other apache projects. > > > > > > > > The python release also could be renamed from > > > > apache-beam-0.6.0-bin-python.zip instead of > > apache-beam-0.6.0-python.zip > > > > so > > > > users understand that these are executable files (but well I am not > > sure > > > > about that one considering that python is a scripting language). > > > > > > > Python distribution is a source distribution, adding bin to the name would > > be confusing. > > > > > > > > > > > > Finally I would prefer that we have a .tar.gz release as JB mentioned > > in > > > > the previous vote, and as most apache projects do. In any case if the > > zip > > > > is somehow a requirement it would be nice to have both a .zip and a > > > .tar.gz > > > > file. > > > > > > > > > > > I think we should move this to a different thread. IMO, having a single > > source of truth is better than having both file formats. Between both file > > formats I don't have a strong opinion but considering the Windows users zip > > might be a portable option. > > > > Thank you, > > Ahmet > > > >
