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

[Mark]

On Thu, Jun 21, 2012 at 5:43 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Thursday, June 21, 2012 16:13:32 Mark wrote:
>> 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.
>
> we don't WANT to, but we do.
>
> this is the "perfect is the enemy of good" problem. we could wait till
> everything is (close enough to) perfect .. and then never release. or release
> once every 3-4 years. which would become the same thing as never because the
> project would die.
>
> we don't cut out pieces as there would be almost nothing left over time, bugs
> would just get hidden not addressed, etc. etc.
>
> but we want to ship working things so we improve them on each iteration.
>
> hope that helps ...
>
>> To phrase it more clearly.
>> How do we deal with individual components that are completely broken?
>
> fix them.
>
> the effort spent in this thread could likely have fixed the kget issue.
>
>> How do we mark such issues in bugzilla?
>
> as critical bugs.
>
>> 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)
>
> i already answered that.
>
> --
> Aaron J. Seigo
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

Ahh right, that answers it.
Critical issues, but not release blockers.

Thank you for that, will mark those blockers as such. :)
Ignore my last mail.