All,
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.
Additionally, if you have the knowledge to lend any help in resolving existing bugs -- your help is needed. I know a lot of you reading this are a lot smarter than I am on c++, but for whatever reason haven't yet grabbed a keyboard and jumped in to the bug tracker to help. 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.
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.
Dne st 25. července 2012 David C. Rankin napsal(a):
All,
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.
Additionally, if you have the knowledge to lend any help in resolving existing bugs -- your help is needed. I know a lot of you reading this are a lot smarter than I am on c++, but for whatever reason haven't yet grabbed a keyboard and jumped in to the bug tracker to help. 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.
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.
Hi David, all
I also watch these build-issues, because of 3.5.13.1. For this version is code frozen enough :) But note that at present also in the GIT head is no large-scale activity. Additionally, build-issues based on new versions of gcc, glibc, etc. seems to be with continuous character - can occur continuously as in the current code, as well as newly added. For both these reasons, I do not think that it was now necessary to explicitly declare code freeze for R14.
Unfortunately, none of my testing machines with Debian and Ubuntu contain new gcc, glibc, etc. where I can test these issues.
Slavek --
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