As I've been repeating lately, I'd like to tag 1.7.0-rc0 this weekend. We don't have any written, official-looking rules for patch acceptance during the -rc period, and have been playing by ear. The rule of thumb is that if a patch is not in 'master' by the time 1.7.0-rc0 is tagged, it won't be in 'master' until 1.7.0 final is released, unless it is: (1) a fix to a regression caused by changes since 1.6.6; (2) an obvious fix to a new feature we added since 1.6.6; or (3) an obvious fix to a problem we had even before 1.6.6. When you have a patch that adds yet another new feature that you think complements what we already added since 1.6.6, you could argue that the patch falls into the second category, by saying something like: "the new option to do X is not complete without configuration variable that tells git to do X by default, and another option to override the configuration". We need to discuss and judge if the the argument has merit, which would largely depend on what that X is. So the above list is not completely black-and-white. We'll cook 1.7.0-rc0 for a week or so, accumulating fixes and then tag rc1 by the end of this month. After that, only fixes in category (1) and perhaps really obvious ones in category (2) will be applied for rc2, which should happen around Feb 10th. I am hoping that we can cut the final release around mid February. I don't know if I have enough bandwidth to review and queue patches that fall outside of the above "meant for 1.7.0" criteria to 'next/pu' branches during the feature freeze, but that doesn't mean I'd discourage people from working on their own topics meant for post-1.7.0 cycle. Hopefully we have enough qualified people to help reviewing them. In any case, I'll be moving my focus to the 'master' branch from now on, and I ask contributors to help hunting and fixing problems in 'master', so that we can have a solid 1.7.0 release (on top of which you can build your favorite shiny new toys ;-). Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html