In the Commit Patches web page is the following patch:
[tdelibs] Add initial tdehardwaredevices skeleton to tdecore Do not use the added classes yet, as the API and ABI are still under heavy construction!
The work on tdehardwaredevices is important to remove the dependency on HAL. Yet skeleton or not, could we please NOT push any API/ABI changes until after R14? Pushing eventual API/ABI changes will create hardships, especially something as monumental as removing HAL dependencies.
As important as that might seem, the bug tracker receives very little attention. Are we developing a reputation of ignoring bug reports?
David and I seem to be the only ones actively trying to squash build issues. Obvious from the messages we post is there are many build related issues that need attention. David and I post a lot of build related questions to this list and frequently nobody answers. Many build related bug reports have been filed and remain untouched.
Not to mention a few hundred unanswered bug reports regarding usability.
According to a previous discussion, the math indicates that we won't resolve many bugs before R14 is released. That implies we are going to push R14 on schedule --- buggy.
Now that we have news about a significant customer using Trinity (LiMux project in Munich), should we be making every effort to quash a significant portion of the bugs and release an R14 that all users relish and even want to join us to help develop further? We sure could use that kind of extra help and publicity.
Darrell
On 30 March 2012 11:52, Darrell Anderson humanreadable@yahoo.com wrote:
In the Commit Patches web page is the following patch:
[tdelibs] Add initial tdehardwaredevices skeleton to tdecore Do not use the added classes yet, as the API and ABI are still under heavy construction!
The work on tdehardwaredevices is important to remove the dependency on HAL. Yet skeleton or not, could we please NOT push any API/ABI changes until after R14? Pushing eventual API/ABI changes will create hardships, especially something as monumental as removing HAL dependencies.
As important as that might seem, the bug tracker receives very little attention. Are we developing a reputation of ignoring bug reports?
David and I seem to be the only ones actively trying to squash build issues. Obvious from the messages we post is there are many build related issues that need attention. David and I post a lot of build related questions to this list and frequently nobody answers. Many build related bug reports have been filed and remain untouched.
That is because you guys are the only ones building trinity nightly on a daily basis :-)
I am steadily working through different bug reports at a crawling pace, and expect many of them to be pushed by R14. I have not even looked at any build problems as bug reports. I consider build bugs problems for packagers ( you ) and I let you resolve them because at this point you have a very good idea of how it works. I see there are a few marked as PATCHAVAIL. why not push those patches now that you have write access?
Not to mention a few hundred unanswered bug reports regarding usability.
According to a previous discussion, the math indicates that we won't resolve many bugs before R14 is released. That implies we are going to push R14 on schedule --- buggy.
Now that we have news about a significant customer using Trinity (LiMux project in Munich), should we be making every effort to quash a significant portion of the bugs and release an R14 that all users relish and even want to join us to help develop further? We sure could use that kind of extra help and publicity.
Don't forget they have been using kde3.5 for quite some time I suspect, and are currently using Trinity 3.5.12. While R14 may have bugs we _are_ getting through many of them.
I concur with the sentiment, only to then say "Yes, such is the plight of finite time and energy"
Calvin
That is because you guys are the only ones building trinity nightly on a daily basis :-)
I am steadily working through different bug reports at a crawling pace, and expect many of them to be pushed by R14. I have not even looked at any build problems as bug reports. I consider build bugs problems for packagers ( you ) and I let you resolve them because at this point you have a very good idea of how it works. I see there are a few marked as PATCHAVAIL. why not push those patches now that you have write access?
Don't forget they have been using kde3.5 for quite some time I suspect, and are currently using Trinity 3.5.12. While R14 may have bugs we _are_ getting through many of them.
I concur with the sentiment, only to then say "Yes, such is the plight of finite time and energy"
Yes, I understand very much the concept and reality of limited resources. :)
I am encouraged by your words. I realize that some members might be working quietly without noticeable "noise." I look forward to your patches. I know about some of them and am happy that they will improve Trinity in meaningful ways.
The thing about packagers is we are not automake and cmake experts. We learn but we post to the list because we are stumped. Yesterday I was given a simple one-liner fix for libksquirrel and the package built. These things are not obvious to all packagers and that is why we ask for help. Perhaps one day I'll see those solutions as being obvious but that day is not today. I'm good at exposing these problems but not always at fixing. :)
Regarding those build related bug reports that have patches. Yes I have commit access but I know from experience that a patch is not always good for all people. The patch always works great for the person submitting the patch but has no way to test the effects on other systems. I saw this a lot back with 3.5.12 when I first joined the project. I probably pushed Tim to swearing at times because everything worked on his Debian/Ubuntu systems and I would break them on my Slackware systems. For that reason I am not eager to push patches until others using different systems test the patches.
Darrell
In the Commit Patches web page is the following patch:
[tdelibs] Add initial tdehardwaredevices skeleton to tdecore Do not use the added classes yet, as the API and ABI are still under heavy construction!
The work on tdehardwaredevices is important to remove the dependency on HAL. Yet skeleton or not, could we please NOT push any API/ABI changes until after R14? Pushing eventual API/ABI changes will create hardships, especially something as monumental as removing HAL dependencies.
As important as that might seem, the bug tracker receives very little attention. Are we developing a reputation of ignoring bug reports?
David and I seem to be the only ones actively trying to squash build issues. Obvious from the messages we post is there are many build related issues that need attention. David and I post a lot of build related questions to this list and frequently nobody answers. Many build related bug reports have been filed and remain untouched.
Not to mention a few hundred unanswered bug reports regarding usability.
According to a previous discussion, the math indicates that we won't resolve many bugs before R14 is released. That implies we are going to push R14 on schedule --- buggy.
Now that we have news about a significant customer using Trinity (LiMux project in Munich), should we be making every effort to quash a significant portion of the bugs and release an R14 that all users relish and even want to join us to help develop further? We sure could use that kind of extra help and publicity.
Darrell
The funny thing is that the HAL dependency bug is among the oldest open bug reports on the tracker, dating back almost to the fork of KDE3.5. It is also one of the first things other desktops environments throw at us to claim that TDE is obsolete. This is high priority for me to fix, it has been over 3 years and in all that time no one has had the requisite expertise to repair it.
I would love to fix the bugs myself, however there is the issue of money and time on my end. Simply put I can't dedicate weeks of unpaid time to TDE each month; bills have to be paid and other tasks need to be finished. Then there is the issue of varying platforms and distributions; I use Debian and Ubuntu and see no build problems whatsoever. Linux can be somewhat infuriating for software developers for this reason; what works perfectly on one distribution fails on another. I don't have the time or resources to install and learn every distribution that TDE runs on, so I rely on others to handle the repair of bugs that only show up on their distribution or setup.
HAL is slowly breaking down as the kernel changes, and there will eventually come a time when it just doesn't work any more, making the initial development of an alternative imperative.
The R14.0 release can be pushed back if needed, especially since Slavek Banko has been fixing critical bugs in the Debian/Ubuntu packages for 3.5.13.
I know it is frustrating, but please remember that we are all volunteers working on this project because in many cases the alternatives are even worse than a buggy release of TDE. Just to be clear, I am not receiving payment for my work on TDE either; the money collected via the Donations page barely covers annual operating expenses, and many times falls short. If those involved in LiMux or any other major TDE deployment would provide coders willing to help squash bugs, or even sponsor the project, then we could make faster progress. I have yet to see this happen.
For now I continue to fix bugs that are most irritating to me, as I have time, in the finest FOSS tradition. :-) As others here do the same the bug list will slowly be whittled down, even if it takes longer than we would like.
Onward and Forward!
Tim
On Friday 30 March 2012 20:52:42 Timothy Pearson wrote: [...]
The funny thing is that the HAL dependency bug is among the oldest open bug reports on the tracker, dating back almost to the fork of KDE3.5. It is also one of the first things other desktops environments throw at us to claim that TDE is obsolete. This is high priority for me to fix, it has been over 3 years and in all that time no one has had the requisite expertise to repair it.
We have already suspend/hibernate support based on upower. Now I'm trying to replace HAL on mediamanager, using udisks2. This will take some time, because udisks2 is pretty new and is not very well documented.
On Friday 30 March 2012 20:52:42 Timothy Pearson wrote: [...]
The funny thing is that the HAL dependency bug is among the oldest open bug reports on the tracker, dating back almost to the fork of KDE3.5. It is also one of the first things other desktops environments throw at us to claim that TDE is obsolete. This is high priority for me to fix, it has been over 3 years and in all that time no one has had the requisite expertise to repair it.
We have already suspend/hibernate support based on upower. Now I'm trying to replace HAL on mediamanager, using udisks2. This will take some time, because udisks2 is pretty new and is not very well documented.
Could you focus on interfacing upower with kpowersave instead? udisks is a dead end from what I have been reading, and I already have a very large chunk of the needed generic udev interface, along with disk handling, completed as of yesterday night.
Thanks!
Tim
On Friday 30 March 2012 21:19:57 Timothy Pearson wrote:
On Friday 30 March 2012 20:52:42 Timothy Pearson wrote: [...]
The funny thing is that the HAL dependency bug is among the oldest open bug reports on the tracker, dating back almost to the fork of KDE3.5. It is also one of the first things other desktops environments throw at us to claim that TDE is obsolete. This is high priority for me to fix, it has been over 3 years and in all that time no one has had the requisite expertise to repair it.
We have already suspend/hibernate support based on upower. Now I'm trying to replace HAL on mediamanager, using udisks2. This will take some time, because udisks2 is pretty new and is not very well documented.
Could you focus on interfacing upower with kpowersave instead? udisks is a dead end from what I have been reading, and I already have a very large chunk of the needed generic udev interface, along with disk handling, completed as of yesterday night.
At this moment I want to replace hal on mediamanager. Ilya told me that soon opensuse will replace udisks with udisks2 and mediamanager will not working at all.
About kpowersave, I have already a battery monitor applet, based on upower. However, to replace kpowersave entirely will be difficult, because we have no mechanism to control cpu governors (upower do not provide such function, and as upower developers told me, will never do).
[...]
On Fri, Mar 30, 2012 at 14:38, Serghei Amelian serghei@thel.ro wrote:
At this moment I want to replace hal on mediamanager. Ilya told me that soon opensuse will replace udisks with udisks2 and mediamanager will not working at all.
At the moment you can run udisks in parallel with udisks2; the plan for suse is unknown as there is a great "debate" going on right now.
About kpowersave, I have already a battery monitor applet, based on upower. However, to replace kpowersave entirely will be difficult, because we have no mechanism to control cpu governors (upower do not provide such function, and as upower developers told me, will never do).
On Friday 30 March 2012 23:02:43 Robert Xu wrote:
On Fri, Mar 30, 2012 at 14:38, Serghei Amelian serghei@thel.ro wrote:
At this moment I want to replace hal on mediamanager. Ilya told me that soon opensuse will replace udisks with udisks2 and mediamanager will not working at all.
At the moment you can run udisks in parallel with udisks2; the plan for suse is unknown as there is a great "debate" going on right now.
I know, but we should be prepared for worst case :)
However, I won't develop for udisks version which will be deprecated sooner or later. Also, I have my own interest to made mediamanager functional with udisks2, because I won't to "taint" my system with HAL.
On Friday 30 March 2012 19:52:42 Timothy Pearson wrote:
... If those involved in LiMux or any other major TDE deployment would provide coders willing to help squash bugs, or even sponsor the project, then we could make faster progress. I have yet to see this happen.
well, I don't believe (in case of LiMux) that will happen 'by itself'. I'm pretty sure the people there are not really aware of the lack of ressources (manpower/money..) in the trinity project. IMHO, the best chance to change that would be if you, Tim, as the project leader, would contact them, asking what problems there are currently with their 3.5.12 deployment and what R14 could improve, even faster if they are willing to help/sponsor. (language should not be a problem, those who are in charge there can read/write in english good enough, for sure).
just my 0.02 €
Werner
The funny thing is that the HAL dependency bug is among the oldest open bug reports on the tracker, dating back almost to the fork of KDE3.5. It is also one of the first things other desktops environments throw at us to claim that TDE is obsolete. This is high priority for me to fix, it has been over 3 years and in all that time no one has had the requisite expertise to repair it.
I would love to fix the bugs myself, however there is the issue of money and time on my end. Simply put I can't dedicate weeks of unpaid time to TDE each month; bills have to be paid and other tasks need to be finished. Then there is the issue of varying platforms and distributions; I use Debian and Ubuntu and see no build problems whatsoever. Linux can be somewhat infuriating for software developers for this reason; what works perfectly on one distribution fails on another. I don't have the time or resources to install and learn every distribution that TDE runs on, so I rely on others to handle the repair of bugs that only show up on their distribution or setup.
HAL is slowly breaking down as the kernel changes, and there will eventually come a time when it just doesn't work any more, making the initial development of an alternative imperative.
The R14.0 release can be pushed back if needed, especially since Slavek Banko has been fixing critical bugs in the Debian/Ubuntu packages for 3.5.13.
I know it is frustrating, but please remember that we are all volunteers working on this project because in many cases the alternatives are even worse than a buggy release of TDE. Just to be clear, I am not receiving payment for my work on TDE either; the money collected via the Donations page barely covers annual operating expenses, and many times falls short. If those involved in LiMux or any other major TDE deployment would provide coders willing to help squash bugs, or even sponsor the project, then we could make faster progress. I have yet to see this happen.
For now I continue to fix bugs that are most irritating to me, as I have time, in the finest FOSS tradition. :-) As others here do the same the bug list will slowly be whittled down, even if it takes longer than we would like.
Yeah, some days I'm a grumpy old man. Probably forgot my vitamins this morning. :)
I am aware of the importance of removing hal dependency. That needs to be fixed sooner or later.
Yes, we're all volunteers. I am too. None of us get paid in the conventional sense, but we all get paid in the reward of using the software. None of us receives any less than we bargained and some of us get a tad more now and then.
My plea to anybody subscribed to this list:
Please look through the bug tracker. Look at what fits your skills. You don't have to open a bug tracker account. Just send me the patch. Or send me the snippet of code you think should be changed and I'll make a patch. I'll do the testing.
Build related bugs need help most (if we can't build the full package we can't test and resolve usability bugs). Some bugs are automake problems, some cmake, some linking, some not finding tqt headers, etc.
Just a couple of bug reports a week and the back log dwindles. Trinity improves with each resolved bug report. Please consider joining a great little project. And you get to use the software too. :)
Let's make R14 shine!
Darrell
-
Calvin Morrison -
Darrell Anderson -
Robert Xu -
Serghei Amelian -
Timothy Pearson -
Werner Joss