Is another action we could take be adding profiles for each version of dependencies to include appropriate dependencies (and dependencies' metadata)?
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 <ctubb...@apache.org> wrote: > 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. >
