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

[Aaron J. Seigo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120621/dfe053f0/attachment.sig>