On Thu, Jun 21, 2012 at 5:43 PM, Aaron J. Seigo <ase...@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@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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
