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.

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.

Cheers,

-- Pavel

2017-01-30 14:07 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:

For example:
19457 Scrolling Versionner configuration list is very slow
18778 FileList "View as" does not work
19221 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