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 <bus...@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 <ctubb...@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 <ctubb...@apache.org> wrote: > > > >> On Mon, Jul 18, 2016 at 4:35 PM Josh Elser <josh.el...@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 >
