Re: [kde] Copy file with Nepomuk meta-data
On Friday 10 May 2013 04:59:51 you wrote: Wolfgang Mader posted on Thu, 09 May 2013 19:47:35 +0200 as excerpted: is there a way to _copy_ a file and also copy tags, comment, etc. Hi, I saw a similar question from either you or someone else a few days ago, but don't believe anyone had an answer. You are right. I already asked (almost) the same question, but it took me a little to realize, that the mail was received by the mailing list, but that the list must use not send to author option. Sorry for double posting, and thanks for your answer. (Here, I have semantic-desktop entirely disabled at build time, gentoo so it's a simple matter of ensuring a few USE flags are off, and thus have no nepomuk, no akonadi, no virtuoso, no rasqual or redland... so I'd not have your answer, but I can let you know about the other post with the same question and that both made the list, with no real answers so far.) ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
Re: [kde] Yet another failed KDE release?
On Thursday, May 09, 2013 08:32:10 PM James Tyrer wrote: On 05/07/2013 02:40 PM, Ross Boylan wrote: I too am finding the reliability of KDE and its apps not what I would like, but one thing puzzles me about this complaint, the statement that bug fixing is not welcomed... On Tuesday, May 07, 2013 02:54:19 AM James Tyrer wrote: The KDE development team appears to be interested in something other than producing a stable release. It really is that simple. As a result, the release process is not oriented towards producing a stable release. I'm not sure if the developers would agree, though most developers would rather make new things than fix old ones. They are supposedly fixing lots of bugs with each release; it's just there are so many. I have to, possibly, correct you here, and this is indicative of the problem. Is the tally of bugs fixed or of bugs closed? I understand that you and others ran into problems that were sufficiently serious and numerous to get you really annoyed. You may think, and I might agree, that software shouldn't have been released in such a state. But by your own admission you don't know what going on with the bugs fixed or closed. So perhaps you shouldn't blame the developers for something that you don't even know is happening. The 4.3 release notes http://www.kde.org/announcements/4.3/ refers to over 10,000 bugs fixed (vs 2,000 feature requests). Now maybe they are counting closed for all reasons as fixed, but they said fixed. It surely does not suggest a project devoting it all its resources to making new stuff. You complained KDE doesn't care about quality, the 4.9 release notes http://www.kde.org/announcements/4.9/ note he KDE Quality Team was set up earlier this year with a goal to improve the general levels of quality and stability in KDE software. The Team also set up a more rigorous testing process for releases starting with beta versions In short, you seem to have taken your experiences and developed a theory of the motivation and goals of the developers and the project. But your theory doesn't fit the facts too well. Maybe there is insufficient emphasis on software quality. But you make it easy to ignore your criticisms when you make over the top statements that KDE doesn't care about quality. Doesn't the existence of so many bugs tend to illustrate my point? Well, software has bugs. I'm not sure a bug count is a great quality metric, but bug-free software is an impossible standard. .. I find very useful the dystopian novel: The Rise of the Meritocracy which is a critique of the idea of the meritocracy. A meritocracy is defined by the search for merit -- but that is dependent on the definition of merit. I find that I have no merit in the KDE project despite the fact that I went to college and studied EE and computer science. In the KDE project, you obtain merit be designing a new application. So, that is the nail that everyone is hitting with their hammer. Where do you get the idea that you have no merit in the KDE project, or that someone fixing bugs would be greeted with anything other than enthusiasm? Well, it's free software and so there's bound to be some static, but apart from that :) I was bluntly told so by a developer -- that formal education in software development was not considered. And also told that I needed to write an application to obtain merit. merit in this context is not something I'm familiar with, but then I'm not a KDE developer. Apparently your annoyance in turned annoyed others, which may have prompted some harsh remarks. Individual developerrs do not speak with the voice of the entire project. The project desktop doesn't need another application. It needs thousands of bugs fixed. Better yet, it needs Total Quality Management methods to prevent the buts ever entering the code base -- hacking replaced with design as a method of writing code. And, self taught hackers and beginners mentored in how to write better code. Writing an application, will not accomplish these things. Note that I am one of those that needs some mentoring. It seems unrealistic to expect mentoring from people you are insulting, particularly when your insults are on shakey factual ground. Ross I am a whiz at writing procedural code. I have learned the basics of C++ on a micro (inside a class) basis, but I could use some help learning the fine points of the macro structure of object oriented code. Actually, this is why I find it interesting that I find that people that have learned C++ seem to know the macro structure but often don't write the small pieces of procedural code that do the actual work of the program well. BTW, I still use Thunderbird. ___ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives:
Re: [kde] Yet another failed KDE release?
On 05/10/2013 10:58 AM, Ross Boylan wrote: On Thursday, May 09, 2013 08:32:10 PM James Tyrer wrote: On 05/07/2013 02:40 PM, Ross Boylan wrote: I too am finding the reliability of KDE and its apps not what I would like, but one thing puzzles me about this complaint, the statement that bug fixing is not welcomed... On Tuesday, May 07, 2013 02:54:19 AM James Tyrer wrote: The KDE development team appears to be interested in something other than producing a stable release. It really is that simple. As a result, the release process is not oriented towards producing a stable release. I'm not sure if the developers would agree, though most developers would rather make new things than fix old ones. They are supposedly fixing lots of bugs with each release; it's just there are so many. I have to, possibly, correct you here, and this is indicative of the problem. Is the tally of bugs fixed or of bugs closed? I understand that you and others ran into problems that were sufficiently serious and numerous to get you really annoyed. You may think, and I might agree, that software shouldn't have been released in such a state. But by your own admission you don't know what going on with the bugs fixed or closed. So perhaps you shouldn't blame the developers for something that you don't even know is happening. I am asking you the question: fixed or closed? The 4.3 release notes http://www.kde.org/announcements/4.3/ refers to over 10,000 bugs fixed (vs 2,000 feature requests). Now maybe they are counting closed for all reasons as fixed, but they said fixed. It surely does not suggest a project devoting it all its resources to making new stuff. I reference the Commit Digests which shows Bugs Closed, not fixed: http://commit-digest.org/issues/2013-04-28/ This is the wrong metric for merit -- the wrong contingency for reinforcement. You complained KDE doesn't care about quality, the 4.9 release notes http://www.kde.org/announcements/4.9/ note he KDE Quality Team was set up earlier this year with a goal to improve the general levels of quality and stability in KDE software. The Team also set up a more rigorous testing process for releases starting with beta versions I do not say that KDE is not interested in quality. That is a misreading of what I said. What I said is that many developers are more interested in new features than a stable and bug free product. The result is a product which is never more than 90% finished. Testing is good. But, testing does not address the type of bugs that we are probably discussing. Testing can prevent regressions and it can check to see if new software conforms to the specifications. Some types of testing can catch specific types of coding errors. But, it can not find all types of bugs. If the KDE Quality Team is really focused on quality control, this is a good sign. However, there has been a KDE Quality Team for some time: http://dot.kde.org/2004/03/02/announcing-kde-quality-team and it wasn't exactly focused on quality control. In short, you seem to have taken your experiences and developed a theory of the motivation and goals of the developers and the project. But your theory doesn't fit the facts too well. I think that with more research you will find evidence to support my position. Maybe there is insufficient emphasis on software quality. But you make it easy to ignore your criticisms when you make over the top statements that KDE doesn't care about quality. Don't misunderstand ironic statements or dry humor. Doesn't the existence of so many bugs tend to illustrate my point? Well, software has bugs. I'm not sure a bug count is a great quality metric, but bug-free software is an impossible standard. That isn't really a true statement but I take your point. However, there are various types of bugs. The type that it is correct to say that about are things that don't work as expected despite the fact that all coding is correct. Yes, the only way to find these is to write the software and then find them. On the other end of the scale are coding errors and code that simply can't work. Basically code that should have never been placed in the code base. It is this later type of bug that I am talking about. That is what I am advocating Total Quality Management for developers to avoid so that they don't need to be fixed. It is much less work in the long run to use TQM to avoid bugs entering the code base rather than allowing bugs (which are coding or design errors) to be committed and then trying to find them through testing (later), after the fact, by someone else (or users) and then fixing them. Detroit found out that this wasn't the way to build cars -- wasn't the way to do quality control. SNIP people you are insulting Well, that is part of the problem, people taking objective analysis -- my expressing my opinion -- as a personal insult. It most certainly is not. No insult is meant
