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