Sean Busbey wrote:
On Fri, Jul 1, 2016 at 10:37 AM, Keith Turner<ke...@deenlo.com> wrote:
On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey<bus...@cloudera.com> wrote:
Targeting for 2.0, including updates in the README, and having mean for
helping
the downstream user find the appropriate licensing information makes me
much
more comfortable with this.
I have to ask though, why not just do source only releases? Or source
Not having the binary release would suck. Its nice to be able to easily
test the latest version of Accumulo on a cluster. Would not be able to
easily run our own cluster test suites against release candidates.
We don't need to have artifacts in the release to do this though. We
could have a nightly build job (for use on dev@accumulo) that makes
the binary artifacts needed. That job can take a git ref and default
to HEAD. if we want to grab e.g. release candidates to deploy we could
then use it.
If these test clusters are going to have to run some script to pull
down 3rd party jars, what's the difference in having that script
either build the accumulo jars or download them from a jenkins job?
Funny, you both just hit my initial reactions:
It would suck to not have the binary artifact and I wouldn't be
surprised if, by changing this, we break downstream projects (just as an
observation).
However, with additional tooling/infrastructure, we could probably get
back to a reasonable position for ease of use in what we have now.
This leads me to wonder: what problem are we trying to solve? By
avoiding the binary release, we're making our lives easier to release
code (the continual L&N work). The build becomes a bit simpler with only
a source-release.
If this is *really* about ease-of-use for downstream packagers (which
seemed to be your original intent, Christopher), is there a different
way we could solve this problem that would meet your needs (again,
assuming you're trying to make life easier as a package maintainer for
Fedora) that would not involve completely removing the binary tarball?
