When should a bug be considered as a regression or a release_blocker?

[Mark]

On Thu, Jun 21, 2012 at 11:20 AM, Aaron J. Seigo <aseigo at 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.

If you follow that reasoning it is... a blocker :p

To phrase it more clearly.
How do we deal with individual components that are completely broken?
How do we mark such issues in bugzilla? And how does the release team
handle those issues if they are still completely broken once a new KDE
SC is about to be released? (not a beta or rc, but final release)

>
>> 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.
>
> we could find such a bug in probably almost every single application in the SC
> :)
>
> --
> Aaron J. Seigo
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>