You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Davor Bonaci <da...@google.com.INVALID> on 2016/06/02 01:46:06 UTC
0.1.0-incubating release
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/
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
As discussed, the release process looks good to me (a bit long compare
to that we use to do ;)).
Regarding the source stage:
- all files have incubating
- signatures check out (and KEYS there)
- disclaimer exists
- LICENSE and NOTICE good
- No unexpected binary in source
- All ASF licensed files have ASF headers
Should be improved:
- the source distribution is named
parent-0.1.0-incubating-source-release.zip where it should be
apache-beam-0.1.0-incubating-source.zip (gonna provide a PR to fix that)
- the source distribution is only available as zip archive, you could
provide tar.gz archive too
So, with a quick fix on the distribution name, we will be ready to go.
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�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
the "valid" one to use is apache-beam-0.1.0-incubating-src.zip.
The PR to fix content has been submitted and merged, Davor will cut a
new staging soon.
Regards
JB
On 06/08/2016 12:36 AM, Dan Halperin wrote:
> 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 <venkatesh@innerzeal.com
>> 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 <
>> venkatesh@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� <jb...@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� <jb...@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
>>>> <klk@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
>>>>>>>>>> <dh...@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� <
>>>>>> jb@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
>>>>>>>>>>>>> <th...@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
>>>>>>>>>> <davor@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� <
>>>>>>>>>> jb@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� <
>>>>>>>>>>> jb@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�
>>>>>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofr�
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Dan Halperin <dh...@google.com.INVALID>.
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 <venkatesh@innerzeal.com
> 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 <
> venkatesh@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é <jb...@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é <jb...@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
> >> <klk@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
> >> >>>>>> <dh...@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é <
> >> >> jb@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
> >> >>>>>>>>> <th...@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
> >> >>>>>> <davor@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é <
> >> >>>>>> jb@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é <
> >> >>>>>>> jb@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é
> >> >>>>>>>>>>>>>> jbonofre@apache.org
> >> >>>>>>>>>>>>>> http://blog.nanthrax.net
> >> >>>>>>>>>>>>>> Talend - http://www.talend.com
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>> --
> >> >>>>>>>>>>>> Jean-Baptiste Onofré
> >> >>>>>>>>>>>> jbonofre@apache.org
> >> >>>>>>>>>>>> http://blog.nanthrax.net
> >> >>>>>>>>>>>> Talend - http://www.talend.com
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>> --
> >> >>>>>>>> Jean-Baptiste Onofré
> >> >>>>>>>> jbonofre@apache.org
> >> >>>>>>>> http://blog.nanthrax.net
> >> >>>>>>>> Talend - http://www.talend.com
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >> >> --
> >> >> Jean-Baptiste Onofré
> >> >> jbonofre@apache.org
> >> >> http://blog.nanthrax.net
> >> >> Talend - http://www.talend.com
> >> >>
> >> >
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
Re: 0.1.0-incubating release
Posted by Seetharam Venkatesh <ve...@innerzeal.com>.
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 <ve...@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é <jb...@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é <jb...@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
>> <klk@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
>> >>>>>> <dh...@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é <
>> >> jb@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
>> >>>>>>>>> <th...@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
>> >>>>>> <davor@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é <
>> >>>>>> jb@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é <
>> >>>>>>> jb@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é
>> >>>>>>>>>>>>>> jbonofre@apache.org
>> >>>>>>>>>>>>>> http://blog.nanthrax.net
>> >>>>>>>>>>>>>> Talend - http://www.talend.com
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>> --
>> >>>>>>>>>>>> Jean-Baptiste Onofré
>> >>>>>>>>>>>> jbonofre@apache.org
>> >>>>>>>>>>>> http://blog.nanthrax.net
>> >>>>>>>>>>>> Talend - http://www.talend.com
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> Jean-Baptiste Onofré
>> >>>>>>>> jbonofre@apache.org
>> >>>>>>>> http://blog.nanthrax.net
>> >>>>>>>> Talend - http://www.talend.com
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >> --
>> >> Jean-Baptiste Onofré
>> >> jbonofre@apache.org
>> >> http://blog.nanthrax.net
>> >> Talend - http://www.talend.com
>> >>
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
Re: 0.1.0-incubating release
Posted by Seetharam Venkatesh <ve...@innerzeal.com>.
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é <jb...@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é <jb...@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
> <klk@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
> >>>>>> <dh...@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é <
> >> jb@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
> >>>>>>>>> <th...@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
> >>>>>> <davor@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é <
> >>>>>> jb@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é <
> >>>>>>> jb@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é
> >>>>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean-Baptiste Onofré
> >>>>>>>> jbonofre@apache.org
> >>>>>>>> http://blog.nanthrax.net
> >>>>>>>> Talend - http://www.talend.com
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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� <jb...@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 <klk@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
>>>>>> <dh...@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� <
>> jb@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
>>>>>>>>> <th...@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
>>>>>> <davor@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� <
>>>>>> jb@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� <
>>>>>>> jb@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�
>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Aljoscha Krettek <al...@apache.org>.
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é <jb...@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 <klk@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
> >>>> <dh...@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é <
> jb@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
> >>>>>>> <th...@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
> >>>> <davor@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é <
> >>>> jb@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é <
> >>>>> jb@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é
> >>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>> Jean-Baptiste Onofré
> >>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> Jean-Baptiste Onofré
> >>>>>> jbonofre@apache.org
> >>>>>> http://blog.nanthrax.net
> >>>>>> Talend - http://www.talend.com
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <kl...@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
>>>> <dh...@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� <jb...@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
>>>>>>> <th...@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
>>>> <davor@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� <
>>>> jb@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� <
>>>>> jb@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�
>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofr�
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <kl...@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
>>> <dh...@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� <jb...@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 <th...@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
>>> <davor@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� <
>>> jb@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� <
>>>> jb@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�
>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofr�
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+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 <kl...@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 <dh...@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� <jb...@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 <th...@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
>> <davor@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� <
>> jb@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� <
>>> jb@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�
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Davor Bonaci <da...@google.com.INVALID>.
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 <kl...@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 <dh...@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é <jb...@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 <th...@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
> <davor@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é <
> jb@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é <
> > jb@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é
> > >>>>>>> jbonofre@apache.org
> > >>>>>>> http://blog.nanthrax.net
> > >>>>>>> Talend - http://www.talend.com
> > >>>>>>>
> > >>>>>>>
> > >>>>>> --
> > >>>>> Jean-Baptiste Onofré
> > >>>>> jbonofre@apache.org
> > >>>>> http://blog.nanthrax.net
> > >>>>> Talend - http://www.talend.com
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > > --
> > > Jean-Baptiste Onofré
> > > jbonofre@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
>
Re: 0.1.0-incubating release
Posted by Kenneth Knowles <kl...@google.com.INVALID>.
+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 <dh...@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é <jb...@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 <th...@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 <davor@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é <jb@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é <
> jb@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é
> >>>>>>> jbonofre@apache.org
> >>>>>>> http://blog.nanthrax.net
> >>>>>>> Talend - http://www.talend.com
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>> Jean-Baptiste Onofré
> >>>>> jbonofre@apache.org
> >>>>> http://blog.nanthrax.net
> >>>>> Talend - http://www.talend.com
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: 0.1.0-incubating release
Posted by Lukasz Cwik <lc...@google.com.INVALID>.
+1
On Tue, Jun 7, 2016 at 8:54 AM, Dan Halperin <dh...@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é <jb...@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 <th...@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 <davor@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é <jb@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é <
> jb@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é
> >>>>>>> jbonofre@apache.org
> >>>>>>> http://blog.nanthrax.net
> >>>>>>> Talend - http://www.talend.com
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>> Jean-Baptiste Onofré
> >>>>> jbonofre@apache.org
> >>>>> http://blog.nanthrax.net
> >>>>> Talend - http://www.talend.com
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: 0.1.0-incubating release
Posted by Dan Halperin <dh...@google.com.INVALID>.
+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é <jb...@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 <th...@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é <jb...@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é <jb@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é
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+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 <th...@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� <jb...@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� <jb@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�
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Davor Bonaci <da...@google.com.INVALID>.
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 <th...@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é <jb...@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é <jb@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é
> > >>> jbonofre@apache.org
> > >>> http://blog.nanthrax.net
> > >>> Talend - http://www.talend.com
> > >>>
> > >>
> > > --
> > > Jean-Baptiste Onofré
> > > jbonofre@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
>
Re: 0.1.0-incubating release
Posted by Thomas Weise <th...@gmail.com>.
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é <jb...@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é <jb...@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é
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: 0.1.0-incubating release
Posted by Davor Bonaci <da...@google.com.INVALID>.
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é <jb...@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é <jb...@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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [VOTE] groupId/artifactId naming & layout
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
But yes, you are right, I should have used "[DISCUSS]" in the subject
instead of "[VOTE]".
Sorry about that.
Regards
JB
On 06/03/2016 07:44 PM, Amit Sela wrote:
> I think that the [VOTE] tagging was a bit confusing, at least for me. I
> thought it was a formal vote..
>
> On Fri, Jun 3, 2016, 20:29 Jean-Baptiste Onofr� <jb...@nanthrax.net> wrote:
>
>> Absolutely.
>>
>> The vote/discussion can "extended" to other options (even if I don't see
>> obvious right now). No worries at all.
>>
>> Regards
>> JB
>>
>> On 06/03/2016 07:25 PM, Frances Perry wrote:
>>> Totally agree on discussing this ;-) I think Davor was just suggesting we
>>> lay out all options and understand them before calling for a vote between
>>> them.
>>>
>>> On Fri, Jun 3, 2016 at 10:19 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> The purpose of the vote is to get a consensus actually.
>>>>
>>>> We have two options expressed on the mailing list: the current "layout"
>> is
>>>> good IMHO but all don't agree. So, let's put things on the table and
>> move
>>>> forward. The vote is a way of discussing. It's not a vote for the
>> release,
>>>> it's a vote/discussion for the layout and Maven coordinates (so not a
>>>> formal vote).
>>>>
>>>> Just to remember: all should be discussed and informed on the mailing
>> list.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 06/03/2016 06:50 PM, Davor Bonaci wrote:
>>>>
>>>>> This is not a great vote proposal for several reasons:
>>>>> * "Use the current layout" is ambiguous, because it is inconsistent
>> (it is
>>>>> now partly flat and party hierarchical).
>>>>> * Getting the outcome won't move us much closer to the resolution,
>> given
>>>>> that there are several sub-variants in each option.
>>>>> * We have not laid out advantages, disadvantages, and consequences of
>> each
>>>>> option for everyone to make an informed decision.
>>>>> * It is premature: we haven't tried to reach a consensus or explored
>>>>> alternatives. 3 hours and just a few emails is way too short from a
>> issue
>>>>> being raised to vote call.
>>>>>
>>>>> I'd suggest to try to find a consensus on the original thread first,
>> and
>>>>> call for a vote if/when needed.
>>>>>
>>>>> On Fri, Jun 3, 2016 at 5:15 AM, Amit Sela <am...@gmail.com>
>> wrote:
>>>>>
>>>>> +1 for Option2
>>>>>>
>>>>>> On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>>>>> wrote:
>>>>>>
>>>>>> As said in my previous e-mail, just proposed PR #416.
>>>>>>>
>>>>>>> Let's start a vote for groupId and artifactId naming.
>>>>>>>
>>>>>>> [ ] Option1: use the current layout (multiple groupId, artifactId
>>>>>>> relative to groupId)
>>>>>>> [ ] Option2: use unique org.apache.beam groupId and rename artifactId
>>>>>>> with a prefix (beam-parent/apache-beam, flink-runner, spark-runner,
>> etc)
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 06/03/2016 01:03 PM, Jean-Baptiste Onofr� 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� <
>> jb@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�
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofr�
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [VOTE] groupId/artifactId naming & layout
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It's a formal vote to choose between the two options proposed.
If you see another option, you can add it in the vote thread.
Regards
JB
On 06/03/2016 07:44 PM, Amit Sela wrote:
> I think that the [VOTE] tagging was a bit confusing, at least for me. I
> thought it was a formal vote..
>
> On Fri, Jun 3, 2016, 20:29 Jean-Baptiste Onofr� <jb...@nanthrax.net> wrote:
>
>> Absolutely.
>>
>> The vote/discussion can "extended" to other options (even if I don't see
>> obvious right now). No worries at all.
>>
>> Regards
>> JB
>>
>> On 06/03/2016 07:25 PM, Frances Perry wrote:
>>> Totally agree on discussing this ;-) I think Davor was just suggesting we
>>> lay out all options and understand them before calling for a vote between
>>> them.
>>>
>>> On Fri, Jun 3, 2016 at 10:19 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> The purpose of the vote is to get a consensus actually.
>>>>
>>>> We have two options expressed on the mailing list: the current "layout"
>> is
>>>> good IMHO but all don't agree. So, let's put things on the table and
>> move
>>>> forward. The vote is a way of discussing. It's not a vote for the
>> release,
>>>> it's a vote/discussion for the layout and Maven coordinates (so not a
>>>> formal vote).
>>>>
>>>> Just to remember: all should be discussed and informed on the mailing
>> list.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 06/03/2016 06:50 PM, Davor Bonaci wrote:
>>>>
>>>>> This is not a great vote proposal for several reasons:
>>>>> * "Use the current layout" is ambiguous, because it is inconsistent
>> (it is
>>>>> now partly flat and party hierarchical).
>>>>> * Getting the outcome won't move us much closer to the resolution,
>> given
>>>>> that there are several sub-variants in each option.
>>>>> * We have not laid out advantages, disadvantages, and consequences of
>> each
>>>>> option for everyone to make an informed decision.
>>>>> * It is premature: we haven't tried to reach a consensus or explored
>>>>> alternatives. 3 hours and just a few emails is way too short from a
>> issue
>>>>> being raised to vote call.
>>>>>
>>>>> I'd suggest to try to find a consensus on the original thread first,
>> and
>>>>> call for a vote if/when needed.
>>>>>
>>>>> On Fri, Jun 3, 2016 at 5:15 AM, Amit Sela <am...@gmail.com>
>> wrote:
>>>>>
>>>>> +1 for Option2
>>>>>>
>>>>>> On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>>>>> wrote:
>>>>>>
>>>>>> As said in my previous e-mail, just proposed PR #416.
>>>>>>>
>>>>>>> Let's start a vote for groupId and artifactId naming.
>>>>>>>
>>>>>>> [ ] Option1: use the current layout (multiple groupId, artifactId
>>>>>>> relative to groupId)
>>>>>>> [ ] Option2: use unique org.apache.beam groupId and rename artifactId
>>>>>>> with a prefix (beam-parent/apache-beam, flink-runner, spark-runner,
>> etc)
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 06/03/2016 01:03 PM, Jean-Baptiste Onofr� 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� <
>> jb@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�
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofr�
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [VOTE] groupId/artifactId naming & layout
Posted by Amit Sela <am...@gmail.com>.
I think that the [VOTE] tagging was a bit confusing, at least for me. I
thought it was a formal vote..
On Fri, Jun 3, 2016, 20:29 Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Absolutely.
>
> The vote/discussion can "extended" to other options (even if I don't see
> obvious right now). No worries at all.
>
> Regards
> JB
>
> On 06/03/2016 07:25 PM, Frances Perry wrote:
> > Totally agree on discussing this ;-) I think Davor was just suggesting we
> > lay out all options and understand them before calling for a vote between
> > them.
> >
> > On Fri, Jun 3, 2016 at 10:19 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> >> The purpose of the vote is to get a consensus actually.
> >>
> >> We have two options expressed on the mailing list: the current "layout"
> is
> >> good IMHO but all don't agree. So, let's put things on the table and
> move
> >> forward. The vote is a way of discussing. It's not a vote for the
> release,
> >> it's a vote/discussion for the layout and Maven coordinates (so not a
> >> formal vote).
> >>
> >> Just to remember: all should be discussed and informed on the mailing
> list.
> >>
> >> Regards
> >> JB
> >>
> >>
> >> On 06/03/2016 06:50 PM, Davor Bonaci wrote:
> >>
> >>> This is not a great vote proposal for several reasons:
> >>> * "Use the current layout" is ambiguous, because it is inconsistent
> (it is
> >>> now partly flat and party hierarchical).
> >>> * Getting the outcome won't move us much closer to the resolution,
> given
> >>> that there are several sub-variants in each option.
> >>> * We have not laid out advantages, disadvantages, and consequences of
> each
> >>> option for everyone to make an informed decision.
> >>> * It is premature: we haven't tried to reach a consensus or explored
> >>> alternatives. 3 hours and just a few emails is way too short from a
> issue
> >>> being raised to vote call.
> >>>
> >>> I'd suggest to try to find a consensus on the original thread first,
> and
> >>> call for a vote if/when needed.
> >>>
> >>> On Fri, Jun 3, 2016 at 5:15 AM, Amit Sela <am...@gmail.com>
> wrote:
> >>>
> >>> +1 for Option2
> >>>>
> >>>> On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>>> wrote:
> >>>>
> >>>> As said in my previous e-mail, just proposed PR #416.
> >>>>>
> >>>>> Let's start a vote for groupId and artifactId naming.
> >>>>>
> >>>>> [ ] Option1: use the current layout (multiple groupId, artifactId
> >>>>> relative to groupId)
> >>>>> [ ] Option2: use unique org.apache.beam groupId and rename artifactId
> >>>>> with a prefix (beam-parent/apache-beam, flink-runner, spark-runner,
> etc)
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> On 06/03/2016 01:03 PM, Jean-Baptiste Onofré 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é <
> jb@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é
> >>>>>>>> jbonofre@apache.org
> >>>>>>>> http://blog.nanthrax.net
> >>>>>>>> Talend - http://www.talend.com
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>> --
> >>>>> Jean-Baptiste Onofré
> >>>>> jbonofre@apache.org
> >>>>> http://blog.nanthrax.net
> >>>>> Talend - http://www.talend.com
> >>>>>
> >>>>>
> >>>>
> >>>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [VOTE] groupId/artifactId naming & layout
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Absolutely.
The vote/discussion can "extended" to other options (even if I don't see
obvious right now). No worries at all.
Regards
JB
On 06/03/2016 07:25 PM, Frances Perry wrote:
> Totally agree on discussing this ;-) I think Davor was just suggesting we
> lay out all options and understand them before calling for a vote between
> them.
>
> On Fri, Jun 3, 2016 at 10:19 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
> wrote:
>
>> The purpose of the vote is to get a consensus actually.
>>
>> We have two options expressed on the mailing list: the current "layout" is
>> good IMHO but all don't agree. So, let's put things on the table and move
>> forward. The vote is a way of discussing. It's not a vote for the release,
>> it's a vote/discussion for the layout and Maven coordinates (so not a
>> formal vote).
>>
>> Just to remember: all should be discussed and informed on the mailing list.
>>
>> Regards
>> JB
>>
>>
>> On 06/03/2016 06:50 PM, Davor Bonaci wrote:
>>
>>> This is not a great vote proposal for several reasons:
>>> * "Use the current layout" is ambiguous, because it is inconsistent (it is
>>> now partly flat and party hierarchical).
>>> * Getting the outcome won't move us much closer to the resolution, given
>>> that there are several sub-variants in each option.
>>> * We have not laid out advantages, disadvantages, and consequences of each
>>> option for everyone to make an informed decision.
>>> * It is premature: we haven't tried to reach a consensus or explored
>>> alternatives. 3 hours and just a few emails is way too short from a issue
>>> being raised to vote call.
>>>
>>> I'd suggest to try to find a consensus on the original thread first, and
>>> call for a vote if/when needed.
>>>
>>> On Fri, Jun 3, 2016 at 5:15 AM, Amit Sela <am...@gmail.com> wrote:
>>>
>>> +1 for Option2
>>>>
>>>> On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>> As said in my previous e-mail, just proposed PR #416.
>>>>>
>>>>> Let's start a vote for groupId and artifactId naming.
>>>>>
>>>>> [ ] Option1: use the current layout (multiple groupId, artifactId
>>>>> relative to groupId)
>>>>> [ ] Option2: use unique org.apache.beam groupId and rename artifactId
>>>>> with a prefix (beam-parent/apache-beam, flink-runner, spark-runner, etc)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 06/03/2016 01:03 PM, Jean-Baptiste Onofr� 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� <jb@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�
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofr�
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [VOTE] groupId/artifactId naming & layout
Posted by Frances Perry <fj...@google.com.INVALID>.
Totally agree on discussing this ;-) I think Davor was just suggesting we
lay out all options and understand them before calling for a vote between
them.
On Fri, Jun 3, 2016 at 10:19 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> The purpose of the vote is to get a consensus actually.
>
> We have two options expressed on the mailing list: the current "layout" is
> good IMHO but all don't agree. So, let's put things on the table and move
> forward. The vote is a way of discussing. It's not a vote for the release,
> it's a vote/discussion for the layout and Maven coordinates (so not a
> formal vote).
>
> Just to remember: all should be discussed and informed on the mailing list.
>
> Regards
> JB
>
>
> On 06/03/2016 06:50 PM, Davor Bonaci wrote:
>
>> This is not a great vote proposal for several reasons:
>> * "Use the current layout" is ambiguous, because it is inconsistent (it is
>> now partly flat and party hierarchical).
>> * Getting the outcome won't move us much closer to the resolution, given
>> that there are several sub-variants in each option.
>> * We have not laid out advantages, disadvantages, and consequences of each
>> option for everyone to make an informed decision.
>> * It is premature: we haven't tried to reach a consensus or explored
>> alternatives. 3 hours and just a few emails is way too short from a issue
>> being raised to vote call.
>>
>> I'd suggest to try to find a consensus on the original thread first, and
>> call for a vote if/when needed.
>>
>> On Fri, Jun 3, 2016 at 5:15 AM, Amit Sela <am...@gmail.com> wrote:
>>
>> +1 for Option2
>>>
>>> On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> wrote:
>>>
>>> As said in my previous e-mail, just proposed PR #416.
>>>>
>>>> Let's start a vote for groupId and artifactId naming.
>>>>
>>>> [ ] Option1: use the current layout (multiple groupId, artifactId
>>>> relative to groupId)
>>>> [ ] Option2: use unique org.apache.beam groupId and rename artifactId
>>>> with a prefix (beam-parent/apache-beam, flink-runner, spark-runner, etc)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 06/03/2016 01:03 PM, Jean-Baptiste Onofré 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é <jb@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é
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [VOTE] groupId/artifactId naming & layout
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
The purpose of the vote is to get a consensus actually.
We have two options expressed on the mailing list: the current "layout"
is good IMHO but all don't agree. So, let's put things on the table and
move forward. The vote is a way of discussing. It's not a vote for the
release, it's a vote/discussion for the layout and Maven coordinates (so
not a formal vote).
Just to remember: all should be discussed and informed on the mailing list.
Regards
JB
On 06/03/2016 06:50 PM, Davor Bonaci wrote:
> This is not a great vote proposal for several reasons:
> * "Use the current layout" is ambiguous, because it is inconsistent (it is
> now partly flat and party hierarchical).
> * Getting the outcome won't move us much closer to the resolution, given
> that there are several sub-variants in each option.
> * We have not laid out advantages, disadvantages, and consequences of each
> option for everyone to make an informed decision.
> * It is premature: we haven't tried to reach a consensus or explored
> alternatives. 3 hours and just a few emails is way too short from a issue
> being raised to vote call.
>
> I'd suggest to try to find a consensus on the original thread first, and
> call for a vote if/when needed.
>
> On Fri, Jun 3, 2016 at 5:15 AM, Amit Sela <am...@gmail.com> wrote:
>
>> +1 for Option2
>>
>> On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofr� <jb...@nanthrax.net>
>> wrote:
>>
>>> As said in my previous e-mail, just proposed PR #416.
>>>
>>> Let's start a vote for groupId and artifactId naming.
>>>
>>> [ ] Option1: use the current layout (multiple groupId, artifactId
>>> relative to groupId)
>>> [ ] Option2: use unique org.apache.beam groupId and rename artifactId
>>> with a prefix (beam-parent/apache-beam, flink-runner, spark-runner, etc)
>>>
>>> Regards
>>> JB
>>>
>>> On 06/03/2016 01:03 PM, Jean-Baptiste Onofr� 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� <jb@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�
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofr�
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [VOTE] groupId/artifactId naming & layout
Posted by Davor Bonaci <da...@google.com.INVALID>.
This is not a great vote proposal for several reasons:
* "Use the current layout" is ambiguous, because it is inconsistent (it is
now partly flat and party hierarchical).
* Getting the outcome won't move us much closer to the resolution, given
that there are several sub-variants in each option.
* We have not laid out advantages, disadvantages, and consequences of each
option for everyone to make an informed decision.
* It is premature: we haven't tried to reach a consensus or explored
alternatives. 3 hours and just a few emails is way too short from a issue
being raised to vote call.
I'd suggest to try to find a consensus on the original thread first, and
call for a vote if/when needed.
On Fri, Jun 3, 2016 at 5:15 AM, Amit Sela <am...@gmail.com> wrote:
> +1 for Option2
>
> On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > As said in my previous e-mail, just proposed PR #416.
> >
> > Let's start a vote for groupId and artifactId naming.
> >
> > [ ] Option1: use the current layout (multiple groupId, artifactId
> > relative to groupId)
> > [ ] Option2: use unique org.apache.beam groupId and rename artifactId
> > with a prefix (beam-parent/apache-beam, flink-runner, spark-runner, etc)
> >
> > Regards
> > JB
> >
> > On 06/03/2016 01:03 PM, Jean-Baptiste Onofré 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é <jb@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é
> > >>> jbonofre@apache.org
> > >>> http://blog.nanthrax.net
> > >>> Talend - http://www.talend.com
> > >
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
Re: [VOTE] groupId/artifactId naming & layout
Posted by Amit Sela <am...@gmail.com>.
+1 for Option2
On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> As said in my previous e-mail, just proposed PR #416.
>
> Let's start a vote for groupId and artifactId naming.
>
> [ ] Option1: use the current layout (multiple groupId, artifactId
> relative to groupId)
> [ ] Option2: use unique org.apache.beam groupId and rename artifactId
> with a prefix (beam-parent/apache-beam, flink-runner, spark-runner, etc)
>
> Regards
> JB
>
> On 06/03/2016 01:03 PM, Jean-Baptiste Onofré 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é <jb...@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é
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
[VOTE] groupId/artifactId naming & layout
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
As said in my previous e-mail, just proposed PR #416.
Let's start a vote for groupId and artifactId naming.
[ ] Option1: use the current layout (multiple groupId, artifactId
relative to groupId)
[ ] Option2: use unique org.apache.beam groupId and rename artifactId
with a prefix (beam-parent/apache-beam, flink-runner, spark-runner, etc)
Regards
JB
On 06/03/2016 01:03 PM, Jean-Baptiste Onofr� 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� <jb...@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�
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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� <jb...@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�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Amit Sela <am...@gmail.com>.
+1 on Max's comment on naming. I prefer spark-runner and beam-parent as
well.
On Fri, Jun 3, 2016, 12:03 Maximilian Michels <mx...@apache.org> 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é <jb...@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é
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
Re: 0.1.0-incubating release
Posted by Maximilian Michels <mx...@apache.org>.
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é <jb...@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Amit,
thanks for the update. Davor is updating a new RC to fix the source
distribution issue.
Stay tuned !
Regards
JB
On 06/08/2016 08:12 PM, Amit Sela wrote:
> To Davor, JB and anyone else helping with the release, Thanks! this looks
> great.
>
> On Wed, Jun 8, 2016 at 9:11 PM Amit Sela <am...@gmail.com> wrote:
>
>> Regarding Dan's questions:
>> 1. I'm not sure - it is built with spark-*_2.10 but I honestly don't know
>> if this matters for the runner itself, it could be nice to have in order to
>> be more informative. In addition, this will change with Spark 2.0 to Scala
>> 2.11 AFAIK.
>> 2. This is to allow running out-of-the-box examples I guess. The Flink
>> runner just tells you how to do it on your own here:
>> https://github.com/apache/incubator-beam/tree/master/runners/flink
>> Would you say this is a better approach ?
>>
>> In any case, packaging is necessary to run on cluster and the shading
>> rules are there for Guava - Beam/Hadoop..
>>
>> On Wed, Jun 8, 2016 at 12:14 PM Maximilian Michels <mx...@apache.org> wrote:
>>
>>> I like the compromise on the Maven naming scheme. Thanks for
>>> incorporating all the feedback!
>>>
>>> On Wed, Jun 8, 2016 at 6:49 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>> wrote:
>>>> Hi Taylor,
>>>>
>>>> Just to be clearn, in most other projects, we stage the distributions on
>>>> repository. We upload the distro and signatures to dist.apache.org
>>> only when
>>>> the vote passed.
>>>>
>>>> Basically, the release process I talked with Davor (and that I will
>>>> document) is:
>>>> - Tag and stage using mvn release:prepare release:perform
>>>> - Close repo
>>>> - Start vote
>>>> - If passed, forward vote to incubator
>>>> - If passed, close repo
>>>> - Upload distro to dist
>>>> - Announce the release (mailing lists, website)
>>>>
>>>> It's based on what I do in Karaf, ServiceMix, etc.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 06/08/2016 02:39 AM, P. Taylor Goetz wrote:
>>>>>
>>>>> Out of curiosity, is there a reason for distributing the release on
>>>>> repository.a.o vs. dist.a.o?
>>>>>
>>>>> In my experience repository.a.o has traditionally been used for maven
>>>>> artifacts, and dist.a.o has been for release artifacts (source
>>> archives and
>>>>> convenience binaries).
>>>>>
>>>>> I'd be happy to help with documenting the process.
>>>>>
>>>>> I ask because this might come up during an IPMC release vote.
>>>>>
>>>>> -Taylor
>>>>>
>>>>>> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID>
>>>>>> 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�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Amit Sela <am...@gmail.com>.
To Davor, JB and anyone else helping with the release, Thanks! this looks
great.
On Wed, Jun 8, 2016 at 9:11 PM Amit Sela <am...@gmail.com> wrote:
> Regarding Dan's questions:
> 1. I'm not sure - it is built with spark-*_2.10 but I honestly don't know
> if this matters for the runner itself, it could be nice to have in order to
> be more informative. In addition, this will change with Spark 2.0 to Scala
> 2.11 AFAIK.
> 2. This is to allow running out-of-the-box examples I guess. The Flink
> runner just tells you how to do it on your own here:
> https://github.com/apache/incubator-beam/tree/master/runners/flink
> Would you say this is a better approach ?
>
> In any case, packaging is necessary to run on cluster and the shading
> rules are there for Guava - Beam/Hadoop..
>
> On Wed, Jun 8, 2016 at 12:14 PM Maximilian Michels <mx...@apache.org> wrote:
>
>> I like the compromise on the Maven naming scheme. Thanks for
>> incorporating all the feedback!
>>
>> On Wed, Jun 8, 2016 at 6:49 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>> > Hi Taylor,
>> >
>> > Just to be clearn, in most other projects, we stage the distributions on
>> > repository. We upload the distro and signatures to dist.apache.org
>> only when
>> > the vote passed.
>> >
>> > Basically, the release process I talked with Davor (and that I will
>> > document) is:
>> > - Tag and stage using mvn release:prepare release:perform
>> > - Close repo
>> > - Start vote
>> > - If passed, forward vote to incubator
>> > - If passed, close repo
>> > - Upload distro to dist
>> > - Announce the release (mailing lists, website)
>> >
>> > It's based on what I do in Karaf, ServiceMix, etc.
>> >
>> > Regards
>> > JB
>> >
>> >
>> > On 06/08/2016 02:39 AM, P. Taylor Goetz wrote:
>> >>
>> >> Out of curiosity, is there a reason for distributing the release on
>> >> repository.a.o vs. dist.a.o?
>> >>
>> >> In my experience repository.a.o has traditionally been used for maven
>> >> artifacts, and dist.a.o has been for release artifacts (source
>> archives and
>> >> convenience binaries).
>> >>
>> >> I'd be happy to help with documenting the process.
>> >>
>> >> I ask because this might come up during an IPMC release vote.
>> >>
>> >> -Taylor
>> >>
>> >>> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID>
>> >>> 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é
>> > jbonofre@apache.org
>> > http://blog.nanthrax.net
>> > Talend - http://www.talend.com
>>
>
Re: 0.1.0-incubating release
Posted by Amit Sela <am...@gmail.com>.
Regarding Dan's questions:
1. I'm not sure - it is built with spark-*_2.10 but I honestly don't know
if this matters for the runner itself, it could be nice to have in order to
be more informative. In addition, this will change with Spark 2.0 to Scala
2.11 AFAIK.
2. This is to allow running out-of-the-box examples I guess. The Flink
runner just tells you how to do it on your own here:
https://github.com/apache/incubator-beam/tree/master/runners/flink
Would you say this is a better approach ?
In any case, packaging is necessary to run on cluster and the shading rules
are there for Guava - Beam/Hadoop..
On Wed, Jun 8, 2016 at 12:14 PM Maximilian Michels <mx...@apache.org> wrote:
> I like the compromise on the Maven naming scheme. Thanks for
> incorporating all the feedback!
>
> On Wed, Jun 8, 2016 at 6:49 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> > Hi Taylor,
> >
> > Just to be clearn, in most other projects, we stage the distributions on
> > repository. We upload the distro and signatures to dist.apache.org only
> when
> > the vote passed.
> >
> > Basically, the release process I talked with Davor (and that I will
> > document) is:
> > - Tag and stage using mvn release:prepare release:perform
> > - Close repo
> > - Start vote
> > - If passed, forward vote to incubator
> > - If passed, close repo
> > - Upload distro to dist
> > - Announce the release (mailing lists, website)
> >
> > It's based on what I do in Karaf, ServiceMix, etc.
> >
> > Regards
> > JB
> >
> >
> > On 06/08/2016 02:39 AM, P. Taylor Goetz wrote:
> >>
> >> Out of curiosity, is there a reason for distributing the release on
> >> repository.a.o vs. dist.a.o?
> >>
> >> In my experience repository.a.o has traditionally been used for maven
> >> artifacts, and dist.a.o has been for release artifacts (source archives
> and
> >> convenience binaries).
> >>
> >> I'd be happy to help with documenting the process.
> >>
> >> I ask because this might come up during an IPMC release vote.
> >>
> >> -Taylor
> >>
> >>> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID>
> >>> 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é
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
Re: 0.1.0-incubating release
Posted by Maximilian Michels <mx...@apache.org>.
I like the compromise on the Maven naming scheme. Thanks for
incorporating all the feedback!
On Wed, Jun 8, 2016 at 6:49 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Taylor,
>
> Just to be clearn, in most other projects, we stage the distributions on
> repository. We upload the distro and signatures to dist.apache.org only when
> the vote passed.
>
> Basically, the release process I talked with Davor (and that I will
> document) is:
> - Tag and stage using mvn release:prepare release:perform
> - Close repo
> - Start vote
> - If passed, forward vote to incubator
> - If passed, close repo
> - Upload distro to dist
> - Announce the release (mailing lists, website)
>
> It's based on what I do in Karaf, ServiceMix, etc.
>
> Regards
> JB
>
>
> On 06/08/2016 02:39 AM, P. Taylor Goetz wrote:
>>
>> Out of curiosity, is there a reason for distributing the release on
>> repository.a.o vs. dist.a.o?
>>
>> In my experience repository.a.o has traditionally been used for maven
>> artifacts, and dist.a.o has been for release artifacts (source archives and
>> convenience binaries).
>>
>> I'd be happy to help with documenting the process.
>>
>> I ask because this might come up during an IPMC release vote.
>>
>> -Taylor
>>
>>> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID>
>>> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Davor Bonaci <da...@google.com.INVALID>.
The third release candidate is now available for everyone's review [1],
which should be incorporating all feedback so far.
Please comment if there's additional feedback, as we are about to start the
voting process.
[1] https://repository.apache.org/content/repositories/orgapachebeam-1002
On Wed, Jun 8, 2016 at 12:10 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
> Thanks for the clarification JB. In the projects I’ve been involved with,
> I’ve not seen that practice.
>
> As long as the resulting release ends up on dist.a.o I don’t think it’s a
> problem.
>
> -Taylor
>
>
> > On Jun 8, 2016, at 12:49 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >
> > Hi Taylor,
> >
> > Just to be clearn, in most other projects, we stage the distributions on
> repository. We upload the distro and signatures to dist.apache.org only
> when the vote passed.
> >
> > Basically, the release process I talked with Davor (and that I will
> document) is:
> > - Tag and stage using mvn release:prepare release:perform
> > - Close repo
> > - Start vote
> > - If passed, forward vote to incubator
> > - If passed, close repo
> > - Upload distro to dist
> > - Announce the release (mailing lists, website)
> >
> > It's based on what I do in Karaf, ServiceMix, etc.
> >
> > Regards
> > JB
> >
> > On 06/08/2016 02:39 AM, P. Taylor Goetz wrote:
> >> Out of curiosity, is there a reason for distributing the release on
> repository.a.o vs. dist.a.o?
> >>
> >> In my experience repository.a.o has traditionally been used for maven
> artifacts, and dist.a.o has been for release artifacts (source archives and
> convenience binaries).
> >>
> >> I'd be happy to help with documenting the process.
> >>
> >> I ask because this might come up during an IPMC release vote.
> >>
> >> -Taylor
> >>
> >>> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID>
> 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é
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>
>
Re: 0.1.0-incubating release
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Thanks for the clarification JB. In the projects I’ve been involved with, I’ve not seen that practice.
As long as the resulting release ends up on dist.a.o I don’t think it’s a problem.
-Taylor
> On Jun 8, 2016, at 12:49 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> Hi Taylor,
>
> Just to be clearn, in most other projects, we stage the distributions on repository. We upload the distro and signatures to dist.apache.org only when the vote passed.
>
> Basically, the release process I talked with Davor (and that I will document) is:
> - Tag and stage using mvn release:prepare release:perform
> - Close repo
> - Start vote
> - If passed, forward vote to incubator
> - If passed, close repo
> - Upload distro to dist
> - Announce the release (mailing lists, website)
>
> It's based on what I do in Karaf, ServiceMix, etc.
>
> Regards
> JB
>
> On 06/08/2016 02:39 AM, P. Taylor Goetz wrote:
>> Out of curiosity, is there a reason for distributing the release on repository.a.o vs. dist.a.o?
>>
>> In my experience repository.a.o has traditionally been used for maven artifacts, and dist.a.o has been for release artifacts (source archives and convenience binaries).
>>
>> I'd be happy to help with documenting the process.
>>
>> I ask because this might come up during an IPMC release vote.
>>
>> -Taylor
>>
>>> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID> 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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Taylor,
Just to be clearn, in most other projects, we stage the distributions on
repository. We upload the distro and signatures to dist.apache.org only
when the vote passed.
Basically, the release process I talked with Davor (and that I will
document) is:
- Tag and stage using mvn release:prepare release:perform
- Close repo
- Start vote
- If passed, forward vote to incubator
- If passed, close repo
- Upload distro to dist
- Announce the release (mailing lists, website)
It's based on what I do in Karaf, ServiceMix, etc.
Regards
JB
On 06/08/2016 02:39 AM, P. Taylor Goetz wrote:
> Out of curiosity, is there a reason for distributing the release on repository.a.o vs. dist.a.o?
>
> In my experience repository.a.o has traditionally been used for maven artifacts, and dist.a.o has been for release artifacts (source archives and convenience binaries).
>
> I'd be happy to help with documenting the process.
>
> I ask because this might come up during an IPMC release vote.
>
> -Taylor
>
>> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID> 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
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: 0.1.0-incubating release
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Out of curiosity, is there a reason for distributing the release on repository.a.o vs. dist.a.o?
In my experience repository.a.o has traditionally been used for maven artifacts, and dist.a.o has been for release artifacts (source archives and convenience binaries).
I'd be happy to help with documenting the process.
I ask because this might come up during an IPMC release vote.
-Taylor
> On Jun 1, 2016, at 9:46 PM, Davor Bonaci <da...@google.com.INVALID> 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/