On Tuesday 17 January 2012 05:29:33 pm Darrell Anderson wrote:
Article:
http://www.datamation.com/open-source/the-fragmentation-of-the-linux-deskto p-1.html
End of the first page:
"...Because maintaining and updating the code is a huge effort, and the development team is small, TDE does suffer from more bugs than you may be used to...."
Our release date goal is May 2012, but let's not release R14.0.0 unless all significant blocker, critical, and major bugs are resolved. :)
I would like to ask that we consider point releases when serious bugs need to be backported to a current release. For example, when we need to release R14.0.1 then we build and release new packages. I don't think any of us have been doing that.
Just thinking out loud....
Darrell
Just replying out loud.....
I can see that some of the comment from datamation maybe is waranted.
For me the fustration is building a package from git repo say tdebase on a monday then working on several other packages and then update the local git repo rebuilding tdebase on friday results in tdebase not building at all. Possibility due to a commit/patch/update in the source. I have since abandoned building from git and only use the 3.5.13 tarballs which have worked well for me.
My question is before a commit is made does whoever changed/updated/patched/crunched/mutilated the code, first see if it builds without barfing/puking then do the commit?
Usually, yes. However please remember that GIT is unstable in the middle of the development cycle, and that this is *typical* for most projects, FOSS or otherwise.
I have mentioned before that a list of backported patches should be maintained on the Etherpad. Francois Androit has done an excellent job of keeping the RHEL packages updated with backported patches, sadly I am not able to keep up with patching Debian/Ubuntu packages. Help would be appreciated on this front!
R14.0.0 is supposed to be a bugfix release. We have already closed out a lot of bugs on the tracker, so let's keep the patches and fixes rolling in!
Tim