On Thu, Jun 21, 2012 at 4:44 PM, Jeremy Whiting <jpwhit...@kde.org> wrote: > On Thu, Jun 21, 2012 at 8:13 AM, Mark <mark...@gmail.com> wrote: >> On Thu, Jun 21, 2012 at 11:20 AM, Aaron J. Seigo <ase...@kde.org> wrote: >>> On Wednesday, June 20, 2012 22:15:35 Mark wrote: >>>> To me the definition of a regression is as follows: >>>> A regression is an issue that wasn't in the previous release. >>> >>> that would describe all new bugs ;) >>> >>> a regression is something that worked properly (for whatever that means in >>> the >>> given situation) in a previous release and then ceased to do so. >>> >>>> Things get a bit more complicated with adding the "release_blocker" >>>> keyword. When do you add that keyword to a bug? >>> >>> data loss, a bug that renders the entire application unusable for the >>> intended >>> primary use cases, .. it's a very serious situation. >>> >>> if in doubt -> ask on the list. >>> >>>> 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. >>> >>> this is not a release blocker. why? because: >>> >>> * it is an optional component, critical to neither the use of kget nor >>> plasma >>> desktop >>> >>> * it does not cause data loss >>> >>> * it does not render the system generally inoperable >>> >>> it is a rendering issue. it's also a component that ships with kget and >>> maintained by the kget developers so it should be assigned to kget in >>> bugzilla >>> (already done this). >>> >>> it is not, however, a release blocker. it's something the kget developers, >>> or >>> someone who feels motivated to help them out :), need to fix. >>> >>>> 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. >>> >>> not when they are this minor, no. >> >> True and i completely agree with it. >> But this doesn't make it any easier. Marco said (above): "i don't >> think we should make releases with random pieces cutted out, or they >> will never be complete" so we don't cut out pieces that don't work yet >> we also don't want to release pieces that don't work. > > Nobody said we don't want to release pieces that don't work. We do > release pieces that don't work. Then those bugs are much more visible > and developers (hopefully) have more motivation to fix them. :) > > Just my 2c, > Jeremy >
Ehhh, that's a very strange reasoning :p That way you could release a completely broken KDE SC (like KDE 4.0 was ;p) then developers will certainly be motivated to fix it asap. That is bad publicity for KDE and a bad KDE image that you should never want to have. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
