Hi Arun, thanks for the reply. I hope that I've come across as an earnest and motivated contributor who wants to help make high-quality releases. Volunteering myself as RM and pushing for a 2.4 was not a reflection on your stewardship of 2.x so far. I know it's a lot of work.
I didn't mean to suggest 12 releases per year. I was trying to couch my terminology with "monthly-ish" and "regular cadence". I must have missed the email thread where we decided on this, but 6-8 weeks per cycle is 100% fine with me. I obviously don't want meaningless releases just for the sake of releases, but I think HDFS-2832, HDFS-4949, and all the other improvements in branch-2 add enough value that cutting something is not meaningless. My impression of the two YARN JIRAs is that they're still roughly a month from being prod-ready, which is why I figured they could wait 6 weeks for the next 2.x. That was also not a slight on the YARN developers, it's that I think we should follow through if we're serious about a regular release cadence. As you allude to, we need to get used to slipping features to the next release. Symlinks one such example that I've personally been involved with, so I do understand. As an aside, I think this means that we should be more judicious about branch-2 merges in the future, since a regular cadence means branch-2 should stay in a releasable state. I hope we can avoid burdonsome code divergence through "hard-disable" patches (e.g. symlinks) or pushing down just refactors (sort of like HDFS-2832), but that remains to be seen. I can abandon the 2.3rc, and then release current branch-2 as 2.3. Would > that be better? > That'd be great. All I'm after here is a regular release cadence with good integration testing, so if you're willing to RM it, awesome. As I stated way back in the thread, feel free to email me if you think I can help with the release process. Thanks, Andrew
