On Sun, Oct 23, 2011 at 11:06 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
On Sun, Oct 23, 2011 at 10:35 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snnip> > Thanks for checking. I know everybody is busy but would be nice if some of > these bugs were quashed before release. > > Any possibility the official release could be pushed to Nov. 15 and some > top/critical bugs get attention? > > If not then c'est la vie. Look forward to 3.5.13 anyway. :) > > Darrell
If you (or anyone else on this list) can get patches together and uploaded to the bugtracker for any of the bugs mentioned within the next week or so they can go into this release. If not then they will just have to wait I'm afraid--I can't push this release back any further, as it is blocking some rather critical updates that will solve other, more major problems.
Forgive me if I missed something on this thread but I'm talking mostly from what I've saw in the most recent SVN releases: isn't it better to
postpone
due to what may be a lack of polish that might drive away users in the same way KDE 4 and GNOME have done recently? One of the problems I have
noticed
ever since I started using Linux is that desktop environment teams are extremely preoccupied about release dates more than what users will experience when using said environment, resulting in what ends up as a product in a bug ridden mess that distros have to fix themselves before packaging.
Not doubting your judgement - or anyone's - on the release date, since
you
better than anyone have a better view of the project as a whole. Could it be in order to have small release updates (call it 3.5.13.1) over the 3.5.13 branch until 3.5.14 is released, in a way to address the bugs that are know to exist currently but can't make the release date? Otherwise they just get pushed further to what can be a good while. That would seem to me a good way to handle this situation.
Best regards, Tiago
**>
Our biggest problem is a lack of developer resources. If it were up to me I'd assign a subteam to handle SRUs, but we just don't have that kind of manpower unfortunately. If the 3.5.14 release drags on for an extended period of time then I may have to revisit this decision.
It has been over a year since our last release, and there are significant problems that I can't even begin to fix without seriously breaking the Trinity source for a few months. This could easily push the release date to another year from now--do you really want to use 3.5.12 (which doesn't even compile on modern Linux distributions) until then? ;-)
True enough ;)
Believe me I don't like the bugs that are still in the release, but from where I sit this is the best decision. Note that this is not a 3.6.x stable release, it is only an incremental update from 3.5.12.
I had assumed that in some way, given the time it takes to release, it probably would be interesting to do more bug fix releases but probably the versioning could be improved? I mean after all Trinity already supports things that KDE 3.5.10 didn't, like RandR. Have you considered trying to gather some financial support from big distros to hire developers to help, since it seems to be some interest in having Trinity for enterprise related distributions? At least I got the impression that it could be possible to gather some support from what I've read for a few months now.
Best regards, Tiago
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting