On 11/29/14, 11:29 AM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>Hi, > >The aim here is to make future releases easier and save everyone time. We >tried it and it didn't work out well, let see if we can fix it >(suggestions anyone?) or just drop it and go back to the normal release >process. The notion that you can compare the timelines or the number of RCs of two different point releases of the same product in order to compare process efficiency would be valid if every release was similar, but, IMO they are not. Based on what I see in the RELEASE_NOTES [1], TDF1.2 took on integrating code from 3rd parties and integration of examples for a different product (Squiggly). Unfortunately, the former introduced the topic of cross-domain security, and the latter exposed a bug in the error reporting of the linker. TDF1.1 didn’t seem to take on anything like that. What is more interesting to me is estimating how the old process would have worked on TDF1.2 given the same timeline of when bugs were found. In my estimation, we saved one or two RCs: one for the 3rd party issue and one for the Squiggly issue. So, that saved us 3 or 6 emails and thus the community saved several hours, and theoretically, the RM saved time not having to send those emails and upload those RCs. I don’t think you can count RC0 given that its posting was not part of the “no RC” process, so in fact, not having RCs did find issues and having the unofficial candidate available on the CI server made it easier for one non-PMC member to find and mention the Squiggly issue. If it wasn’t clear when to call the vote, then that’s a topic worth improving on for the next release. One suggestion would be for folks to unofficially vote with a -1, 0, or +1 in the discuss thread so RM can know where they stand. -Alex [1] https://dist.apache.org/repos/dist/release/flex/tourdeflex/1.2/RELEASE_NOTE S
