On Fri, Jun 22, 2012 at 3:49 PM, Myriam Schweingruber <myr...@kde.org> wrote: > Hi Mark, > > On Fri, Jun 22, 2012 at 4:26 PM, Mark <mark...@gmail.com> wrote: >> On Fri, Jun 22, 2012 at 3:11 PM, Myriam Schweingruber <myr...@kde.org> wrote: >>> Hi Thijs, >>> >>> On Fri, Jun 22, 2012 at 10:22 AM, Thijs Heus >>> <thijs22nos...@googlemail.com> wrote: >>>> Hi Martin, >>>> >>> ... >>>> My personal opinion, which counts for nothing: BKO can only work with less >>>> than 50 bugs or so per component. So be rigurous. BKO can only work as a >>>> developers tool if the developers want to use it, if they can have >>>> developers discussions within the report (like KWin does, or telepathy). >>>> The >>>> difference is that Plasma got almost 1400 bug reports in the past half year >>>> more than 10% of all of KDE, not even counting the bugs that ended up being >>>> redirected to nepomuk, kwin, solid, etc. Currently there are ~800 bugs >>>> open, >>>> my guess would be about 500 real bugs in a current version. That makes a >>>> bug >>>> overturn time of only 2 or 3 months. >>>> These are impressive numbers, and they show that Plasma is doing OK in >>>> beating the bugs, even though plasma may not yet be doing OK in beating >>>> BKO. >>>> So should we really keep minor bugs that will never be fixed unless as >>>> colleteral damage open? Crashes of over a year old, without any duplicate >>>> since? I am not saying that these are no bugs, just that they are not >>>> helpful reports (anymore), and thus pollute the database. For a highly >>>> visible project like plasma, the amount of eyeballs is so high that an >>>> accidentally closed bug will be reported again. Currently, this is working >>>> against us, but we could make it work a bit more in our favor if we want >>>> to. >>> >>> I agree with most of your points here, but what we really should avoid >>> is closing reports without any comments, that should never happen, and >>> sadly it did in the past and that is something that only causes anger >>> from the bug reporters >>> >>> As for the current bugs it is crucial that all incoming reports are >>> triaged ASAP. We can hold a bugsprint to tackle the remaining >>> duplicates and close old ones, but what counts are the bugs that are >>> reported now. If we continue to ignore those the b.k.o situation will >>> not improve. >>> >>> I have in mind an initiative similar to what Ubuntu does with their >>> "Five a day": https://wiki.ubuntu.com/5-A-Day >> >> Five bugs a day is a dayjob :p Considering that one bug can often take >> a full day (in time) from start to finish. Now i'm only talking about >> real bugs that are indeed confimed, hunted down to the part that >> causes the bug and making a fix for it. Placing it in reviewboard >> takes a few days as well. > > Wait, you misunderstood: I talk about triaging, not about fixing :) > Triaging one bug is a matter of minutes most of the time. Example: an > incoming crash report: check if there is a backtrace, identify the > FunctionCall that is most likely to cause the crash, search for > duplicates, try to reproduce if no dupes are around. Since 90% of the > bug reports at least are probably already reported this only rarely > involves reproducing > > ... >> The thing i hate when i look in bugzilla in the plasma bugs is the >> amount of ancient old bugs even before the KDE 4 time. I > > Erm, we had Plasma in KDE3? Also, when did you last have a look at > Bugzilla for Plasma bugs? Your comment makes me think of "not since a > long time".
Plasma (now) encompasses everything inside KDE-Workspaces, it's the "plasma-workspace". So when people say Plasma, they're not always talking about the part in bugzilla titled "plasma", which relates only to the "plasma-shell". It's somewhat confusing right now. This very recent wiki page might help: http://community.kde.org/Plasma/Terminology Dave > > Regards, Myriam > -- > Proud member of the Amarok and KDE Community > 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) > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
