Re: "Set date and time automatically" is grayed out
On Sat 01 of Oct 2011 23:07:49 Nikos Chantziaras wrote: > There is a checkbox in the Date & Time System Settings that says "Set > date and time automatically". However, it's grayed out and can't be > enabled. > > What do I need to do to get that functionality? > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> unsubscribe << Do you have ntp installed? I think that it is required for automatic date and time synchonization. signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Sat, Oct 1, 2011 at 10:52 PM, Rui Maciel wrote: > On 09/30/2011 07:17 PM, todd rme wrote: >> >> If they don't have time to respond to all the bug reports, what makes >> you think they would have time to respond to just as many, if not >> more, emails? You would only be increasing the amount of stuff they >> need to read, further decreasing the amount of time they have to >> respond to bugs, not to mention fix them. In the end you would end up >> with the same situation: tons of emails left unanswered. > > The main problem is not how many messages, either those sent to this mailing > list or to the bug tracker, are left unanswered; it's how much time is > being wasted on a futile task. This problem is being incorrectly depicted > as one which only affects developers but in reality it affects every person > involved, including users. That's right. The more things they have to read, the less time they have to develop. Sending what amounts to duplicate bug reports is not going to help that, it is going to make it worse. Further, it would require even more time on the part of users as well, sending a ton of emails that would not and could not help the situation. So from a user perspective this approach also makes things worse. > You claimed that developers waste time browsing some messages. Yet, it > should also be noted that filing bug reports, particularly when providing > every piece of information which may be of any interest, does demand quite a > bit of time and energy from the users. In fact, a bug report which is left > untouched by any developer ends up being a complete waste of time for the > user who submitted it, while not affecting any developer in the process. If > you hold this in consideration while you browse through KDE's bug tracker > you will get an idea of how much time the current bug tracking policy is > forcing users to waste. This, as this thread demonstrates, is a > considerable source of frustration. So, if there is really an intention to > cut on how much time is being wasted with the current process then why not > start where it really is being entirely wasted? I am not sure I understand your proposal. My point is that sending emails can only make the situation worse. It will require more time on the part of both users and developers while not addressing the underlying problem: not enough eyes and not enough time. And you don't need to lecture me on frustration with the bug reporting process. I currently have 38 unconfirmed (including 1 major data loss bug) and 17 new bugs. That only includes bugs I reported myself (not ones I have but that there was already a bug for) and it does not include wishlist items. That is exactly why I am against anything that will make it less likely that my bugs will be solved, which is exactly what sending bugs to the mailing list does. The only thing that will improve the situation is having people help in the triage process. I don't do that full-time, but I certainly do point out when bugs are duplicates or already fixed when I see them. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: "Set date and time automatically" is grayed out
On 10/02/2011 10:14 AM, Θεόφιλος Ιντζόγλου wrote: On Sat 01 of Oct 2011 23:07:49 Nikos Chantziaras wrote: There is a checkbox in the Date& Time System Settings that says "Set date and time automatically". However, it's grayed out and can't be enabled. What do I need to do to get that functionality? Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe<< Do you have ntp installed? I think that it is required for automatic date and time synchonization. I had openntpd installed. Seems like this doesn't work. I removed it, and installed plain old ntp. Now the checkbox is active. Thanks. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help (links about bug triaging)
On Wednesday, September 28, 2011 01:46:14 PM Bart Kelsey wrote: > Hi folks, > > I'd like to draw attention to the fact that KDE's bug triage process is > lacking. > > It's frustrating for users submitting bug reports when an easily > reproducible bug sits in the queue, without even a comment, for six > months. For the record, I'm referring to this bug report here: > > https://bugs.kde.org/show_bug.cgi?id=270105 > > I have, for the record, already posted a message to plasma-devel about > it, and I'm mentioning it here because I believe it's indicative of a > larger problem. > > From my understanding of C++ and Qt, this bug is most likely very easy > to fix for someone who knows the code base. Even if it's not, though, > it would require a trivial amount of time to confirm it, leave a brief > comment, and mark the bug as new. > > My question, ultimately, is do you really want users to report bugs? > If so, there ought to be a process in place to make sure the users who > report the bugs know that the bugs have at least been looked at by a > human being (and preferably triaged). I realize this isn't exactly a > fun or interesting job, but for a large FOSS project like KDE, it's a > necessary one. > > Regards, > > Bart Kelsey > The bug refered there is not really a bug. It is a usability wish. In my opinion, such a wish should be accompanied by a strong use case. Do you often remove panels? when do you do so? why do you remove them "accidentally"? same for widgets. My use case is that I take time to set up my workspace when I install my distribution and then occasionally I need for example a new activity that I set up. The rest of the time I use my machine as it is. When I do those setup, I dedicate some amount of time which includes trial and error time. This is my use case. Yours can be different. As for general bugs: - the number of reported bugs is too large for developers to deal with it. We addressed this by trying to make the reporting smarter and by setting bugsquads days/weeks to "triage" bugs. Triaging means moving the bug report to a new state: - identify duplicates - reproduce the bug and mark it as CONFIRMED - write clearly the steps to reproduce it are 3 important states but there are others. Recommanded reading: Quick reading: http://techbase.kde.org/Contribute/Bugsquad/Guide Bug Triaging: http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging A bug's Life Cycle: https://bugs.kde.org/page.cgi?id=fields.html Setting up a bug day: http://techbase.kde.org/Contribute/Bugsquad Users do report bugs. Developers do fix bugs. To achieve better results, we need the intermediary: users participating in bug triaging. The last bug days I participated to, we were only a handful of people (and maybe not a complete handful even!) and I was very discouraged to carry on. Maybe we lacked promotion of it, the one regarding kdepim also was difficult to triage because technical. I urge you to be positive and help with an hour or so of contribution during the next month. I am willing to set up some week-end bug days, I am sure members of the bugsquad also are. But we need help otherwise it's just too much work when yo uare only 2 people. Please stay tuned to Planet KDE in the next days and volunteer to participate to any bug crushing effort that will be planned. Thanks for reading, Anne-Marie >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Saturday, 2011-10-01, Rui Maciel wrote: > On 09/30/2011 03:03 PM, Myriam Schweingruber wrote: > > Well yes, it is feasible, provided the database is completely triaged > > and there are actual people doing the queries, as those need to be > > done by sentient beings. Of course we welcome all volunteer triagers > > to give a hand:) See also my previous post though. > > What do you mean by "completely triaged"? If I'm not mistaken, by > default KDE's bug tracker lists bug reports sorted by report ID, which > is directly proportional to how old a bug report is and therefore "how > long they have been unanswered". This means that if you run a search on > KDE's bug tracker for the bugs filed on a specific project, the first > result that pops out by default is already the report which has been > left unaddressed the longest. Completely triaged in the sense of someone having weeded out all duplicates, requested and received all necessary additional information [1] and ideally confirmed to happen in a current built-from-source installation similar to what a developer will use when trying to fix it. Being the oldest report for a given product qualifies as an indicator of when a problem occured first, but just its age does not imply that any of these other criteria have been met. Cheers, Kevin [1] and ideally unrelated information removed, some reports accumulate a lot of noise over time. Especially when being linked to from forums and people adding their "me too", even if their problem is actually different. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Saturday, 2011-10-01, Scott Kitterman wrote: > We are worried about regressions, so we are careful about post-release > updates but we do do them. When I got approval to ship these updates the > fact that KDE has a policy to only put bug fixes in these updates was an > important part of getting it accepted (the Ubuntu project does not > generally do this, KDE has a special exception). Interesting. So do other projects ship bug fixes without patch level release or do the not ship bug fixes at all? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Saturday, 2011-10-01, Joshua Blocher wrote: > I think we are acting like it all has to be done manually which is > simply not true. Why are we tackling bug triage as something that only > a human can do? Because it potentially requires interpretation of natural language text, understanding of relations between concepts and ideally the ability to combine those to reproduce the problem. > Computers are good a repetitive tasks. Indeed they are. They are also very bad in doing things outside a very strict set of rules and are almost certainly not able to adapt those rules. > A little bit of > intelligent use of technology would reduce the "burden" on all of our > developers. KDE has semantic technology, use it. Or if that isn't good > enough there has to be another route. We can find possible duplicates > by matching debug text ranked by percent of similarity. 50% and below > most likely not a duplicate. 50% - 75% possibly a dup, if 75% and up > probably a dup. Then auto assign it to the correct original bug. How would this decide which of the reports is the main one and thus has the best description of the problem? Or how would it detect additional information present in a duplicate and copy that into the main one? IMHO a software like that should not automatically decide to do things, at most it could be tool for triagers to help them discover candidates. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Sun, Oct 2, 2011 at 1:08 PM, Kevin Krammer wrote: > On Saturday, 2011-10-01, Joshua Blocher wrote: >> I think we are acting like it all has to be done manually which is >> simply not true. Why are we tackling bug triage as something that only >> a human can do? > > Because it potentially requires interpretation of natural language text, > understanding of relations between concepts and ideally the ability to combine > those to reproduce the problem. Maybe at the very least it could be used to find likely duplicate backtraces. Currently drkonqi asks that you submit a new bug report if you aren't certain that your backtrace is identical to an existing one (which most users would not be able to do). If it could compare backtraces and identify likely matches hopefully this could cut down a lot on the number of duplicate crash reports. -Todd >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Re: Bug triage process needs help
On Sunday 02 October 2011 13:38:56 todd rme wrote: > On Sun, Oct 2, 2011 at 1:08 PM, Kevin Krammer wrote: > > On Saturday, 2011-10-01, Joshua Blocher wrote: > >> I think we are acting like it all has to be done manually which is > >> simply not true. Why are we tackling bug triage as something that only > >> a human can do? > > > > Because it potentially requires interpretation of natural language text, > > understanding of relations between concepts and ideally the ability to > > combine > > those to reproduce the problem. > > Maybe at the very least it could be used to find likely duplicate > backtraces. Currently drkonqi asks that you submit a new bug report > if you aren't certain that your backtrace is identical to an existing > one (which most users would not be able to do). If it could compare > backtraces and identify likely matches hopefully this could cut down a > lot on the number of duplicate crash reports. The problem here is that DrKonqui asks. A user cannot interpret a backtrace and I cannot remember any case during the last year where DrKonqui found possible duplicates and the real one was not under them. DrKonqui should not allow to submit the backtrace if it finds possible duplicates. Cheers Martin > > -Todd > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
Am Sun, 02 Oct 2011 13:50:57 +0200 schrieb Martin Gräßlin : > DrKonqui should not allow to submit the backtrace if it finds > possible duplicates. +1 - in general :) However, remember the "mystery" bug, ie. the uncatched exception thrown from Qt's eventloop because of the invalid nvidia error log size return in the lanczos filter? w/o all the dupes we might have just concluded "heisenbug" and never understood or (hopefully ;-) fixed it. -> "DrKonqui should not submit pot. dupes for bugs with a regular backtrace, but everything that ends up in some sort of memory corruption." Cheers, Thomas >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On 2011-10-02, Kevin Krammer wrote: > Interesting. So do other projects ship bug fixes without patch level releas= > e or=20 > do the not ship bug fixes at all? At least in debian, for stable updates it is only for very serious issues there are shipped updates in stable releases, among other things because 'non-changing' is also part of 'stability'. In many pieces of 'deployed software' you as a user or integrator or sysadm have deployed workarounds for known bugs, and fixing them might actually introduce new issues because of the workarounds. But this might also be primarily for 'server components' this is important. /Sune >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
Hi Rui, On Sat, Oct 1, 2011 at 23:20, Rui Maciel wrote: > On 09/30/2011 03:03 PM, Myriam Schweingruber wrote: >> >> Well yes, it is feasible, provided the database is completely triaged >> and there are actual people doing the queries, as those need to be >> done by sentient beings. Of course we welcome all volunteer triagers >> to give a hand:) See also my previous post though. > > What do you mean by "completely triaged"? If I'm not mistaken, by default > KDE's bug tracker lists bug reports sorted by report ID, which is directly > proportional to how old a bug report is and therefore "how long they have > been unanswered". This means that if you run a search on KDE's bug tracker > for the bugs filed on a specific project, the first result that pops out by > default is already the report which has been left unaddressed the longest. > > > Rui Maciel The age of a bug doesn't tell anything about its importance. Especially regressions, which are more important due to there nature are usually much younger than old reports. Many old reports are also completely outdated, as they don't apply to the most recent version. One of the task of the bug triager is also to go over all older reports and check with the reporter if it is still valid in the most recent released version, or ideally in the git version. FWIW: most of those request from the triagers are simply ignored as we only rarely get feedback on those, another time waster in triaging. As a general rule, bug reports to the KDE bugtracker should always be only about the latest released version or the currently developed one, we don't do backports, that is up to the distributions to do so. Again, a matter of manpower. I just think that all the time we now have invested in this thread could have been better spent by everybody in bug triaging and/or coding, don't you all think the same? Regards, Myriam -- Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Sun, Oct 2, 2011 at 13:38, todd rme wrote: > On Sun, Oct 2, 2011 at 1:08 PM, Kevin Krammer wrote: >> On Saturday, 2011-10-01, Joshua Blocher wrote: >>> I think we are acting like it all has to be done manually which is >>> simply not true. Why are we tackling bug triage as something that only >>> a human can do? >> >> Because it potentially requires interpretation of natural language text, >> understanding of relations between concepts and ideally the ability to >> combine >> those to reproduce the problem. > > Maybe at the very least it could be used to find likely duplicate > backtraces. Currently drkonqi asks that you submit a new bug report > if you aren't certain that your backtrace is identical to an existing > one (which most users would not be able to do). If it could compare > backtraces and identify likely matches hopefully this could cut down a > lot on the number of duplicate crash reports. Oh but it does, and it puts the numbers of the possible duplicate at the end of the backtrace. IMHO those should be on top of the backtrace instead of being at the bottom, but even then, most users will just click submit without even caring to check. Currently bug reporting is far too easy as it doesn't request enough thinking from the reporter. Dr. Konqi can compare to a certain extend, but there are quite a few reports that seem duplicates because of identical lines at the start, but diverge further on in the CrashHandler. What I would love to see is Dr. Konqi prohibiting reports that don't have complete backtraces e.g. are not marked with 3 stars. Currently there are still far too many reports going through without proper backtraces because of missing debugging symbols. Regards, Myriam -- Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Sunday, October 02, 2011 16:14:18 Myriam Schweingruber wrote: > Many old reports are also > completely outdated, as they don't apply to the most recent version. I just respond to this, as this is very true. And one cause of why bug number keeps growing. If the developer keeps an eye on the bug list, or check from time to time them after a fixing bugs, then such old bugs would have been closed. When you work and find an bug that might affect more users, chances are that somebody reported at, so it worths to do a search in bugzilla and close those bugs. This will make both you (as the number of open bugs decreases) and the users happy (as they get feedback). Andras >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Bug triage process needs help
On Sunday, 2011-10-02, Sune Vuorela wrote: > On 2011-10-02, Kevin Krammer wrote: > > Interesting. So do other projects ship bug fixes without patch level > > releas= e or=20 > > do the not ship bug fixes at all? > > At least in debian, for stable updates it is only for very serious > issues there are shipped updates in stable releases, among other things > because 'non-changing' is also part of 'stability'. > > In many pieces of 'deployed software' you as a user or integrator > or sysadm have deployed workarounds for known bugs, and fixing them > might actually introduce new issues because of the workarounds. But this > might also be primarily for 'server components' this is important. Yes, of course. I consider Debian Stable to be what other distributions call LTS or Enterprise. Those have, as you explained, different goals, i.e. better have a known bug than a new unknown one. But I don't think this applies to each distributor's variant of intermediate releases in between "frozen-stable" releases, does it? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Updates in custom data engine broken
Moin moin,
I'm hacking on a Plasma::DataEngine which receives its data via a DBus
interface. updateSourceEvent() is thus uninteresting, all updates come
from DBus' propertiesChanged signal.
One of these properties ("Metadata") contains a QVariantMap which I
place in one dataengine source:
void DataEngine::fillMetadata(const QVariantMap& metadata)
{
const QString source = QLatin1String("metadata");
removeAllData(source);
QMapIterator iter(metadata);
while (iter.hasNext())
{
iter.next();
setData(source, iter.key(), iter.value());
}
}
Because the available metadata in different situations might not
consist of the same set of keys, removeAllData() clears the source
before filling it with new data. The function above is called both
from the propertiesChanged() slot and from the ctor to initialize the
source. Now when I look at this source in plasmaengineexplorer,
everything's fine until the propertiesChanged signal is delivered for
this property. After that, the source is shown empty in
plasmaengineexplorer when I update it, and that won't change in
further updates.
At first I thought that removeAllData() causes the confusion, so I
changed fillMetadata() like this:
void DataEngine::fillMetadata(const QVariantMap& metadata)
{
const QString source = QLatin1String("metadata");
foreach (const QString& key, query(source).keys() + metadata.keys())
setData(source, key, metadata.value(key));
}
But this causes the same behavior in plasmaengineexplorer. What am I
doing wrong?
Greetings
Stefan
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
