flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: [DISCUSS] No RC process for releases
Date Sat, 29 Nov 2014 17:07:18 GMT
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 <justin@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

Mime
View raw message