Changing the subject to make sure folks not interested in TDF also pay attention.
For folks who haven’t been following closely, there’s been discussion on trying to find a more efficient way to do releases. In the past we cut a release candidate (RC) and start a vote but if issues are found, we have to cancel the vote, do another RC, and start yet another vote. A suggestion was made and supported by at least one board member to do more discussion and testing before calling for a vote. Therefore, if critical issues are found, there isn’t the additional overhead of canceling and restarting votes. So below is a proposal with my comments in-line. Feedback from everyone is welcome. On 10/26/14, 3:19 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >It seems to me that there are two types of releases: Normal releases and >“hot fix” releases. In the case of a normal release, I think there should >be mechanism built in to encourage people to commit fixes prior to the >release. I’m thinking something like this: > >1) There would be a period of time until a release is “frozen”. 72 hours? >Anyone working on something that should go into the release should commit >their work to develop before that time is up. I would call this a “last call for changes”. I think that’s what Justin is doing now for TDF1.2. I would suggest that we create nightly builds for TDF and other packages we release so the barrier to testing for folks who don’t have the repos is lower. They can poke at the nightly and let us know if they see any show-stoppers. > >2) Once the freeze goes into effect, a branch is made for release x.xx >for xyz 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. IMO, no need to create extra work for these lower-traffic packages. I’m guessing the reason you want to “freeze” the source is so we can better manage what we are voting on, but IMO, we can take it on a case-by-case basis. If someone does have some new thing they want to add at the last minute we can discuss whether to do it or not. For TDF, if it is some third-party example, I’d probably say yes. > >3) A discussion/VOTE is opened at that point and kept open until the >release is voted through. Any issues discovered should be corrected in >the release branch. If they are applicable to future releases, the change >should be applied to develop as well. 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. We should probably make sure we’ve heard positive thoughts from enough folks to be very sure the vote will succeed. We could open the vote sooner. Technically Justin is probably right that votes are supposed to be on a specific artifact [1] but we already fudge that with carry-over votes. > >For hot fixes, the last release branch should probably be branched and we >should have an expedited voting process. More than one board member has said that the 72-hour requirement is just a guideline and not policy so yes, we can have shorter vote cycles unless we get objections from the community. [1] http://www.apache.org/dev/release.html#approving-a-release
