> On Sun, Oct 23, 2011 at 10:35 PM, Timothy Pearson < > kb9vqf@...> 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? ;-) 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. Tim