accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 14:44:27 GMT
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
+ publishing
the binary jars to maven central needed for the public API?


On Thu, Jun 30, 2016 at 8:03 PM, Christopher <ctubbsii@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

Mime
View raw message