> 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