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