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 >
