On 2013-12-02 23:49 +0100, Bryce Harrington wrote:
On Mon, Dec 02, 2013 at 03:08:33PM +0100, su_v wrote:
> On 2013-12-02 08:20 +0100, Bryce Harrington wrote:
>> Thanks. Josh and I will get a task list together this week. Sounds
>> like in the meantime the priority is getting regression bugs analyzed
>> and resolved. If we haven't already we'll need a burndown list of those
>> bugs.
>
> <
http://sourceforge.net/mailarchive/message.php?msg_id=31423493>
Pasting the link from that earlier message: List of reports tagged with
'regression' and milestoned to '0.49', sorted by 'newest first':
<
http://tinyurl.com/o9lq44w>
suv, I notice the subject of the referenced email is
"Non-blockers";
does that imply that the bugs in this list are not deemed to be release
blockers? If that's true, then do we have a shortlist of blocking bugs,
or have those all been resolved already?
I didn't choose that thread topic myself… Personally, I think that many
(if not most) of the so far known regressions introduced in trunk need
to (or ought to) be fixed before a new stable release branch is created.
AFAICT the impacts of the recent large merges have not been fully
addressed yet (e.g. units, C++ification), and there are a couple of
performance, units and precision regressions which would likely affect
many users. TBH I somewhat lost track of the current state of ellipse
and circle elements (both internally, and what is exposed to the user).
Reports which currently have an explicit 'blocker' status (i.e. have the
tag 'blocker' added) are listed here (they are excluded from the other
search):
<
https://bugs.launchpad.net/inkscape/+bugs/?field.tag=blocker>
Also, I see that some good thinking has gone into setting priorities
for
pretty much all of these bugs, and only a handful are marked High. suv,
do you have an opinion on how we should treat the bug priorities for the
release? I.e., should we focus heaviest on getting the High priority
bugs closed, and not really worry about the low priority ones? Or
should priority be interpreted in some other fashion?
Maybe we had been too technically minded in the past when assigning the
priorities, roughly based on these criteria:
- high: all crashes (unless they occur under very rare circumstances),
bugs with the risk of data loos
- medium: severe bugs for which workarounds are known,
bugs which produce incorrect or unxepected results
- low: only occur under rare circumstances,
or can be easily worked around,
GUI regressions
The statuses do not (or rarely) reflect the impact on usability or the
bug's level of 'annoyance'.
Personally, I had stopped tagging additional reports as 'blocker' a
couple of weeks ago (except for two reports, very recently) - it would
be great if someone could help with that task (for one thing I do find
it rather difficult to decide, after having read too many reactions from
bug reporters disagreeing about how bugs have been triaged, and for
another thing I don't really like having to decide that for reports I
filed myself).
@JazzyNico - what's your view?
Regards, V