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, we (pkgsrc-pmc) 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 confident that there will not be breakage, and that you are really sure that if there is any breakage (including on platforms you don't use), that you will fix it quickly, and definitely 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/llvm 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. Now is not the time for deleting groups of things (but single packages that meet the deletion criteria are fine). 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. 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 December 23. This quarter is always awkward because of Christmas, and this timing allows people the 23rd to update and start long-running builds. During the 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 December 30 (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