accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 16:34:16 GMT
Sean Busbey wrote:
> On Fri, Jul 1, 2016 at 10:37 AM, Keith Turner<>  wrote:
>> On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey<>  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 

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?

View raw message