https://repository.apache.org/content/repositories/orgapachebeam-1001/org/apache/beam/beam-parent/0.1.0-incubating/beam-parent-0.1.0-incubating-source-release.zip
is what I think is a complete copy of the source release. note that the empty version JB is talking about is here: 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 On Tue, Jun 7, 2016 at 1:21 PM, Seetharam Venkatesh <[email protected] > wrote: > 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 < > [email protected]> > 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é <[email protected]> > > 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é <[email protected]> > >> 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 > >> <[email protected] > >> >>> > >> >>>>> 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 > >> >>>>>> <[email protected]> > >> >>>>>> 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é < > >> >> [email protected]> > >> >>>>>>> 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 > >> >>>>>>>>> <[email protected]> > >> >>>>>>>>> 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 > >> >>>>>> <[email protected] > >> >>>>>>>> > >> >>>>>>>>>> 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é < > >> >>>>>> [email protected] > >> >>>>>>>> > >> >>>>>>>>>>> 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é < > >> >>>>>>> [email protected] > >> >>>>>>>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>>>>> 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é > >> >>>>>>>>>>>>>> [email protected] > >> >>>>>>>>>>>>>> http://blog.nanthrax.net > >> >>>>>>>>>>>>>> Talend - http://www.talend.com > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>>> > >> >>>>>>>>>>>>> -- > >> >>>>>>>>>>>> Jean-Baptiste Onofré > >> >>>>>>>>>>>> [email protected] > >> >>>>>>>>>>>> http://blog.nanthrax.net > >> >>>>>>>>>>>> Talend - http://www.talend.com > >> >>>>>>>>>>>> > >> >>>>>>>>>>>> > >> >>>>>>>>>>> > >> >>>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>> -- > >> >>>>>>>> Jean-Baptiste Onofré > >> >>>>>>>> [email protected] > >> >>>>>>>> http://blog.nanthrax.net > >> >>>>>>>> Talend - http://www.talend.com > >> >>>>>>>> > >> >>>>>>> > >> >>>>>> > >> >>>>> > >> >>>> > >> >>> > >> >> > >> >> -- > >> >> Jean-Baptiste Onofré > >> >> [email protected] > >> >> http://blog.nanthrax.net > >> >> Talend - http://www.talend.com > >> >> > >> > > >> > >> -- > >> Jean-Baptiste Onofré > >> [email protected] > >> http://blog.nanthrax.net > >> Talend - http://www.talend.com > >> > > >
