25 Jul
2012
25 Jul
'12
11:48 a.m.
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