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