>   I think we are at the point where we need to
> implement a code freeze against new changes to TDE until we
> have resolved all BLOCKER and CRITICAL bugs. Shooting at a
> moving target makes getting R14 to an acceptable baseline
> much more difficult than it need be. If there are a few more
> new changes required to build in functionality that is
> wanted in R14, that's fine, but once they are added, let's
> implement a 14 or 30 day freeze against new changes and get
> R14 in shape. What do you think? Please weigh in on the
> discussion.

I'm not against a soft freeze, but seems the moving target of late is upstream. Several new versions of upstream packages are causing the breakage. We have weathered the gory parts of GCC 4.7.x and ligpng 1.5.x. There might be some remaining glibc issues but I think we have resolved them.

The latest heartache is ffpmeg. We need somebody familiar with the changes to help with a template of sorts for what needs patching. Specifically, some basic preprocessor checks and the respective changes for the newer versions of ffmpeg.

> Darrell has shouldered much of the recent fixing and updating, but
> we cannot rely on his efforts alone -- there is too much to
> do. Regardless of your level of expertise, you can help by
> taking a bug and working through the code to find out where
> things are not working. Even if you can't fix it,
> identifying where the problem is moves the ball forward and
> is greatly needed. Lord knows that is what I do most of the
> time.

All I have been doing this summer is changing diapers. I still can't code in C++. I admit that changing one diaper is one thing, but changing a stadium full does tend to roughen one's spirits. :-)

> Seriously, if we are going to get R14 to the point of
> release, we need every able body to help. We are all busy,
> it is just a matter of making time. We have some really
> smart people on the list, let's all take a bug and work it
> to move R14 closer to done.

Many of the Blocker/Critical/Major bugs are build issues. People familiar with automake, cmake, make, etc. could help quash many of those bugs in short order. Many of the Normal/Minor build issue bugs are repeatable but for different packages. Resolve one and we have a template for resolving others.

We need to start usability testing. That means people install and use the GIT version. I have been doing that for several weeks. There are some nuisance bugs but nothing has blown up. I could use more testing of the migratekde3 and r14-xdg-update scripts to help identify corner cases and also how to deal with administratively locked files.

Darrell