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 Mon, 25 Jul 2016 15:51:08 GMT
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
View raw message