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é <j...@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é <j...@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 <amitsel...@gmail.com>
wrote:
+1 for Option2
On Fri, Jun 3, 2016 at 2:09 PM Jean-Baptiste Onofré <j...@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é <
j...@nanthrax.net
wrote:
Actually, I think we can fix both issue in one commit.
What do you think about renaming the main parent POM with:
groupId: org.apache.beam
artifactId: apache-beam
?
Thanks to that, the source distribution will be named
apache-beam-xxx-sources.zip and it would be clearer to dev.
Thoughts ?
Regards
JB
On 06/02/2016 03:10 PM, Jean-Baptiste Onofré wrote:
Another annoying thing is the main parent POM artifactId.
Now, it's just "parent". What do you think about renaming to
"beam-parent" ?
Regarding the source distribution name, I would cancel this
staging
to
fix that (I will have a PR ready soon).
Thoughts ?
Regards
JB
On 06/02/2016 03:46 AM, Davor Bonaci wrote:
Hi everyone!
We've started the release process for our first release,
0.1.0-incubating.
To recap previous discussions, we don't have particular
functional
goals
for this release. Instead, we'd like to make available what's
currently in
the repository, as well as work through the release process.
With this in mind, we've:
* branched off the release branch [1] at master's commit
8485272,
* updated master to prepare for the second release,
0.2.0-incubating,
* built the first release candidate, RC1, and deployed it to a
staging
repository [2].
We are not ready to start a vote just yet -- we've already
identified
a few
issues worth fixing. That said, I'd like to invite everybody to
take
a
peek
and comment. I'm hoping we can address as many issues as
possible
before we
start the voting process.
Please let us know if you see any issues.
Thanks,
Davor
[1]
https://github.com/apache/incubator-beam/tree/release-0.1.0-incubating
[2]
https://repository.apache.org/content/repositories/orgapachebeam-1000/
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
