2017-01-30 15:23 GMT+01:00 Pavel Krivanek <[email protected]>:
> Hi Nicolai, > > I'm checking all current issues marked for Pharo 6 and testing if they are > new or the problem already existed in Pharo 5. According to it I'm marking > it and for most cases (but not all) I'm decreasing the priority to "Fix if > Time". > I understand you but look at the priorities as priorities for the > releasing process. Of course a lot such issues should be fixed and if you > think they must be fixed for the upcoming release, increase the priority. > Currently the assignment of priorities is on issue reporters and they use > different personal scales. This way we can unify that a little bit. > > After finishing of the marking I wanted to ask people to think again about > priorities of the reported issues. But If we already made a release with > some issue, it probably means it is not extremely important. > I am not talking about "extremely important" issues. If it is an issue that "must be fixed for this release", I would use the "show stopper" priority. Now if some uses used his time to report an issue, say one as priority "fix if time" and another one "must fix", now we put all this issues to "fix if time", don't you think we loose some valuable information ? If this issues won't be fixed in this release (because we don't have enough man power) we can always put them on "Later" instead of "Pharo 6.0" For me, it makes a difference if some issues occure in some situations, where we can maybe work around, and can be fixed "if time" or if an issues is a bug that must be fixed just because the functionality is just not working anymore. > > This step needs to be done anyway or we will never finish the release. To > do it now gives us more time to focus on really important things. We want > every new release to be better that release before so it makes sense to > firstly look at new problems we created. > I don't get this point. Some issues were just introduced in the pharo 5.0. So instead of seeing this issues as "must fix", we decrease the priority as "fix if time", so we can focus on the issues we introduced in Pharo 6.0? > Cheers, > -- Pavel > > > 2017-01-30 14:07 GMT+01:00 Nicolai Hess <[email protected]>: > >> For example: >> 19457 >> <https://pharo.fogbugz.com/f/cases/19457/Scrolling-Versionner-configuration-list-is-very-slow> >> Scrolling Versionner configuration list is very slow >> 18778 >> <https://pharo.fogbugz.com/f/cases/18778/FileList-View-as-does-not-work> >> FileList "View as" does not work >> 19221 >> <https://pharo.fogbugz.com/f/cases/19221/Rub-Find-And-Replace-can-not-search-for> >> Rub Find And Replace can not search for "?" >> >> For me, these are issues that "must fix" and not "Fix If Time". Most >> issues are only >> fixed "if someone has the time to do it" regardless how serious they are. >> Fixed if time looks like , we can live without this as we did since the >> last >> release, but actually we are just used to accept some bugs and >> regressions because >> we know we are to small or to few develoeper to actually fix this issues. >> I don't see any value in downgrading the priority - else we could just >> discard any priority. >> >> >> nicolai >> > >
