Tim, Serghei,
I know you both are working hard, but would one of you please provide an estimated date when the porting to cmake will be complete for all Trinity packages?
Thanks.
Darrell
How about the courtesy of a short reply? :)
Weeks? A month? Two months? Next year?
Darrell
--- On Tue, 3/29/11, Darrell Anderson humanreadable@yahoo.com wrote:
From: Darrell Anderson humanreadable@yahoo.com Subject: [trinity-devel] Estimated date of completing cmake conversion To: trinity-devel@lists.pearsoncomputing.net Date: Tuesday, March 29, 2011, 12:11 AM Tim, Serghei,
I know you both are working hard, but would one of you please provide an estimated date when the porting to cmake will be complete for all Trinity packages?
Thanks.
Darrell
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
How about the courtesy of a short reply? :)
Weeks? A month? Two months? Next year?
Darrell
I was going to reply and say late this year, but I held off because I really don't know if this is true or not. At the current pace it seems likely, but as we are getting more people involved with CMake and the difficult packages are being completed at this point it is very hard to say.
Sorry I can't be more specific. :-)
Tim
Thanks. I realize you and Serghei quietly are lighting fires (and I'm grateful!), but the rest of us haven't been told what's happening. :)
Some regular two-sentence announcements on this list would be nice. What got done, what's left to do. That's all. Otherwise people tend to get discouraged and move on. Not good. For example, an explanation of the tqtinterface revamping would be nice. I don't know what that means or entails. Keep some carrots in front of us so we don't walk away. :)
Okay. Months. Or thereabouts.
With the move to cmake and the future potential hook into QT4, I still vote for a release version of 3.6 rather than 3.5.13.
Sure, end-users see little difference, but the version bump is a public relations effort.
First, the major point bump shows a distancing from KDE3, which forever will be remembered as 3.5.10. Moving to 3.6 establishes a nominal identity for Trinity and establishes that something is happening.
Second, many people have declared KDE3 dead. A major point release bump causes people to pause and notice. Especially when the eventual press release mentions the future hooks to QT4 and move to cmake. That kind of work requires commitment and time --- meaning Trinity is not a fly-by-night project. That might stir interest with developers and packagers.
Lots of time to think about that, but that's my two pennies.
If the conversion is going to take months --- more or less, perhaps somewhere in between then and now there could be an unofficial 3.5.13 with bug quashing patches that can be back ported to 3.5.12. Or perhaps an official 3.5.13 as long as packagers understand they need to back port the patches and not use SVN. I have shared previously several dozen paper cuts that need attention to provide polish. The automake 2.65 change log says that the AH_CHECK_HEADERS macros were reinstalled. Therefore packagers should be able to build 3.5.13 on newer systems. Probably so because I successfully built all of 3.5.10 on Slackware 13.1, which has autoconf 2.6.5.
Possibly just as important, a small point release like 3.5.13 announces to the world that Trinity is not stagnant. If SVN/cmake will not be fully ready for a long time then such a lack of visible progress might create that impression to outsiders. Would be nice to see some critical and paper cut bugs quashed --- but that's not my call because I don't know C++. :) I can test and package, however.
And any 3.5.13 announcement would declare the release as such: a paper cut release focusing on polish and support for newer systems.
I have a bunch of patches I collected to build 3.5.10 on Slackware 13.1. I plan to go through them and submit any that are missing from Trinity. For example, there are patches for libpng 1.4. Some are related to gcc 4. Etc. Probably all of those will be needed for any subsequent release, whether 3.5.13 or 3.6.
Darrell
--- On Wed, 3/30/11, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
From: Timothy Pearson kb9vqf@pearsoncomputing.net Subject: Re: [trinity-devel] Estimated date of completing cmake conversion To: trinity-devel@lists.pearsoncomputing.net Date: Wednesday, March 30, 2011, 12:24 PM
How about the courtesy of a
short reply? :)
Weeks? A month? Two months? Next year?
Darrell
I was going to reply and say late this year, but I held off because I really don't know if this is true or not. At the current pace it seems likely, but as we are getting more people involved with CMake and the difficult packages are being completed at this point it is very hard to say.
Sorry I can't be more specific. :-)
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
On 30 March 2011 15:44, Darrell Anderson humanreadable@yahoo.com wrote:
Thanks. I realize you and Serghei quietly are lighting fires (and I'm grateful!), but the rest of us haven't been told what's happening. :)
Some regular two-sentence announcements on this list would be nice. What got done, what's left to do. That's all. Otherwise people tend to get discouraged and move on. Not good. For example, an explanation of the tqtinterface revamping would be nice. I don't know what that means or entails. Keep some carrots in front of us so we don't walk away. :)
Okay. Months. Or thereabouts.
With the move to cmake and the future potential hook into QT4, I still vote for a release version of 3.6 rather than 3.5.13.
Sure, end-users see little difference, but the version bump is a public relations effort.
First, the major point bump shows a distancing from KDE3, which forever will be remembered as 3.5.10. Moving to 3.6 establishes a nominal identity for Trinity and establishes that something is happening.
Second, many people have declared KDE3 dead. A major point release bump causes people to pause and notice. Especially when the eventual press release mentions the future hooks to QT4 and move to cmake. That kind of work requires commitment and time --- meaning Trinity is not a fly-by-night project. That might stir interest with developers and packagers.
Lots of time to think about that, but that's my two pennies.
If the conversion is going to take months --- more or less, perhaps somewhere in between then and now there could be an unofficial 3.5.13 with bug quashing patches that can be back ported to 3.5.12. Or perhaps an official 3.5.13 as long as packagers understand they need to back port the patches and not use SVN. I have shared previously several dozen paper cuts that need attention to provide polish. The automake 2.65 change log says that the AH_CHECK_HEADERS macros were reinstalled. Therefore packagers should be able to build 3.5.13 on newer systems. Probably so because I successfully built all of 3.5.10 on Slackware 13.1, which has autoconf 2.6.5.
Possibly just as important, a small point release like 3.5.13 announces to the world that Trinity is not stagnant. If SVN/cmake will not be fully ready for a long time then such a lack of visible progress might create that impression to outsiders. Would be nice to see some critical and paper cut bugs quashed --- but that's not my call because I don't know C++. :) I can test and package, however.
And any 3.5.13 announcement would declare the release as such: a paper cut release focusing on polish and support for newer systems.
I have a bunch of patches I collected to build 3.5.10 on Slackware 13.1. I plan to go through them and submit any that are missing from Trinity. For example, there are patches for libpng 1.4. Some are related to gcc 4. Etc. Probably all of those will be needed for any subsequent release, whether 3.5.13 or 3.6.
Darrell
I agree with you on this point. I think that a version bump is at this point a good idea. With the conversion to CMake, qt4 advancements, as well as fixing up alot of papercut bugs, I think it would be time to bump versions to 3.6
Calvin Morrison
+1
On Wed, Mar 30, 2011 at 9:33 PM, Calvin Morrison mutantturkey@gmail.comwrote:
On 30 March 2011 15:44, Darrell Anderson humanreadable@yahoo.com wrote:
Thanks. I realize you and Serghei quietly are lighting fires (and I'm
grateful!), but the rest of us haven't been told what's happening. :)
Some regular two-sentence announcements on this list would be nice. What
got done, what's left to do. That's all. Otherwise people tend to get discouraged and move on. Not good. For example, an explanation of the tqtinterface revamping would be nice. I don't know what that means or entails. Keep some carrots in front of us so we don't walk away. :)
Okay. Months. Or thereabouts.
With the move to cmake and the future potential hook into QT4, I still
vote for a release version of 3.6 rather than 3.5.13.
Sure, end-users see little difference, but the version bump is a public
relations effort.
First, the major point bump shows a distancing from KDE3, which forever
will be remembered as 3.5.10. Moving to 3.6 establishes a nominal identity for Trinity and establishes that something is happening.
Second, many people have declared KDE3 dead. A major point release bump
causes people to pause and notice. Especially when the eventual press release mentions the future hooks to QT4 and move to cmake. That kind of work requires commitment and time --- meaning Trinity is not a fly-by-night project. That might stir interest with developers and packagers.
Lots of time to think about that, but that's my two pennies.
If the conversion is going to take months --- more or less, perhaps
somewhere in between then and now there could be an unofficial 3.5.13 with bug quashing patches that can be back ported to 3.5.12. Or perhaps an official 3.5.13 as long as packagers understand they need to back port the patches and not use SVN. I have shared previously several dozen paper cuts that need attention to provide polish. The automake 2.65 change log says that the AH_CHECK_HEADERS macros were reinstalled. Therefore packagers should be able to build 3.5.13 on newer systems. Probably so because I successfully built all of 3.5.10 on Slackware 13.1, which has autoconf 2.6.5.
Possibly just as important, a small point release like 3.5.13 announces
to the world that Trinity is not stagnant. If SVN/cmake will not be fully ready for a long time then such a lack of visible progress might create that impression to outsiders. Would be nice to see some critical and paper cut bugs quashed --- but that's not my call because I don't know C++. :) I can test and package, however.
And any 3.5.13 announcement would declare the release as such: a paper
cut release focusing on polish and support for newer systems.
I have a bunch of patches I collected to build 3.5.10 on Slackware 13.1.
I plan to go through them and submit any that are missing from Trinity. For example, there are patches for libpng 1.4. Some are related to gcc 4. Etc. Probably all of those will be needed for any subsequent release, whether 3.5.13 or 3.6.
Darrell
I agree with you on this point. I think that a version bump is at this point a good idea. With the conversion to CMake, qt4 advancements, as well as fixing up alot of papercut bugs, I think it would be time to bump versions to 3.6
Calvin Morrison
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
-
Calvin Morrison -
Darrell Anderson -
Tiago Marques -
Timothy Pearson