Hi, Yesterday i was looking over quite a few plasma bugs and noticed a lot of bug being filled at the new QML components. I marked most of them as regressions since they looked like regressions to me.
To me the definition of a regression is as follows: A regression is an issue that wasn't in the previous release. Things get a bit more complicated with adding the "release_blocker" keyword. When do you add that keyword to a bug? Thus far i considered a bug a "release_blocker" if the issue means that the item is unusable or causing loss of data. For example https://bugs.kde.org/show_bug.cgi?id=301854. It's a very innocent plasmoid, but it's unusable on multiscreen environments thus i marked it as a release blocker. Another example is https://bugs.kde.org/show_bug.cgi?id=301854, that bug described the KGet Piechart applet as being broken. I tested that and verified that it indeed is completely broken and even renders outside it's applet space. So i marked that one as release blocker as well because it's useless in it's current state. Both issues are not something that obstruct normal KDE usage, but they do render some parts of KDE completely useless. I'm a bit unsure if i should mark such bugs as release blockers. Perhaps there should be a keyword called "component_blocker" indicating that a specific component (specified in the component field on bugzilla) is not fit to be shipped with the release. I would like to have some clarification on when something should be marked as a release blocker. So perhaps we can draft up a general guideline for the conditions that justify a bug being marked as release_blocker. Kind regards, Mark _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel