Davor, I do not see the source tar ball for verifying the release. Can you please point me to that?
Thanks! On Tue, Jun 7, 2016 at 1:21 PM Seetharam Venkatesh <venkat...@innerzeal.com> wrote: > Aljoscha, if you want to be sure and want only one RC like me, I'd suggest > you search general incubator mail archive and look for comments from Justin > & Sebb - they are very thorough and will give you a headstart instead of > iterating multiple times. > > On Tue, Jun 7, 2016 at 12:59 PM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Hi Aljoscha >> >> It's basically here: >> http://incubator.apache.org/guides/releasemanagement.html >> >> The checklist is interesting to check the release content: >> >> http://incubator.apache.org/guides/releasemanagement.html#check-list >> >> Regards >> JB >> >> On 06/07/2016 09:56 PM, Aljoscha Krettek wrote: >> > By the way, is there any document where we keep track of what checks to >> run >> > for a release? Maybe I missed something, there. >> > >> > On Tue, 7 Jun 2016 at 21:29 Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> > >> >> Just submitted: https://github.com/apache/incubator-beam/pull/428 >> >> >> >> to fix the src distribution content. >> >> >> >> Regards >> >> JB >> >> >> >> On 06/07/2016 09:26 PM, Jean-Baptiste Onofré wrote: >> >>> I have to revert my vote to -1: >> >>> >> >>> the source distribution zip file is empty. >> >>> >> >>> I gonna submit a new PR to fix that. >> >>> >> >>> Sorry about that. >> >>> >> >>> Regards >> >>> JB >> >>> >> >>> On 06/07/2016 09:12 PM, Jean-Baptiste Onofré wrote: >> >>>> +1 >> >>>> >> >>>> it looks good to me: >> >>>> >> >>>> - all files have incubating >> >>>> - signatures check out (asc, md5, sha1) (and KEYS there) >> >>>> - disclaimer exists >> >>>> - LICENSE and NOTICE good >> >>>> - No unexpected binary in source >> >>>> - All ASF licensed files have ASF headers >> >>>> - Source distribution is available, with a correct name, and correct >> >>>> content: >> >>>> >> >>>> >> >> >> https://repository.apache.org/content/repositories/orgapachebeam-1001/org/apache/beam/apache-beam/0.1.0-incubating/apache-beam-0.1.0-incubating-src.zip >> >>>> >> >>>> >> >>>> I'm more comfortable to move forward on a formal release vote with >> this >> >>>> staging, and forward to the IPMC review. >> >>>> >> >>>> Thanks all and especially to Davor (to support me when I bother him >> >>>> bunch of times a day ;)). >> >>>> >> >>>> Regards >> >>>> JB >> >>>> >> >>>> On 06/07/2016 08:58 PM, Davor Bonaci wrote: >> >>>>> The second release candidate is available for everyone's review [1]. >> >>>>> >> >>>>> We plan to call for a vote shortly; please comment if there's any >> >>>>> additional feedback. >> >>>>> >> >>>>> [1] >> >>>>> >> https://repository.apache.org/content/repositories/orgapachebeam-1001 >> >>>>> >> >>>>> On Tue, Jun 7, 2016 at 9:33 AM, Kenneth Knowles >> <k...@google.com.invalid >> >>> >> >>>>> wrote: >> >>>>> >> >>>>>> +1 >> >>>>>> >> >>>>>> Lovely. Very readable. >> >>>>>> >> >>>>>> The "-parent" artifacts are just leaked implementation details of >> our >> >>>>>> build >> >>>>>> configuration that no one should ever actually reference, right? >> >>>>>> >> >>>>>> Kenn >> >>>>>> >> >>>>>> On Tue, Jun 7, 2016 at 8:54 AM, Dan Halperin >> >>>>>> <dhalp...@google.com.invalid> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> +2! This seems most concordant with other Apache products and the >> >> most >> >>>>>>> future-proof. >> >>>>>>> >> >>>>>>> On Mon, Jun 6, 2016 at 9:35 PM, Jean-Baptiste Onofré < >> >> j...@nanthrax.net> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> +1 >> >>>>>>>> >> >>>>>>>> Regards >> >>>>>>>> JB >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On 06/07/2016 02:49 AM, Davor Bonaci wrote: >> >>>>>>>> >> >>>>>>>>> After a few rounds of discussions and examining patterns of >> other >> >>>>>>>>> projects, >> >>>>>>>>> I think we are converging towards: >> >>>>>>>>> >> >>>>>>>>> * A flat group structure, where all artifacts belong to the >> >>>>>>>>> org.apache.beam >> >>>>>>>>> group. >> >>>>>>>>> * Prefix all artifact ids with "beam-". >> >>>>>>>>> * Name artifacts according to the existing directory/module >> layout: >> >>>>>>>>> beam-sdks-java-core, beam-runners-google-cloud-dataflow-java, >> etc. >> >>>>>>>>> * Suffix all parents with "-parent", e.g., "beam-parent", >> >>>>>>>>> "sdks-java-parent", etc. >> >>>>>>>>> * Create a "distributions" module, for the purpose of packaging >> the >> >>>>>>> source >> >>>>>>>>> code for the ASF release. >> >>>>>>>>> >> >>>>>>>>> I believe this approach takes into account everybody's feedback >> so >> >>>>>> far, >> >>>>>>>>> and >> >>>>>>>>> I think opposing positions have been retracted. >> >>>>>>>>> >> >>>>>>>>> Please comment if that's not the case, or if there are any >> >>>>>>>>> additional >> >>>>>>>>> points that we may have missed. If not, this is implemented in >> >>>>>>>>> pending >> >>>>>>>>> pull >> >>>>>>>>> requests #420 and #423. >> >>>>>>>>> >> >>>>>>>>> Thanks! >> >>>>>>>>> >> >>>>>>>>> On Fri, Jun 3, 2016 at 9:59 AM, Thomas Weise >> >>>>>>>>> <thomas.we...@gmail.com> >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> Another consideration for potential future >> packaging/distribution >> >>>>>>>>>> solutions >> >>>>>>>>>> is how the artifacts line up as files in a flat directory. For >> >> that >> >>>>>> it >> >>>>>>>>>> may >> >>>>>>>>>> be good to have a common prefix in the artifactId and unique >> >>>>>>> artifactId. >> >>>>>>>>>> >> >>>>>>>>>> The name for the source archive (when relying on ASF parent >> POM) >> >>>>>>>>>> can >> >>>>>>> also >> >>>>>>>>>> be controlled without expanding the artifactId: >> >>>>>>>>>> >> >>>>>>>>>> <build> >> >>>>>>>>>> <plugins> >> >>>>>>>>>> <plugin> >> >>>>>>>>>> <artifactId>maven-assembly-plugin</artifactId> >> >>>>>>>>>> <configuration> >> >>>>>>>>>> <finalName>apache-beam</finalName> >> >>>>>>>>>> </configuration> >> >>>>>>>>>> </plugin> >> >>>>>>>>>> </plugins> >> >>>>>>>>>> </build> >> >>>>>>>>>> >> >>>>>>>>>> Thanks, >> >>>>>>>>>> Thomas >> >>>>>>>>>> >> >>>>>>>>>> On Fri, Jun 3, 2016 at 9:39 AM, Davor Bonaci >> >>>>>> <da...@google.com.invalid >> >>>>>>>> >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> BEAM-315 is definitely important. Normally, I'd always advocate >> >> for >> >>>>>>>>>>> >> >>>>>>>>>> holding >> >>>>>>>>>> >> >>>>>>>>>>> the release to pick that fix. For the very first release, >> >> however, >> >>>>>> I'd >> >>>>>>>>>>> prefer to proceed to get something out there and test the >> >> process. >> >>>>>> As >> >>>>>>>>>>> you >> >>>>>>>>>>> said, we can address this rather quickly once we have the fix >> >>>>>>>>>>> merged >> >>>>>>> in. >> >>>>>>>>>>> >> >>>>>>>>>>> In terms of Maven coordinates, there are two basic approaches: >> >>>>>>>>>>> * flat structure, where artifacts live under "org.apache.beam" >> >>>>>>>>>>> group >> >>>>>>> and >> >>>>>>>>>>> are differentiated by their artifact id. >> >>>>>>>>>>> * hierarchical structure, where we use different groups for >> >>>>>> different >> >>>>>>>>>>> >> >>>>>>>>>> types >> >>>>>>>>>> >> >>>>>>>>>>> of artifacts (org.apache.beam.sdks; org.apache.beam.runners). >> >>>>>>>>>>> >> >>>>>>>>>>> There are pros and cons on the both sides of the argument. >> >>>>>>>>>>> Different >> >>>>>>>>>>> projects made different choices. Flat structure is easier to >> find >> >>>>>> and >> >>>>>>>>>>> navigate, but often breaks down with too many artifacts. >> >>>>>> Hierarchical >> >>>>>>>>>>> structure is just the opposite. >> >>>>>>>>>>> >> >>>>>>>>>>> On my end, the only important thing is consistency. We used to >> >>>>>>>>>>> have >> >>>>>>> it, >> >>>>>>>>>>> >> >>>>>>>>>> and >> >>>>>>>>>> >> >>>>>>>>>>> it got broken by PR #365. This part should be fixed -- we >> should >> >>>>>>> either >> >>>>>>>>>>> finish the vision of the hierarchical structure, or rollback >> >>>>>>>>>>> that PR >> >>>>>>> to >> >>>>>>>>>>> >> >>>>>>>>>> get >> >>>>>>>>>> >> >>>>>>>>>>> back to a fully flat structure. >> >>>>>>>>>>> >> >>>>>>>>>>> My general biases tend to be: >> >>>>>>>>>>> * hierarchical structure, since we have many artifacts >> already. >> >>>>>>>>>>> * short identifiers; no need to repeat a part of the group id >> in >> >>>>>>>>>>> the >> >>>>>>>>>>> artifact id. >> >>>>>>>>>>> >> >>>>>>>>>>> On Fri, Jun 3, 2016 at 4:03 AM, Jean-Baptiste Onofré < >> >>>>>> j...@nanthrax.net >> >>>>>>>> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Hi Max, >> >>>>>>>>>>>> >> >>>>>>>>>>>> I discussed with Davor yesterday. Basically, I proposed: >> >>>>>>>>>>>> >> >>>>>>>>>>>> 1. To rename all parent with a prefix (beam-parent, >> >>>>>>>>>>>> >> >>>>>>>>>>> flink-runner-parent, >> >>>>>>>>>> >> >>>>>>>>>>> spark-runner-parent, etc). >> >>>>>>>>>>>> 2. For the groupId, I prefer to use different groupId, it's >> >>>>>>>>>>>> clearer >> >>>>>>> to >> >>>>>>>>>>>> >> >>>>>>>>>>> me, >> >>>>>>>>>>> >> >>>>>>>>>>>> and it's exactly the usage of the groupId. Some projects use >> a >> >>>>>> single >> >>>>>>>>>>>> groupId (spark, hadoop, etc), others use multiple (camel, >> karaf, >> >>>>>>>>>>>> >> >>>>>>>>>>> activemq, >> >>>>>>>>>>> >> >>>>>>>>>>>> etc). I prefer different groupIds but ok to go back to single >> >>>>>>>>>>>> one. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Anyway, I'm preparing a PR to introduce a new Maven module: >> >>>>>>>>>>>> "distribution". The purpose is to address both BEAM-319 >> (first) >> >>>>>>>>>>>> and >> >>>>>>>>>>>> BEAM-320 (later). It's where we will be able to define the >> >>>>>> different >> >>>>>>>>>>>> distributions we plan to publish (source and binaries). >> >>>>>>>>>>>> >> >>>>>>>>>>>> Regards >> >>>>>>>>>>>> JB >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 06/03/2016 11:02 AM, Maximilian Michels wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks for getting us ready for the first release, Davor! We >> >>>>>>>>>>>> would >> >>>>>>>>>>>>> like to fix BEAM-315 next week. Is there already a timeline >> for >> >>>>>> the >> >>>>>>>>>>>>> first release? If so, we could also address this in a minor >> >>>>>> release. >> >>>>>>>>>>>>> Releasing often will give us some experience with our >> release >> >>>>>>> process >> >>>>>>>>>>>>> :) >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I would like everyone to think about the artifact names and >> >>>>>>>>>>>>> group >> >>>>>>> ids >> >>>>>>>>>>>>> again. "parent" and "flink" are not very suitable names for >> the >> >>>>>> Beam >> >>>>>>>>>>>>> parent or the Flink Runner artifact (same goes for the Spark >> >>>>>>> Runner). >> >>>>>>>>>>>>> I'd prefer "beam-parent", "flink-runner", and >> "spark-runner" as >> >>>>>>>>>>>>> artifact ids. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> One might think of Maven GroupIds as a sort of hierarchy but >> >>>>>> they're >> >>>>>>>>>>>>> not. They're just an identifier. Renaming the parent pom to >> >>>>>>>>>>>>> "apache-beam" or "beam-parent" would give us the old naming >> >>>>>>>>>>>>> scheme >> >>>>>>>>>>>>> which used flat group ids (before [1]). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> In the end, I guess it doesn't matter too much if we >> document >> >>>>>>>>>>>>> the >> >>>>>>>>>>>>> naming schemes accordingly. What matters is that we use a >> >>>>>> consistent >> >>>>>>>>>>>>> naming scheme. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Cheers, >> >>>>>>>>>>>>> Max >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/BEAM-287 >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Thu, Jun 2, 2016 at 4:00 PM, Jean-Baptiste Onofré < >> >>>>>>> j...@nanthrax.net >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Actually, I think we can fix both issue in one commit. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> What do you think about renaming the main parent POM with: >> >>>>>>>>>>>>>> groupId: org.apache.beam >> >>>>>>>>>>>>>> artifactId: apache-beam >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> ? >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Thanks to that, the source distribution will be named >> >>>>>>>>>>>>>> apache-beam-xxx-sources.zip and it would be clearer to dev. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Thoughts ? >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Regards >> >>>>>>>>>>>>>> JB >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> On 06/02/2016 03:10 PM, Jean-Baptiste Onofré wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Another annoying thing is the main parent POM artifactId. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Now, it's just "parent". What do you think about renaming >> to >> >>>>>>>>>>>>>>> "beam-parent" ? >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Regarding the source distribution name, I would cancel >> this >> >>>>>>> staging >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> to >> >>>>>>>>>> >> >>>>>>>>>>> fix that (I will have a PR ready soon). >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Thoughts ? >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Regards >> >>>>>>>>>>>>>>> JB >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On 06/02/2016 03:46 AM, Davor Bonaci wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Hi everyone! >> >>>>>>>>>>>>>>>> We've started the release process for our first release, >> >>>>>>>>>>>>>>>> 0.1.0-incubating. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> To recap previous discussions, we don't have particular >> >>>>>>> functional >> >>>>>>>>>>>>>>>> goals >> >>>>>>>>>>>>>>>> for this release. Instead, we'd like to make available >> >> what's >> >>>>>>>>>>>>>>>> currently in >> >>>>>>>>>>>>>>>> the repository, as well as work through the release >> process. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> With this in mind, we've: >> >>>>>>>>>>>>>>>> * branched off the release branch [1] at master's commit >> >>>>>> 8485272, >> >>>>>>>>>>>>>>>> * updated master to prepare for the second release, >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> 0.2.0-incubating, >> >>>>>>>>>> >> >>>>>>>>>>> * built the first release candidate, RC1, and deployed it to a >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> staging >> >>>>>>>>>>> >> >>>>>>>>>>>> repository [2]. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> We are not ready to start a vote just yet -- we've >> already >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> identified >> >>>>>>>>>> >> >>>>>>>>>>> a few >> >>>>>>>>>>>>>>>> issues worth fixing. That said, I'd like to invite >> >>>>>>>>>>>>>>>> everybody to >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> take >> >>>>>>>>>> >> >>>>>>>>>>> a >> >>>>>>>>>>> >> >>>>>>>>>>>> peek >> >>>>>>>>>>>>>>>> and comment. I'm hoping we can address as many issues as >> >>>>>> possible >> >>>>>>>>>>>>>>>> before we >> >>>>>>>>>>>>>>>> start the voting process. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Please let us know if you see any issues. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>>>>> Davor >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> [1] >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >> https://github.com/apache/incubator-beam/tree/release-0.1.0-incubating >> >>>>>>>>>>> >> >>>>>>>>>>>> [2] >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>> >> >> https://repository.apache.org/content/repositories/orgapachebeam-1000/ >> >>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> -- >> >>>>>>>>>>>>>> Jean-Baptiste Onofré >> >>>>>>>>>>>>>> jbono...@apache.org >> >>>>>>>>>>>>>> http://blog.nanthrax.net >> >>>>>>>>>>>>>> Talend - http://www.talend.com >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> -- >> >>>>>>>>>>>> Jean-Baptiste Onofré >> >>>>>>>>>>>> jbono...@apache.org >> >>>>>>>>>>>> http://blog.nanthrax.net >> >>>>>>>>>>>> Talend - http://www.talend.com >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Jean-Baptiste Onofré >> >>>>>>>> jbono...@apache.org >> >>>>>>>> http://blog.nanthrax.net >> >>>>>>>> Talend - http://www.talend.com >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> -- >> >> Jean-Baptiste Onofré >> >> jbono...@apache.org >> >> http://blog.nanthrax.net >> >> Talend - http://www.talend.com >> >> >> > >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >
