accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Fri, 01 Jul 2016 15:37:04 GMT
On Fri, Jul 1, 2016 at 10:44 AM, Sean Busbey <busbey@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message