I like this plan overall. I am definitely in favor of more frequent, lighter-weight bugfix releases. We can start to move toward a regular schedule of them, based on whether there is enough there to warrant one each month / two months / whatever.
We could start by branching off 1.6.0 now, and merging in whatever bug fix commits make sense (pending a discussion as Christopher suggested). It can be kept in a ready-to-release condition, for whenever it's "time" for 1.6.1. What about 1.5.x? That will still receive feature changes as well as bug fixes, I assume, until it goes EOL. On Mon, May 12, 2014 at 10:44 AM, Josh Elser <[email protected]> wrote: > On 5/12/14, 10:41 AM, Keith Turner wrote: > >> On Sun, May 11, 2014 at 6:54 PM, Josh Elser<[email protected]> wrote: >> >> >SGTM. Looks like there aren't currently any fixes of much substance for >>> >1.6.1 presently, but there are a few that would make for a very-low >>> impact >>> >1.6.1, and a good 1.5.2 which also includes the fallout tickets shortly >>> >after 1.5.1. Timeframe looks good to me too. >>> > >>> >If we can get that reduced test burden for "real" bug-fix releases >>> >hammered out, a month sounds good to me. >>> >> >> Rather than reduce the test burden, it would be nice to make the cluster >> testing more automated like you and other have discussed. >> > > I think that would be a good parallel goal, but I would still think that 7 > days of testing for a bug-fix release is excessive. Most times for me the > pain is getting resources to test for such a long period, not necessarily > setting up the test. > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
