On 3 April 2014 09:30, Tomasz Gajc <[email protected]> wrote: > Short resume of these so called Blockers: > Bug 562 - only TWO people confirmed this issue. There is no debug no > nothing, only hunch. > Bug 615 - Closed as a duplicate of 307 - as Denis Silakov suggested this > bootloader settings should be dropped in favour of providing kcm-grub2 > Bug 613 - it is not a blocker - just major ! > Bug 422 - filled against beta - looks like no one ever tested it agains RC1 > candidate... > Bug 424 - it is just a warning that is shown for a user
Hi Tomasz, IIRC you asked QA to bring a definite list of blockers for RC, and IIRC these were among them. So Colin felt the need to block this release because of those bugs. > > We can not postpone all the time, because this looks higly unprofessional. > EFI support topic is closed, and we should not waste time on fining it for > 2014.0 because we do not even have time, not to mention man power to fix > this so called blocker list of bugs. What? Projects postpone all the time due to issues like these. Excessive postponing is not good, but I see no harm in postponing a week. In fact, you wanted to do that until we resolved the booting issues - so now we should do it to fix these bugs. > > A real solution needs to be found for this situation, as i said already > postponing again will make Asso and Community looks highly unproffesional. > These bugs are not blocking booting process or using KDE by "daily linux" > user . Yet it's these subtle bugs that leave a bad impression. Tools that don't work as they should are considered unprofessional. > > Please take a look at rosa bugzilla, they have more opened bugs than we > have, not to mention that severity of them are quite huge. With current > manpower we can not cope with a organized company, and yet release is > blocked. > Looks like not obeying dates on release plan will lead to anarchy very soon. Your dates have nothing to do with our QA GO/NOGO. We take very little into consideration about the proposed release date, and focus more on stability and usage, especially with RC and final releases. -- cheers, Robert :: protocol.by/rxu
