I'll be handling the 2017Q3 branch; this email explains what we're headed for. The goal is a boring short freeze! * CAREFUL MODE Starting now, we're in careful mode. There are few hard fules, and no notion of permission. Basically, I want to enter the freeze without any significant new brokenness, so that during the freeze people can fix little things, instead of not being able to build a lot of packages because of messed-up dependencies, and that we exit the freeze without the need to fix things in arrears and do pullups. The normal pre-freeze flurry of updates and especially fixes are entirely welcome, with the caveat that you should only commit updates if you are really sure that if there is any breakage (including on platforms you don't use), that you will have fixed it by the time the freeze starts. If you have almost never caused this kind of breakage, you don't need to worry. If you are more than once in a great while in a hurry-up-fix-during-freeze situation, you probably should be a bit more careful :-) The only thing I'm explicitly asking that we avoid is non-micro updates to things that have large numbers (50ish) dependencies and significant risk. One group is language implementations: in recent memory at least perl and clang have been harder than all of us expected. Another group is foundational libraries that either have a history of updates causing problems or that have API changes or build system rototills. Another area is significant changes to mk/, such as compiler selection logic, etc. Finally I would like to avoid changing the default version of languages and large systems like python and php. Right after the freeze ends is a great time to dig in to all of these things. The recent poppler update is an example of something that was just fine last week (it's all fixed now, I think), and harder than everyone expected, but would be best avoided the day before the freeze. I'll deal with this by hoping for the best and if there is real trouble asking for the problematic update to be backed out. But with any luck we'll avoid having to think about that! * FREEZE I plan to start the freeze around 0000Z on September 19 (late Monday US, just after midnight Tuesday EU, Tuesday daytime Asia). During freeze, I'd like to limit changes to build fixes, security fixes, micro updates (those documented to be bug fixes and obviously safe changes only) that carry security fixes (any package), and micro updates (leaf packages). Starting 0000Z on September 26 (1 week later), we'll exit the freeze as soon as things seem stable enough. * TESTING As always, bulk builds or other testing (pkg_rr, or however you update) is appreciated. Now is a reasonable time to start if you don't mind rebuilding some things later. Thanks, gdt
Attachment:
signature.asc
Description: PGP signature