Hi, Was looking at the last two TourDeFlex releases, one which used the normal process and one that used the no RC process.
For Tour De Flex 1.1 using the normal process: Release 24th Sept RC2 12th Sept (4 PMC, 2 non binding) RC1 4th Sept (4 votes) For Tour De Flex 1.2 for using the no RC process: Released 29th Nov RC2 Nov 23rd (3 votes) RC1 Nov 14th (3 votes) RC0 Oct 31st (no votes) Initial Start Oct 26th Time taken 1.1 20 days 1.2 35 days. The no RC process increased to time to release from start to release, even if you factor in a few delays like ApacheCon. No of RCs 1.1 had 2, 1.2 had 3. The no RC process did not produce fewer RCs. One of the RCs could of been avoided if a NOTICE issue was caught earlier. No of votes (RCs checked by PMC) 1.1 had 10 votes (two non binding), 1.2 had 6. The was no voting by non PMC members in the no RC process. Did the no RC process find any issues before the first RC? A minor issue with an example title issue was found. An issue with NOTICE however was not found by the PMC unit the second RC. No of emails sent to list 1.1 about 70, 1.2 about 160. The no release process produced quite a bit more email. No of contributors Less people contributed on 1.2, so the no RC process doesn't seem to encourage any more participation. We didn't have any votes by non PMC members. Was it less work for the RM? No it was a lot more. Was it less work for the PMC? Probably not - while there were less votes there was more email. Checking a RC as simple as this is fairly straight forward. So on just about any metric you use the no RC process did not help this (relatively simple) release and it was a lot more work for the release manager. Other issues run into along the way: - There was little significant checking during the no RC phase of the release - No real way to know of the PMC has checked important things during this phase - It quite hard to know (without asking on the list) if issues found with the release would be consider mean a -1 vote and minor issues seemed to become blockers. - Because of the above it quite difficult to determine when a vote should be called - IMO because of the above two points this process tends towards having to obtaining PMC consensus before calling on a vote to make a release. (And that's against release voting procedure). - Lower level of participation by the PMC, it was a struggle trying to get 3 people to vote. - Not a smoother process Any suggestions on improving this process or should we just drop it and go back to the normal Apache release process which seem to run smoother, take less time, produce fewer RCs, produce less list email and also cause a little less conflict? Thanks, Justin
