accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 17:23:19 GMT
On Fri, Jul 1, 2016 at 12:07 PM, Sean Busbey <busbey@cloudera.com> wrote:

> On Fri, Jul 1, 2016 at 10:37 AM, Keith Turner <keith@deenlo.com> wrote:
> > On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey <busbey@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?
>

 To be clear, I would not want to just drop the binary tar ball w/o a
suitable replacement.  If all we had was the source tar ball I would have
write my own scripts create something for testing a release on a cluster.



>
> --
> busbey
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message