Justin, The tone of your email is very confrontational. Very much: "See, I was right all along, I tried it and it doesn't work." You should really take more care when writing your emails. The way you wrote this one gives the impression it is meant to start another 'endless' discussion, which I'm sure you want to avoid as much as the rest of us.
EdB On Sat, Nov 29, 2014 at 9:27 AM, Justin Mclean <jus...@classsoftware.com> wrote: > 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 > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
