accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Proposed binary packaging changes
Date Mon, 25 Jul 2016 18:08:54 GMT
No hurry. This is only for the 2.0 branch (master) for which there are no
immediate or near-term release plans. In addition, Josh has expressed some
concerns which make it clear there isn't consensus here (at least, not
among the discussion participants). So, take your time. I won't press until
we're nearer an actual release schedule for 2.0.

On Mon, Jul 25, 2016 at 11:51 AM Sean Busbey <busbey@cloudera.com> wrote:

> I was hoping to have time last weekend to review the discussion on the
> PR, but didn't find it.
>
> Just so I have an idea while planning my week, how big of a hurry are
> you to get this in Christopher? Would giving me next weekend be too
> long? I'm happy to only review after the fact if it is.
>
> On Thu, Jul 21, 2016 at 7:39 PM, Christopher <ctubbsii@apache.org> wrote:
> > Here's the PR I was thinking:
> https://github.com/apache/accumulo/pull/131
> > This gives us something concrete to discuss.
> >
> > On Mon, Jul 18, 2016 at 4:36 PM Christopher <ctubbsii@apache.org> wrote:
> >
> >> On Mon, Jul 18, 2016 at 4:35 PM Josh Elser <josh.elser@gmail.com>
> wrote:
> >>
> >>>
> >>>
> >>> Christopher wrote:
> >>> >> I've had quite the foray into ASF release policies over the past
two
> >>> >> >  days which brings me back to this.
> >>> >> >
> >>> >> >  I really don't believe that the amount of effort you claim
we
> will
> >>> save
> >>> >> >  will actually be beneficial overall. Our dependencies do
not
> >>> frequently
> >>> >> >  change which means that our L&N also do not frequently
change.
> >>> >> >
> >>> >> >  Even if I do concede that it will make things more simple
for
> >>> Accumulo
> >>> >> >  in the short-term, you're forcing change from N organizations
> which
> >>> >> >  already integrate Accumulo in its current state (you would
force
> all
> >>> >> >  downstream to change). I would rather solve this once in
> Accumulo.
> >>> >> >
> >>> >> >  If you want to create such a script to help users build their
own
> >>> >> >  artifact for their specific installation: great. I believe
that
> the
> >>> >> >  argument that such a script would save time in Accumulo in
> managing
> >>> our
> >>> >> >  L&N is false.
> >>> >> >
> >>> >
> >>> > I know it would have saved me a ton of time (and sanity) moving to
> >>> > commons-math3. How often it saves us time is debatable, agreed. But,
> >>> that's
> >>> > not a primary motivation. It's just a slight benefit, which might
> reduce
> >>> > the burden of bumping dep versions.
> >>> >
> >>> > I have a PR ready to push... not sure I'm 100% happy with it,
> because of
> >>> > the way it downloads deps one at a time (might be easier to download
> >>> then
> >>> > all at once using maven... but with some complication), and some of
> the
> >>> > changes need to be pushed as a separate commit anyway. So perhaps
> >>> you'll be
> >>> > able to see better what I'm thinking when you can see the changeset.
> >>> >
> >>> > As I said before, this isn't really about a single (or a few) big
> >>> > benefit(s). It's about numerous tiny ones, which are admittedly hard
> to
> >>> > measure. Whether it pays off in the long-run is hard to tell, but
> that's
> >>> > what I'm targeting... the long-term, though there may be some road
> >>> bumps in
> >>> > the short-term. I'm convinced this is the right thing to do, but I
> can
> >>> > understand the reluctance to accept my conclusion, when I've not
> done a
> >>> > good job of articulating dramatic, easy-to-see benefits.:(
> >>> >
> >>>
> >>> Would it be better for me to wait for your push before continuing
> >>> discussion? I feel like it's hard to talk over hypotheticals and might
> >>> just be distracting :). With changes, we can outline
> positives/negatives
> >>> rather than feelings.
> >>>
> >>>
> >> Yes, I think that would be better. I'll provide a link to the PR in this
> >> thread in case anybody's not watching PR notifications or JIRA.
> >>
>
>
>
> --
> busbey
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message