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 >
