I still don't know where this "severely compromised builds of limited usefulness" thing comes from? what's so bad? You didn't veto its release, after all. And rightly so: a release doesn't mean "definitely works"; it means it was created the right way. It's OK to say it's buggy alpha software; this isn't an argument to not really release it.
But aside from that: if it should be used by someone, then who did you have in mind? It would be coherent at least to decide not to make alpha-like release, but, we agreed to, which is why this argument sort of surprises me. I share some concerns about piling on Databricks. Nothing here is by nature about an organization. However, this release really began in response to a thread (which not everyone here can see) about Databricks releasing a "2.0.0 preview" option in their product before it existed. I presume employees of that company sort of endorse this, which has put this same release into the hands of not just developers or admins but end users -- even with caveats and warnings. (And I think that's right!) While I'd like to see your reasons before I'd agree with you Mark, yours is a feasible position; I'm not as sure how people who work for Databricks can argue at the same time however that this should be carefully guarded as an ASF release -- even with caveats and warnings. We don't need to assume bad faith -- I don't. The appearance alone is enough to act to make this consistent. But, I think the resolution is simple: it's not 'dangerous' to release this and I don't think people who say they think this really do. So just finish this release normally, and we're done. Even if you think there's an argument against it, weigh vs the problems above. On Mon, Jun 6, 2016 at 4:00 PM, Mark Hamstra <m...@clearstorydata.com> wrote: > This is not a Databricks vs. The World situation, and the fact that some > persist in forcing every issue into that frame is getting annoying. There > are good engineering and project-management reasons not to populate the > long-term, canonical repository of Maven artifacts with what are known to be > severely compromised builds of limited usefulness, particularly over time. > It is a legitimate dispute over whether these preview artifacts should be > deployed to Maven Central, not one that must be seen as Databricks seeking > improper advantage. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
