Dnia czwartek, 3 kwietnia 2014 11:34:11 Robert Xu pisze: > 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. >
On my daily job i'm PM and my projects does not postpone, because i've been already fired long time ago :) Managing projects is choosing between what is more important: scope, timetable, CAPEX/OPEX, quality and risk In this game choosing one option means you loos another one, so what you can have is maximum two of them. From my experience, choosing timetable and scope gives best overall results, because you delivers only important things (so called MUST HAVE) and those who left (NICE TO HAVE) are good for new project starters. > > 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. > We are not Fedora, neither Mageia so we can't afford to have more manpower for fixing those. What are yout thoughts on https://issues.openmandriva.org/show_bug.cgi?id=562 There are not kernel debug output, nothing suspicious in systemlogs. Do you have any ideas how to trace the real problem there, and where to fix this? Be my guest. Waving with magic wand won't solve this. > > 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. So why you do not respect plan with which you and all of use have approved? -- Cheers TPG
signature.asc
Description: This is a digitally signed message part.
