Then it looks like we are freezing too soon. If we do
not even have time to
include things that are already complete and simply need to be added, DO NOT
FREEZE ANYTHING.
SECOND -- as long as renaming continues DO NOT FREEZE. Renaming is guaranteed
to BREAK things intended or not.
Solution - Until renaming is complete DO NOT FREEZE -- it is pointless while
renaming continues. Nobody can give any type of educated "it's ready to
freeze" when nobody has had a chance to build the code that is to be frozen.
If we must continue to rename, then set the soft freeze date 3 days after
renaming is complete -- otherwise we are setting ourselves up for failure and
we are pushing off functional additions to TDE for sake of renaming.
We should not be in this position on the proposed soft-freeze date.
A soft freeze is just that: soft. A soft freeze is the signal for the trainers to walk the
horses toward the starting gate. The horses still get to pee and poop if they need to
while they walk toward the gate and if they do, somebody is standing by with shovels and
buckets. The hard freeze occurs when the back gates are closed.
Renaming will continue for a long time. Renaming halts duration the freeze but continues
after the official release.
Breakage? Welcome to free/libre software. Breakage occurs daily. Just wait for the next
upstream release of libpng or gcc. Or systemd that the RedHat folks have snookered most
everybody into embracing hook, line, and sinker. Or the next time you update bleeding edge
Arch and you start whining about build failures. People upstream are like the honey badger
--- they don't give a shit about breakage downstream.
That said, perhaps we ought to consider when to invoke the soft freeze. What is utterly
critical right now? Slavek mentions some FTBFS issues. There are several more FTBFS bug
reports. Should we at least agree to resolve FTBFS issues before moving to the soft
freeze?
And of course, nobody talks about paper cut issues, which drive away users faster than a
wacked hornet's nest.
Darrell