tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

upcoming freeze for 2017Q3, now in careful mode

I'll be handling the 2017Q3 branch; this email explains what we're
headed for.   The goal is a boring short freeze!


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!


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.


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.


Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index