On Fri, Jul 1, 2016 at 12:34 PM Josh Elser <josh.el...@gmail.com> 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.
