accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 18:48:04 GMT
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