23 Oct
2011
23 Oct
'11
11:42 p.m.
On Sun, Oct 23, 2011 at 11:06 PM, Timothy Pearson <
kb9vqf(a)pearsoncomputing.net> wrote:
True enough ;)
On Sun, Oct
23, 2011 at 10:35 PM, Timothy Pearson <
kb9vqf(a)pearsoncomputing.net> wrote:
postpone
<snnip>
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 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.
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.
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(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)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