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, 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!


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.


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