Re: Post 1.5.3 and 1.6.3
This started making me think about making this clear for other components like FATE and RandomWalk. Accumulo dev's have made some effort to extract Fate, Tracing, RandomWalk and even ContinuousIngest, all to see the code copied (tracing, CI), with little attribution, or ignored (RW, Fate). The effort to create independent projects has largely been wasted. Worse, it has led to convoluted duplication within our own code base. For example, multiple copies of zookeeper-related code. I would rather do something like port RW to HBase, and adopt that version for Accumulo, like we have for tracing. Otherwise, I wouldn't bother putting any effort into separating these modules with some abstract notion that someone else might use it. -Eric On Wed, Jul 8, 2015 at 3:43 PM, Josh Elser josh.el...@gmail.com wrote: Some thoughts myself... John Vines brought up to me privately the topic of separating out the RFile code from core. This started making me think about making this clear for other components like FATE and RandomWalk. These all have some level of separation, but they often get other things dropped into the same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes in RandomWalk). Maybe there are more things we could do. It would be nice to start trying to pull out these frameworks/sub-projects into discrete packages. I think it would help us with testing and proper separation of logic. Long term, maybe other projects would see the value and consider using/adopting them and grow into their own separately-versioned artifacts. It would be nice to start these efforts now to eventually reap the benefits. 2.0 and the new client API is a little scary now that we get another tick closer to it. I know it's been Christopher's brain-child so far (which is fine -- not meant to be taken in a negative context), but, if we really do want to adopt it, we should make a concerted effort to start integrating and reviewing it. Given how far away this seems, 1.8 and 1.9 could happen (or client API just gets targeted for a 3.0 -- numbers are just numbers). We have some decent script improvements for 1.8 already in (PID files _finally_). Would be nice to clean up the rest of the scripts too (notably the stop scripts need some love). Some other back-burner thoughts: better client API metrics, more server-side tracing instrumentation, Adam's iterator-stack collapsing perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI work, finish the Accumulo monitor rewrite (aka REST server + servlet3). - Josh Josh Elser wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
I think we also need a formal announcement that the branch is EOM and may only be resuscitated for critical security issues (and may not at that). To illustrate the need, I noticed the 1.5.3 release made Hadoop Weekly but there was no mention that it is the last expected 1.5.z release. On Tue, Jul 7, 2015 at 3:46 PM, Christopher ctubb...@apache.org wrote: Good point. On Tue, Jul 7, 2015, 15:36 Josh Elser josh.el...@gmail.com wrote: Upgrade testing out of 1.5.x to 1.6 or 1.7? Christopher wrote: What else is there to do for 1.5 EOL? We've indicated this already in the 1.5.3 release announcement and we've removed the 1.5 development branch. As far as I'm concerned, I think the last remaining thing to do is to archive the 1.5 parts of the website... and I see no particular rush for that. We can do it along with the next minor or major release. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jul 7, 2015 at 11:58 AM, Sean Busbeybus...@cloudera.com wrote: I'd like to see the 1.5 EOL happen. On Mon, Jul 6, 2015 at 3:04 PM, Josh Elserjosh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh -- Sean -- Sean
Re: Post 1.5.3 and 1.6.3
Do you think we didn't cover that appropriately in the ANNOUNCE email and/or the release notes? I wouldn't have expected anything more from Hadoop Weekly than apache foo x.y.z, 1-2 high-level changes, read more _here_ Sean Busbey wrote: I think we also need a formal announcement that the branch is EOM and may only be resuscitated for critical security issues (and may not at that). To illustrate the need, I noticed the 1.5.3 release made Hadoop Weekly but there was no mention that it is the last expected 1.5.z release. On Tue, Jul 7, 2015 at 3:46 PM, Christopherctubb...@apache.org wrote: Good point. On Tue, Jul 7, 2015, 15:36 Josh Elserjosh.el...@gmail.com wrote: Upgrade testing out of 1.5.x to 1.6 or 1.7? Christopher wrote: What else is there to do for 1.5 EOL? We've indicated this already in the 1.5.3 release announcement and we've removed the 1.5 development branch. As far as I'm concerned, I think the last remaining thing to do is to archive the 1.5 parts of the website... and I see no particular rush for that. We can do it along with the next minor or major release. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jul 7, 2015 at 11:58 AM, Sean Busbeybus...@cloudera.com wrote: I'd like to see the 1.5 EOL happen. On Mon, Jul 6, 2015 at 3:04 PM, Josh Elserjosh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh -- Sean
Re: Post 1.5.3 and 1.6.3
I don't see a problem sending an extra note to the user@ alias and the twitter, just to be clear but I think we've sufficiently covered it for the larger ASF community with the announce@ notice. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jul 8, 2015 at 12:58 PM, Josh Elser josh.el...@gmail.com wrote: Do you think we didn't cover that appropriately in the ANNOUNCE email and/or the release notes? I wouldn't have expected anything more from Hadoop Weekly than apache foo x.y.z, 1-2 high-level changes, read more _here_ Sean Busbey wrote: I think we also need a formal announcement that the branch is EOM and may only be resuscitated for critical security issues (and may not at that). To illustrate the need, I noticed the 1.5.3 release made Hadoop Weekly but there was no mention that it is the last expected 1.5.z release. On Tue, Jul 7, 2015 at 3:46 PM, Christopherctubb...@apache.org wrote: Good point. On Tue, Jul 7, 2015, 15:36 Josh Elserjosh.el...@gmail.com wrote: Upgrade testing out of 1.5.x to 1.6 or 1.7? Christopher wrote: What else is there to do for 1.5 EOL? We've indicated this already in the 1.5.3 release announcement and we've removed the 1.5 development branch. As far as I'm concerned, I think the last remaining thing to do is to archive the 1.5 parts of the website... and I see no particular rush for that. We can do it along with the next minor or major release. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jul 7, 2015 at 11:58 AM, Sean Busbeybus...@cloudera.com wrote: I'd like to see the 1.5 EOL happen. On Mon, Jul 6, 2015 at 3:04 PM, Josh Elserjosh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh -- Sean
Re: Post 1.5.3 and 1.6.3
Also, might be worthwhile to look at thrift 0.9.2 for 1.8 For kerberos, https://issues.apache.org/jira/browse/THRIFT-2660. https://issues.apache.org/jira/browse/THRIFT-2274 might be a concern for us too (would have to check). Josh Elser wrote: Some thoughts myself... John Vines brought up to me privately the topic of separating out the RFile code from core. This started making me think about making this clear for other components like FATE and RandomWalk. These all have some level of separation, but they often get other things dropped into the same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes in RandomWalk). Maybe there are more things we could do. It would be nice to start trying to pull out these frameworks/sub-projects into discrete packages. I think it would help us with testing and proper separation of logic. Long term, maybe other projects would see the value and consider using/adopting them and grow into their own separately-versioned artifacts. It would be nice to start these efforts now to eventually reap the benefits. 2.0 and the new client API is a little scary now that we get another tick closer to it. I know it's been Christopher's brain-child so far (which is fine -- not meant to be taken in a negative context), but, if we really do want to adopt it, we should make a concerted effort to start integrating and reviewing it. Given how far away this seems, 1.8 and 1.9 could happen (or client API just gets targeted for a 3.0 -- numbers are just numbers). We have some decent script improvements for 1.8 already in (PID files _finally_). Would be nice to clean up the rest of the scripts too (notably the stop scripts need some love). Some other back-burner thoughts: better client API metrics, more server-side tracing instrumentation, Adam's iterator-stack collapsing perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI work, finish the Accumulo monitor rewrite (aka REST server + servlet3). - Josh Josh Elser wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
Yeah, that's why I brought it up now. If we're going to do it, we should do it now and let the shake-down begin. I know Hive has been on 0.9.2 for a while now, so I assume it's somewhat ok. I'm sure we'll be good testers :) Christopher wrote: Bumping thrift versions scares me... a lot... because of how terrible thrift has been about avoiding breakage and/or retaining functionality. It seems every time we bump to fix something we want fixed, we find many more things broken. I'd be much more interested in moving to something a bit more reliable than Thrift... maybe Java serialization (heavy use of Externalizable) or protocol buffers with Netty. But, maybe that's something more for 2.0 (or later, since it seems like it'd be a huge effort). Even just moving off thrift for the network and leaving it in place for the serialization, might be a big improvement in stability. I'd be far less concerned about bumping thrift if it only affected the proxy. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jul 8, 2015 at 6:25 PM, Josh Elserjosh.el...@gmail.com wrote: Also, might be worthwhile to look at thrift 0.9.2 for 1.8 For kerberos, https://issues.apache.org/jira/browse/THRIFT-2660. https://issues.apache.org/jira/browse/THRIFT-2274 might be a concern for us too (would have to check). Josh Elser wrote: Some thoughts myself... John Vines brought up to me privately the topic of separating out the RFile code from core. This started making me think about making this clear for other components like FATE and RandomWalk. These all have some level of separation, but they often get other things dropped into the same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes in RandomWalk). Maybe there are more things we could do. It would be nice to start trying to pull out these frameworks/sub-projects into discrete packages. I think it would help us with testing and proper separation of logic. Long term, maybe other projects would see the value and consider using/adopting them and grow into their own separately-versioned artifacts. It would be nice to start these efforts now to eventually reap the benefits. 2.0 and the new client API is a little scary now that we get another tick closer to it. I know it's been Christopher's brain-child so far (which is fine -- not meant to be taken in a negative context), but, if we really do want to adopt it, we should make a concerted effort to start integrating and reviewing it. Given how far away this seems, 1.8 and 1.9 could happen (or client API just gets targeted for a 3.0 -- numbers are just numbers). We have some decent script improvements for 1.8 already in (PID files _finally_). Would be nice to clean up the rest of the scripts too (notably the stop scripts need some love). Some other back-burner thoughts: better client API metrics, more server-side tracing instrumentation, Adam's iterator-stack collapsing perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI work, finish the Accumulo monitor rewrite (aka REST server + servlet3). - Josh Josh Elser wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
I completely agree with more abstracting separable funtionality where it makes sense. I think RFile makes sense. Maybe separating it out would help alleviate some problems I've seen with it being too tightly coupled with Hadoop config and Accumulo config. And, maybe it'd help with its API... right now, working with RFiles is a nightmare. Even just basic read/write is confusing. As for 2.0... I'm a bit scared of it myself. It keeps lagging in priority for me, and isn't going very far very quickly. I have tried to keep it rebase'd onto the latest master, but it's sometimes difficult to keep that up. One thing I have kept on top of, though, is dropping deprecated stuff in 2.0, so it's not burdened with old APIs and stuff we intend to remove. Everything else in that branch is either unfinished, or still a rough cut. I would like to start maintaining a current 2.0 branch, in our shared git in ASF-land, which is kept up-to-date, drops deprecated stuffs, and where I can start merging in each feature we complete in the API, as we go. My main concern with that is merge strategy... I don't want master tainted with merges from 1.7 - 2.0 - master. That'd be bad... and would cause huge problems for us. (1.7-master-2.0 is generally fine, though). That's one reason I previously suggested ceasing use of master as current development branch, and explicitly make a 1.8 branch for 1.8 devel. (because then, 1.7-1.8-2.0 would still make sense). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jul 8, 2015 at 3:43 PM, Josh Elser josh.el...@gmail.com wrote: Some thoughts myself... John Vines brought up to me privately the topic of separating out the RFile code from core. This started making me think about making this clear for other components like FATE and RandomWalk. These all have some level of separation, but they often get other things dropped into the same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes in RandomWalk). Maybe there are more things we could do. It would be nice to start trying to pull out these frameworks/sub-projects into discrete packages. I think it would help us with testing and proper separation of logic. Long term, maybe other projects would see the value and consider using/adopting them and grow into their own separately-versioned artifacts. It would be nice to start these efforts now to eventually reap the benefits. 2.0 and the new client API is a little scary now that we get another tick closer to it. I know it's been Christopher's brain-child so far (which is fine -- not meant to be taken in a negative context), but, if we really do want to adopt it, we should make a concerted effort to start integrating and reviewing it. Given how far away this seems, 1.8 and 1.9 could happen (or client API just gets targeted for a 3.0 -- numbers are just numbers). We have some decent script improvements for 1.8 already in (PID files _finally_). Would be nice to clean up the rest of the scripts too (notably the stop scripts need some love). Some other back-burner thoughts: better client API metrics, more server-side tracing instrumentation, Adam's iterator-stack collapsing perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI work, finish the Accumulo monitor rewrite (aka REST server + servlet3). - Josh Josh Elser wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
Bumping thrift versions scares me... a lot... because of how terrible thrift has been about avoiding breakage and/or retaining functionality. It seems every time we bump to fix something we want fixed, we find many more things broken. I'd be much more interested in moving to something a bit more reliable than Thrift... maybe Java serialization (heavy use of Externalizable) or protocol buffers with Netty. But, maybe that's something more for 2.0 (or later, since it seems like it'd be a huge effort). Even just moving off thrift for the network and leaving it in place for the serialization, might be a big improvement in stability. I'd be far less concerned about bumping thrift if it only affected the proxy. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Jul 8, 2015 at 6:25 PM, Josh Elser josh.el...@gmail.com wrote: Also, might be worthwhile to look at thrift 0.9.2 for 1.8 For kerberos, https://issues.apache.org/jira/browse/THRIFT-2660. https://issues.apache.org/jira/browse/THRIFT-2274 might be a concern for us too (would have to check). Josh Elser wrote: Some thoughts myself... John Vines brought up to me privately the topic of separating out the RFile code from core. This started making me think about making this clear for other components like FATE and RandomWalk. These all have some level of separation, but they often get other things dropped into the same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes in RandomWalk). Maybe there are more things we could do. It would be nice to start trying to pull out these frameworks/sub-projects into discrete packages. I think it would help us with testing and proper separation of logic. Long term, maybe other projects would see the value and consider using/adopting them and grow into their own separately-versioned artifacts. It would be nice to start these efforts now to eventually reap the benefits. 2.0 and the new client API is a little scary now that we get another tick closer to it. I know it's been Christopher's brain-child so far (which is fine -- not meant to be taken in a negative context), but, if we really do want to adopt it, we should make a concerted effort to start integrating and reviewing it. Given how far away this seems, 1.8 and 1.9 could happen (or client API just gets targeted for a 3.0 -- numbers are just numbers). We have some decent script improvements for 1.8 already in (PID files _finally_). Would be nice to clean up the rest of the scripts too (notably the stop scripts need some love). Some other back-burner thoughts: better client API metrics, more server-side tracing instrumentation, Adam's iterator-stack collapsing perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI work, finish the Accumulo monitor rewrite (aka REST server + servlet3). - Josh Josh Elser wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
Some thoughts myself... John Vines brought up to me privately the topic of separating out the RFile code from core. This started making me think about making this clear for other components like FATE and RandomWalk. These all have some level of separation, but they often get other things dropped into the same bucket (e.g. ZK-retry code in FATE, Accumulo implementation classes in RandomWalk). Maybe there are more things we could do. It would be nice to start trying to pull out these frameworks/sub-projects into discrete packages. I think it would help us with testing and proper separation of logic. Long term, maybe other projects would see the value and consider using/adopting them and grow into their own separately-versioned artifacts. It would be nice to start these efforts now to eventually reap the benefits. 2.0 and the new client API is a little scary now that we get another tick closer to it. I know it's been Christopher's brain-child so far (which is fine -- not meant to be taken in a negative context), but, if we really do want to adopt it, we should make a concerted effort to start integrating and reviewing it. Given how far away this seems, 1.8 and 1.9 could happen (or client API just gets targeted for a 3.0 -- numbers are just numbers). We have some decent script improvements for 1.8 already in (PID files _finally_). Would be nice to clean up the rest of the scripts too (notably the stop scripts need some love). Some other back-burner thoughts: better client API metrics, more server-side tracing instrumentation, Adam's iterator-stack collapsing perf ticket, keep tabs on HDFS tracing impl, keep tabs on HTrace's GUI work, finish the Accumulo monitor rewrite (aka REST server + servlet3). - Josh Josh Elser wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
I'd like to see the 1.5 EOL happen. On Mon, Jul 6, 2015 at 3:04 PM, Josh Elser josh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh -- Sean
Re: Post 1.5.3 and 1.6.3
Upgrade testing out of 1.5.x to 1.6 or 1.7? Christopher wrote: What else is there to do for 1.5 EOL? We've indicated this already in the 1.5.3 release announcement and we've removed the 1.5 development branch. As far as I'm concerned, I think the last remaining thing to do is to archive the 1.5 parts of the website... and I see no particular rush for that. We can do it along with the next minor or major release. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jul 7, 2015 at 11:58 AM, Sean Busbeybus...@cloudera.com wrote: I'd like to see the 1.5 EOL happen. On Mon, Jul 6, 2015 at 3:04 PM, Josh Elserjosh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh -- Sean
Re: Post 1.5.3 and 1.6.3
What else is there to do for 1.5 EOL? We've indicated this already in the 1.5.3 release announcement and we've removed the 1.5 development branch. As far as I'm concerned, I think the last remaining thing to do is to archive the 1.5 parts of the website... and I see no particular rush for that. We can do it along with the next minor or major release. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jul 7, 2015 at 11:58 AM, Sean Busbey bus...@cloudera.com wrote: I'd like to see the 1.5 EOL happen. On Mon, Jul 6, 2015 at 3:04 PM, Josh Elser josh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh -- Sean
Re: Post 1.5.3 and 1.6.3
Good point. On Tue, Jul 7, 2015, 15:36 Josh Elser josh.el...@gmail.com wrote: Upgrade testing out of 1.5.x to 1.6 or 1.7? Christopher wrote: What else is there to do for 1.5 EOL? We've indicated this already in the 1.5.3 release announcement and we've removed the 1.5 development branch. As far as I'm concerned, I think the last remaining thing to do is to archive the 1.5 parts of the website... and I see no particular rush for that. We can do it along with the next minor or major release. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jul 7, 2015 at 11:58 AM, Sean Busbeybus...@cloudera.com wrote: I'd like to see the 1.5 EOL happen. On Mon, Jul 6, 2015 at 3:04 PM, Josh Elserjosh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh -- Sean
Re: Post 1.5.3 and 1.6.3
On Mon, Jul 6, 2015 at 4:04 PM, Josh Elser josh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? I am still working on sampling. After that I was thinking of working on some ease of use issues, like optionally sending exceptions from the server side to the client. * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Post 1.5.3 and 1.6.3
Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
More importantly, when are we going to have a happy hour to celebrate? -Eric On Mon, Jul 6, 2015 at 4:04 PM, Josh Elser josh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: Post 1.5.3 and 1.6.3
+1 on the happy hour! On Mon, Jul 6, 2015 at 5:58 PM, Eric Newton eric.new...@gmail.com wrote: More importantly, when are we going to have a happy hour to celebrate? -Eric On Mon, Jul 6, 2015 at 4:04 PM, Josh Elser josh.el...@gmail.com wrote: Thanks to the efforts spearheaded by Christopher and verified by everyone else, we now have 1.5.3 and 1.6.3 releases! To keep the ball rolling, what's next? High level questions that come to mind... * When do we do 1.7.1 and/or 1.8.0? * What bug-fixes do we have outstanding for 1.7.1? * What other minor improvements do people want for 1.8.0? * Where does 2.0.0 stand? Should we make a bigger effort to getting the new client API stuff Christopher had started into Apache? Feel free to brainstorm here and/or on JIRA (tagging relevant issues to the desired fixVersion) - Josh
Re: 1.5.3 and 1.6.3
If anybody has any release notes items for 1.5.3 or 1.6.3, please comment on the following issues: https://issues.apache.org/jira/browse/ACCUMULO-3843 (1.5.3) https://issues.apache.org/jira/browse/ACCUMULO-3844 (1.6.3) A brief look at 1.5.3 shows that there's no docs changes since 1.5.2, so that makes updating the site a bit easier. I also checked for API changes... and there aren't any changes to public API, so it might not be worth updating javadocs either (but if somebody thinks we should, I'd be grateful for help with that when the time comes). I haven't quite finished looking at 1.6.3, but hopefully it has minimal doc changes, too (because I don't want to spend a lot of time updating the site). An rc0 is forthcoming for both 1.5.3 and 1.6.3. I won't call a vote on these, but just present them for testing. I'll call an rc1 vote (for both, concurrently) in a few days after people get a chance to examine them a bit. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, May 29, 2015 at 6:31 PM, Christopher ctubb...@apache.org wrote: I've narrowed the list down to 3 remaining issues which are still Unassigned. If nobody takes these by Monday, I'll punt them to a later version so I can start making some RCs. https://issues.apache.org/jira/issues/ACCUMULO-2990 https://issues.apache.org/jira/issues/ACCUMULO-3773 https://issues.apache.org/jira/issues/ACCUMULO-3865 -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, May 28, 2015 at 7:20 PM, Christopher ctubb...@apache.org wrote: All- I'm wrapping up triage'ing issues for 1.6.3. Below is the list of issues I haven't (yet) punted. If anybody wants these fixed in 1.6, now would be a great time to knock them out. If you want to assign one (or more) to yourself to work on, please feel free. If you feel it can be punted to a later version, or its priority should change, or if there's any other blockers you think should be included in 1.6.3, please comment and/or edit the relevant ticket. Blockers: https://issues.apache.org/jira/issues/ACCUMULO-2388 (assigned to Keith*) https://issues.apache.org/jira/issues/ACCUMULO-3755 (assigned to Keith*) https://issues.apache.org/jira/issues/ACCUMULO-3859 (assigned to Josh, Patch Available to review) * not marked In Progress, and I'm sure Keith wouldn't mind if somebody else wants to take them on. Critical (all Unassigned): https://issues.apache.org/jira/issues/ACCUMULO-2687 https://issues.apache.org/jira/issues/ACCUMULO-2990 https://issues.apache.org/jira/issues/ACCUMULO-3029 https://issues.apache.org/jira/issues/ACCUMULO-3169 https://issues.apache.org/jira/issues/ACCUMULO-3216 https://issues.apache.org/jira/issues/ACCUMULO-3773 https://issues.apache.org/jira/issues/ACCUMULO-3855 Major (all Unassigned): https://issues.apache.org/jira/issues/ACCUMULO-3250 https://issues.apache.org/jira/issues/ACCUMULO-3865 I'd like to vote on some RCs next week. Thanks! -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, May 27, 2015 at 4:38 PM, Josh Elser josh.el...@gmail.com wrote: SGTM -- makes sense given historically what we've actually ended up doing. Thanks for sending out a progress update. Christopher wrote: FWIW, I'm still triage'ing issues. I've finished all the 1.5.x issues, and have moved on to 1.6.x issues. For many of these, I just don't see a fixVersion happening for 1.6.3, or even 1.6.4 or 1.6.5 (if those occur). So, I'll most likely just drop 1.6.x from the fixVersion for these to avoid constant bumping. In fact, I'll probably just drop all but the most recent working branch... currently 1.8.0/master... for many of them. It's not that these *can't be* fixed for 1.6.x, it's just that I don't see that it is very probably that they will be, so rather than lie to ourselves, I'd prefer to just be realistic and drop the older fixVersions, rather than constantly bump them when we do bugfix releases. If these get fixed, and they are fixed for an earlier branch, great, we can update the fixVersion to include them. The way I see it, the fixVersion has two roles: planning/declared intent (for unresolved issues), and statement about which branch a fix is included in (for resolved issues). I obviously won't change any resolved issues. This is just about being realistic for unresolved issues. If I run into any critical or blocker issues, I probably won't bump or drop those (at least, not without discussion on the issue), but trivial or non-bug, or unlikely to be fixed in an older version issues, those are the ones I plan to drop the old fixVersions on. This is just triage... not final decisions... if I make a change you wish to contest, please
Re: 1.5.3 and 1.6.3
together. On Tue, May 12, 2015 at 2:04 PM, Christopherctubb...@apache.org wrote: Sure, we can discuss that separately. I'll start a new thread. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:58 PM, Sean Busbeybus...@cloudera.com wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopherctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopherctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
Re: 1.5.3 and 1.6.3
closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopherctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
Re: 1.5.3 and 1.6.3
FWIW, I'm still triage'ing issues. I've finished all the 1.5.x issues, and have moved on to 1.6.x issues. For many of these, I just don't see a fixVersion happening for 1.6.3, or even 1.6.4 or 1.6.5 (if those occur). So, I'll most likely just drop 1.6.x from the fixVersion for these to avoid constant bumping. In fact, I'll probably just drop all but the most recent working branch... currently 1.8.0/master... for many of them. It's not that these *can't be* fixed for 1.6.x, it's just that I don't see that it is very probably that they will be, so rather than lie to ourselves, I'd prefer to just be realistic and drop the older fixVersions, rather than constantly bump them when we do bugfix releases. If these get fixed, and they are fixed for an earlier branch, great, we can update the fixVersion to include them. The way I see it, the fixVersion has two roles: planning/declared intent (for unresolved issues), and statement about which branch a fix is included in (for resolved issues). I obviously won't change any resolved issues. This is just about being realistic for unresolved issues. If I run into any critical or blocker issues, I probably won't bump or drop those (at least, not without discussion on the issue), but trivial or non-bug, or unlikely to be fixed in an older version issues, those are the ones I plan to drop the old fixVersions on. This is just triage... not final decisions... if I make a change you wish to contest, please watch/follow the JIRA notifications and jump in to comment (ideally, volunteering to fix the issue in question). For some issues I've already passed, this has already happened, which is great. Anyway, this is just an update on what my intentions are, in case anybody is curious about all the JIRA edits lately, and in the next few days. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, May 21, 2015 at 1:22 PM, Christopher ctubb...@apache.org wrote: I know Corey volunteered, but I'd like to get started today releasing 1.6.3. So, if there's no objection in the next hour or so, I'm just going to move forward and produce an rc0 test release (no voting necessary, as it won't be released, but testing is welcome). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 10:17 PM, Corey Nolet cjno...@gmail.com wrote: That is, unless any of the new committers would like to take it on- in that case, I can help ;-) On Tue, May 12, 2015 at 3:41 PM, Corey Nolet cjno...@gmail.com wrote: I can get a 1.6.3 together. On Tue, May 12, 2015 at 2:04 PM, Christopher ctubb...@apache.org wrote: Sure, we can discuss that separately. I'll start a new thread. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:58 PM, Sean Busbey bus...@cloudera.com wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
Re: 1.5.3 and 1.6.3
SGTM -- makes sense given historically what we've actually ended up doing. Thanks for sending out a progress update. Christopher wrote: FWIW, I'm still triage'ing issues. I've finished all the 1.5.x issues, and have moved on to 1.6.x issues. For many of these, I just don't see a fixVersion happening for 1.6.3, or even 1.6.4 or 1.6.5 (if those occur). So, I'll most likely just drop 1.6.x from the fixVersion for these to avoid constant bumping. In fact, I'll probably just drop all but the most recent working branch... currently 1.8.0/master... for many of them. It's not that these *can't be* fixed for 1.6.x, it's just that I don't see that it is very probably that they will be, so rather than lie to ourselves, I'd prefer to just be realistic and drop the older fixVersions, rather than constantly bump them when we do bugfix releases. If these get fixed, and they are fixed for an earlier branch, great, we can update the fixVersion to include them. The way I see it, the fixVersion has two roles: planning/declared intent (for unresolved issues), and statement about which branch a fix is included in (for resolved issues). I obviously won't change any resolved issues. This is just about being realistic for unresolved issues. If I run into any critical or blocker issues, I probably won't bump or drop those (at least, not without discussion on the issue), but trivial or non-bug, or unlikely to be fixed in an older version issues, those are the ones I plan to drop the old fixVersions on. This is just triage... not final decisions... if I make a change you wish to contest, please watch/follow the JIRA notifications and jump in to comment (ideally, volunteering to fix the issue in question). For some issues I've already passed, this has already happened, which is great. Anyway, this is just an update on what my intentions are, in case anybody is curious about all the JIRA edits lately, and in the next few days. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, May 21, 2015 at 1:22 PM, Christopherctubb...@apache.org wrote: I know Corey volunteered, but I'd like to get started today releasing 1.6.3. So, if there's no objection in the next hour or so, I'm just going to move forward and produce an rc0 test release (no voting necessary, as it won't be released, but testing is welcome). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 10:17 PM, Corey Noletcjno...@gmail.com wrote: That is, unless any of the new committers would like to take it on- in that case, I can help ;-) On Tue, May 12, 2015 at 3:41 PM, Corey Noletcjno...@gmail.com wrote: I can get a 1.6.3 together. On Tue, May 12, 2015 at 2:04 PM, Christopherctubb...@apache.org wrote: Sure, we can discuss that separately. I'll start a new thread. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:58 PM, Sean Busbeybus...@cloudera.com wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopherctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopherctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
Re: 1.5.3 and 1.6.3
I know Corey volunteered, but I'd like to get started today releasing 1.6.3. So, if there's no objection in the next hour or so, I'm just going to move forward and produce an rc0 test release (no voting necessary, as it won't be released, but testing is welcome). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 10:17 PM, Corey Nolet cjno...@gmail.com wrote: That is, unless any of the new committers would like to take it on- in that case, I can help ;-) On Tue, May 12, 2015 at 3:41 PM, Corey Nolet cjno...@gmail.com wrote: I can get a 1.6.3 together. On Tue, May 12, 2015 at 2:04 PM, Christopher ctubb...@apache.org wrote: Sure, we can discuss that separately. I'll start a new thread. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:58 PM, Sean Busbey bus...@cloudera.com wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
1.5.3 and 1.6.3
I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii
Re: 1.5.3 and 1.6.3
Agree - 1.6.3 would be good to ship. Discuss on EOL 1.5 would be good to entertain. It's about that time. Sean Busbey wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopherctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopherctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii
Re: 1.5.3 and 1.6.3
let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
Re: 1.5.3 and 1.6.3
Sure, we can discuss that separately. I'll start a new thread. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:58 PM, Sean Busbey bus...@cloudera.com wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
Re: 1.5.3 and 1.6.3
I can get a 1.6.3 together. On Tue, May 12, 2015 at 2:04 PM, Christopher ctubb...@apache.org wrote: Sure, we can discuss that separately. I'll start a new thread. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:58 PM, Sean Busbey bus...@cloudera.com wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
Re: 1.5.3 and 1.6.3
That is, unless any of the new committers would like to take it on- in that case, I can help ;-) On Tue, May 12, 2015 at 3:41 PM, Corey Nolet cjno...@gmail.com wrote: I can get a 1.6.3 together. On Tue, May 12, 2015 at 2:04 PM, Christopher ctubb...@apache.org wrote: Sure, we can discuss that separately. I'll start a new thread. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:58 PM, Sean Busbey bus...@cloudera.com wrote: let's please have a labeled [DISCUSS] thread on when and how to EOL 1.5. On Tue, May 12, 2015 at 12:55 PM, Christopher ctubb...@apache.org wrote: And, whether or not we release 1.5.3, I do think we should consider closing out development on that branch after 1.7.0 is released. Anybody have any thoughts on that? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 1:48 PM, Christopher ctubb...@apache.org wrote: I'd like to think about releasing 1.5.3 and 1.6.3, since there are 75 and 82 commits in those branches, presumably fixing a lot of bugs. Is anybody willing to act as release manager for either of these and prepare the RCs? Perhaps somebody who hasn't already done some releases who wants to try? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sean
