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 Fri, 22 Jul 2016 00:39:32 GMT
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.
>

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