accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 19:07:40 GMT
Is another action we could take be adding profiles for each version of
dependencies to include appropriate dependencies (and dependencies'

I guess right now the problem is we throw in a generic "one size fits all"
distribution, and we're seeing the cracks in it?

On Fri, Jul 1, 2016 at 11:48 AM, Christopher <> wrote:

> On Fri, Jul 1, 2016 at 12:34 PM Josh Elser <> wrote:
> > 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?
> >
> I'm finding it difficult to express clearly the one or two top problems I'm
> trying to solve. I think this is one of those things that addresses several
> smaller problems, each of which on their own aren't that important, but add
> up. Some of those are:
> * Reduce developer workload so that we can more easily bump dependencies
> when needed for features, bugfixes, and security fixes.
> * Reduce the technical and licensing debt on our part (current and future),
> because we're taking on unnecessary bundling tasks which are prone to
> faulty assumptions.
> * Better communicate downstream responsibilities for integration so
> upstream Accumulo is not harmed by negative perceptions when it's not our
> fault (we made faulty assumptions and the user didn't reconcile them).
> * Refocus/narrow our responsibilities to the upstream project, and draw a
> distinction with additional integration responsibilities we might
> voluntarily take on, so that we can provide a better experience for
> integrators and ease/encourage greater adoption.
> * In general, encourage making fewer upstream assumptions about downstream
> use cases, so we can better support a wider audience of users.
> * Prefer extensible tools for users to customize their integration
> experience, rather than hard-code decisions for them.
> FWIW, it was reported to me today that a user ran into an issue where my
> recent update of commons-configuration caused an integration problem
> because our scripts/packaging do not bundle commons-configuration and we
> just assume it will work with the version provided by Hadoop lib directory.
> That's the kind of thing I'd like to avoid... users should understand that
> assumptions in our packaging may not work for them, and we're creating work
> for ourselves while failing to communicate that when we try to bundle
> everything for them.
> If we were a self-contained application, we could even go the opposite way,
> and bundle everything. But, we're not. We're picking and choosing what to
> bundle, and our choices might not be right. We should make it easier for
> the users to choose, instead.

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