Hi, > I would say that during the “last call”, if nobody speaks up with a plan > to commit stuff soon that shouldn’t be put into the release, that a > release branch is optional.
It's easy enough to create a release branch, but merging back into dev and master can sometimes be painful. I'm not sure what the point is for the utilities as we have many projects in a single repository and gits inability to handle sub trees simply. What has happen in the past (on a couple of occasions when working on a SDK release) is people have checked into the wrong branch which caused some merging issues. Also the automated test were mostly run on the develop not the release branch which also caused some issues. The simpler it is the less is likely to it is to cause issues IMO. Given it's simplicity (and no automated tests) I can't see TDF having any issues along those lines. > For TDF, if it is some third-party example, I’d probably say yes. Third party examples are external and not part of the release. > I think it would be simpler to open the discussion but not a vote until > the discussion doesn’t appear to have any release blockers being > discussed. +1 The concern I have is that this period could drag on a lot longer than the normal RC cycle and that people wont check things carefully until a vote is called. > More than one board member has said that the 72-hour requirement is just a > guideline But there needs to be a good reason for it to be shorter, given we are volunteers and are scattered across the global 72 seems a reasonable amount of time someone cay check and vote on a release. [1] (last bit in expressing votes).It's rare that we get 3 votes in under 48 hours anyway. Thanks, Justin 1. http://www.apache.org/foundation/voting.html
