On Nov 22, 2016, at 10:20, R. David Murray <rdmur...@bitdance.com> wrote: > I'm sorry, but I find this confusing. It wasn't what I understood > your previous email to mean, which means I didn't read it carefully > enough and saw it through a filter of my preconceptions.
No problem! We are doing things a bit differently this time, for several reasons as I've mentioned in previous emails. > Essentially, you are making B4 act like RC1 except that you are expecting > there to be fixes, and making RC1 act like RC2 with hopes that it really > is final. That's fine, but we really ought to have named them RC1 and > RC2 in that case. I think we just have a difference in terminology here and, yes, the terminology may differ somewhat from some previous releases. Beta 4 is the end of the beta stage; it is *not* a candidate to be released. There are still missing documentation changes and it contains previously unreleased and untested code. After b4, the final doc changes and a small number (we hope) of release critical code changes will go in for rc1. This is where we are right now. The goal is for rc1 to be able to be released as is, with zero changes other than the version tag. To me, that's a release candidate. > I'm not suggesting you change your plan now, except that you should *not* > open the 3.6 branch for commits until after *final* is released, in case > another RC is required. Unless you plan to branch and cherry pick for an > "RC2" if it is needed, which would be fine, but you should say that :) > If we in fact miss something in this really-an-RC phase (RC0?) that > is revealed by the testing of RC1, then I strongly recommend against > making changes to RC1 and then releasing the result as final without > external testing. We've had a brown bag release in the past by doing > that, for what we thought were "safe" fixes. Any "extra" RC period can > be really short, though. Yes, I think we are in agreement here. In the most recent email, I did not repeat everything from my earlier email in which I stated: "4. Once rc1 is tagged, the 3.6 branch will again be open for the usual maintenance-release-appropriate changes destined for 3.6.1. Any emergency fixes that might arise after rc1 and prior to 3.6.0 will be approved and merged from the 3.6 branch into the 3.6.0 release by me. I'm really hoping we won't have to do that!" I did not explicitly talk about an rc2 but it is in the PEP as an option. The goal as I see it is for rc1 to be the same as the final release other than the version info (v3.6.0rc1 vs v3.6.0 final). So option 0 is: 0. We find no release critical problems with rc1 and we retag, rebuild, and release it as 3.6.0 final. If we do find problems with rc1, I see three additional options: 1. If the problem(s) are truly trivial and we agree that the risk is truly minimal (release manager gut feel, hand wave, group consultation), we can release rc1 with the trivial fix as the final without another round of testing. 2. If a very small number of problems are found with rc1 that are more than trivial but still "manageable" (another release manager gut feel call), we can produce an rc2 and another round of testing and then retag, rebuild, and release as 3.6.0 final. 3. If multiple significant problems arise, we can go back to the beta stage and do additional beta releases until we think we are ready for a new release candidate. I am hoping for option 0, obviously. Between the time rc1 is released and up to the scheduled final release date, we will evaluate any release critical problems that arise and choose one of the other options. I share your concern about the risks of releasing untested code resulting in brown bag followups so option 1 would not be taken lightly. The major point I want to stress is that we are going to very carefully manage what goes into 3.6.0 from now until the end of the release. I think we have had some strain on the release process in the past when we've allowed ourselves to put too many changes in the final stages of a release and I want to avoid doing that for 3.6.0. I am also counting on all of you to help by following the Release Candidate stage criteria for 3.6 changes. Between now (the end of b4) and rc1, I am asking all of us to only push things to the 3.6 branch that should go into 3.6.0 rc1 and final, that is, reviewed release critical code fixes and final doc changes. I've opted to do this rather than totally lock down the 3.6 branch and/or accumulate changes for rc1 elsewhere because: - the period is relatively short - we're expecting a small number of code changes going into rc1 - so that we won't introduce further confusions with external repos et al - so we have the benefit of our standard buildbot testing. If you are not sure whether something is appropriate for the 3.6 branch, please ask before pushing. Once we reach rc1, by the criteria above, there will be zero to a very very small number of changes approved post-rc1 and those will be cherry-picked and managed separately and the 3.6 branch will open again for 3.6.1 changes unless, perish the thought, we need to go back and do more betas (option 3 above). I hope this all sounds reasonable and makes things clearer. Let me know if you have any further questions. Thanks everyone! --Ned -- Ned Deily n...@python.org -- [] _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
