On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey <bus...@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. > + publishing > the binary jars to maven central needed for the public API? > > > On Thu, Jun 30, 2016 at 8:03 PM, Christopher <ctubb...@apache.org> wrote: > > > > The impetus for this was that I recently bumped our commons-math > dependency > > to commons-math3, and it was such a time sink to try to track down even > > just that one bundled dependencies LICENSE/NOTICE modifications. I > > seriously doubt our LICENSE/NOTICE files are fully up-to-date and in sync > > with other bundled deps which have been updated over time. > > > > This reasoning seems like avoiding the real problem, which seems distinct > from > not bundling 3rd party works. It's our job as a community to keep > accurate track of > our dependency licensing, even if we don't need to make a document about > it, > because we have to ensure that cat-x is kept out*. > > Changes needed in our LICENSE/NOTICE for a bundled dependency change > should be getting handled by whomever does each dependency change. Folks > who review changes (even in our commit-then-review process) should be > pointing > out where due diligence hasn't been done. We spent a ton of time getting > our > LICENSE/NOTICE files correct back in September. It'd be super > disappointing if > that impact of that effort atrophied. > > > > But, to the question of whether it's broke... I've seen several cases > where > > a version in our lib directory caused a problem with a version of the > same > > classes elsewhere in the user's system. The user thought they could just > > avoid any dependency convergence/reconciliation on their part, because > they > > thought Accumulo would just work... and when it didn't, they blamed > > Accumulo when it was their specific environment which was the problem. If > > we communicate that responsibility up front, perhaps we wouldn't get > blamed > > when users fail to do their due diligence to converge their dependencies > or > > when they use wildcards excessively in their classpath configs. > > If the downstream users are going to be fulfilling dependencies themselves, > should we try to provide an accurate range of versions that we properly > work > with? > > > * barring maneuvers related to "optional" deployment dependencies, natch. > > -- > busbey >
