The new 'cloud' rendering of all tags on https://bugs.edge.launchpad.net/inkscape shows a total of 287 used tags. Are there any guidelines to follow when adding or renaming tags besides the visible 'official' and 'other' tags of the default interface on https://bugs.launchpad.net/inkscape?
Is there a more suitable place to ask/discuss questions like this about the bug tracker and bug triage?
tia, ~suv
Thanks for starting this. I've felt tempted to do it myself but time constrains wouldn't allow me. My duty as a member of the bug tracker has been to use the most common and coherent tags for new and old bug reports. I tried to prune unnecessary tags, like those which only pointed to one or two bugs, or when there was already another similar tag in use. I think tags give a good all-around look of where the most common bugs are.
Now, I've some suggestions: - There exists the tag 'other'. I suggest to get rid of it and try to categorize those bugs with better, more descriptive tags. I think this is doable for many bugs there. - We've right now the tags 'importing', 'exporting', 'export' and 'import-export'. Should we simplify this? I think, at least, 'export' should be converted to 'exporting', as there is 'importing' already. - Looking at the tag cloud, I see there are a lot of one-bug tags. These can be easily categorized with better tags. - I don't know what's the policy for platform or architecture specific bugs. For instance: I see some bugs marked with 'linux' or 'amd64' tags where there wasn't a proved connection between the architecture or OS and the bug itself. I think those tags should be used only when there is a positive proof that the bug is platform/architecture specific. - Maybe some new tags should be added to the official list, like 'tablet' or 'color'.
That's all I remember right now.
Regards.
2009/9/22 ~suv <suv-sf@...58...>:
The new 'cloud' rendering of all tags on https://bugs.edge.launchpad.net/inkscape shows a total of 287 used tags. Are there any guidelines to follow when adding or renaming tags besides the visible 'official' and 'other' tags of the default interface on https://bugs.launchpad.net/inkscape?
Is there a more suitable place to ask/discuss questions like this about the bug tracker and bug triage?
tia, ~suv
More points:
1) I searched for tags with the wildcard -*, which means "search for bugs without tags". Turns out there are 1032, many of them recent. I think these should be tagged because right now they're in no man's land. The number of 'pdf', 'ui', 'livepatheffects'... tagged bugs might grow considerably.
2) There are some tags like 'ui-text' that should be converted to 'ui text'. I think it's better that way because Launchpad's search already allows searching for multiple tags at once, while keeping them separate as 'text' and 'ui' at the same time. There are others like 'ui-toolbars-whatever' which are already covered by the broad tag 'ui'. My opinion is that this case should be simplified.
3) The tag 'bitmap' should be made official and used more extensively.
BTW, Launchpad was updated yesterday and the tag cloud is showing for everyone but, where are the official tags?
Regards.
On 24/9/09 18:35, Pajarico wrote:
BTW, Launchpad was updated yesterday and the tag cloud is showing for everyone but, where are the official tags?
here is the complete tag list from 2009-09-22, before 'they' shortened it back to the current state (whatever the criteria now are). Many single bug tags have already been changed since. Any way such a list could be made accessible (e.g. on a wiki page) and regularly updated? At the moment it seems unclear what and where the 'official' and 'other' list (as they were called in the previous launchpad version) are kept.
hth, ~suv
tags-list 2009-09-22 https://bugs.edge.launchpad.net/inkscape
2geom 3d 3dbox 64-bit accessibility aim all-platforms alpha amd64 angle angular apport-bug apport-collected apport-crash arabic automation autosave axonometric bezier bidi bitmap blur bsd build build-compile-code-design cairo calligraphy cdr centre chameleon clipboard clipping clipping-path clone clones closepath color compiz cone conic connectors content coordinates copy copy-paste craah crash creating css cyrillic declaration defs desktop-integration dia dialogs displaced display distort document-properties documentation dxf effects emf eps erase eraser evince expand export exporting extension extensions extensions-plugins feature fill filters-svg fit fit-page-to-selection focus font fonts free freehand freeze full fullscreen gamma gnome gnuplot gradient grid grids group grouped grouping gsoc2009-color guides hand help history href http icons image imagemagick import import-export importing inkboard inkscape installer internet invisible-layer java kern keyboard keys landscape latex layer layers licence ligature ligatures line-height link linux list livepatheffects load localisation locking logo lpe mac macosx management marker markers maximize maximum memory menu metadata motif mouse needs-confirm-on-svn-head netbook node node-editing nodes non-grouped object object-shape object-text object-to-pattern objects objects-freehand-calligraphic objects-gradients objects-markers objects-nodes objects-pattern odg on opacity openclipart orientation ornemantal osx other oversampling packaging page paper paste patch path pattern pdf pdf-import pencil performance perspective planes png poppler portable position positioning preview print printing problem process proxy ps psfrag python quality radial-gradient-fill radialgradient reference regression remember remove render renderer request resize restore romanian rotation rulers save saving script scripts select selection serbian shape-editing single-dots size slider slovenian snapping snapshot soc-2008-juca solaris solarize sparse spiral spiro stamp stroke stroke-width style styles svg svg-xml symmetry tablet text text-tool tiled-clones tool tools transformations translation translation-geometry transparency tutorials ubuntu ui ui-dialogs-toolbars ui-guide-grid-ruler ui-palette-color ui-preferences ui-preview ui-selection-group-layer ui-shortcuts ui-text ui-xml undo unexpected-error ungroup usability usb value version vertical viewbox vista vml website wiki win32 win32-vista window wishlist with wmf x11 xaml xlink xmleditor zoom
I agree. We should start using it extensively. There are many bugs like that. Don't forget about problems with many fonts installed!
I would ask you to reply to the mailing list thread instead of personally. That way everyone can read it.
Regards.
2009/9/27 ~suv <suv-sf@...58...>:
What do you think about using the tag 'performance' more often? It does exist (currently only 2 bugs) and there have been an increasing number of bug reports about lack of performance with e.g.
- many filters
- big files (specially maps)
- imported ai-files (nested groups with transparency)
- on OS X: slow screen redrawing under X11
- slow file dialog opening with many files
- ...
In the thread about the roadmap for 0.48 on the mailing list this issue was discussed as well: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31350
~suv
One more tag that I would like for us to use, and will be tagging a bug with it right now, is "blocker". By the way, if you feel the tag should change to a different name feel free to do so. To me, having a tag for release blocker bugs will reduce the need for having to search emails and for people to repeat themselves to know which blocker bugs still stand.
Cheers, Josh
On Sun, 2009-09-27 at 19:30 +0200, Pajarico wrote:
I agree. We should start using it extensively. There are many bugs like that. Don't forget about problems with many fonts installed!
I would ask you to reply to the mailing list thread instead of personally. That way everyone can read it.
Regards.
2009/9/27 ~suv <suv-sf@...58...>:
What do you think about using the tag 'performance' more often? It does exist (currently only 2 bugs) and there have been an increasing number of bug reports about lack of performance with e.g.
- many filters
- big files (specially maps)
- imported ai-files (nested groups with transparency)
- on OS X: slow screen redrawing under X11
- slow file dialog opening with many files
- ...
In the thread about the roadmap for 0.48 on the mailing list this issue was discussed as well: http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31350
~suv
Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
~suv: I've been using the performance tag. I think all the old bugs are already categorized (at the time there are 31).
J.A. Andler: I will keep an eye on bugs mentioned on the mailing list.
Regards.
On 24/9/09 18:35, Pajarico wrote:
- I searched for tags with the wildcard -*, which means "search for
bugs without tags". Turns out there are 1032, many of them recent. I think these should be tagged because right now they're in no man's land. The number of 'pdf', 'ui', 'livepatheffects'... tagged bugs might grow considerably.
As you mention 'pdf':
question about _filetypes_: should we use the file extensions as tags or delete them in general and only keep an agreed-upon subset of major ones like 'pdf' and 'eps' ('ps')? At the moment I'd favour to always add them as separate tag when relevant.
question about importing/exporting/import-export and _extensions/plugins_: many of the import-export bug reports are related to (python) extensions or their helper applications - how to tag these bugs? Always add both im/ex and ext-pl plus the filetype?
[ Background of above questions: there have recently been several (?) bug reports about importing failures (cdr, 0.47pre) that are really _UniConverter_ bugs. On windows, UniConverter is part of the Inkscape package - who is now responsible for handling the bug reports? How to tag them? ]
BTW, Launchpad was updated yesterday and the tag cloud is showing for everyone but, where are the official tags?
The criteria for a tag to appear in the cloud remain mysterious ;-)
From looking at google search results for launchpad bugs I gather that
previous Launchpad versions did allow to search for partial tags like 'ui-*' or 'objects-*'. These kind of queries are not possible with the current Launchpad 3.0 advanced bug search (at least I could not figure out how ;-). AFAIU that means that only _fully known_ tags are now useful for bug management. It would be convenient if we had a way to query the launchpad inkscape bug database for all used tags and keep an updated list as reference somewhere on launchpad or the wiki.
Does anybody from the Inkscape bug team have more insight what is/isn't possible within the (somewhat) limited tools Launchpad 3.0 offers for the bug tracker? (yes, I'm critical because I don't understand their priorities for launching v3.0 with gimmicks like in-page-editing of summary etc. but at the same time removing tools like 'bug activity' - at least I can't find it anymore. Do members of the bug team have a different set of tools when logged in?)
~suv
~suv: I haven't forgotten about your reply, I didn't have time to think about it.
question about _filetypes_: should we use the file extensions as tags or delete them in general and only keep an agreed-upon subset of major ones like 'pdf' and 'eps' ('ps')? At the moment I'd favour to always add them as separate tag when relevant.
I think we should use the major ones. But then there are tags like 'javafx' (1 bug only), what to do with those??. There was 'cdr' too (it is part of UniConvertor, not Inkscape). Let's leave UniConvertor formats (like cdr) to the tag 'uniconvertor'. The problem that might happen is when a bug is not in uniconvertor but in the extension that manages it. In that case we could use tags 'extensions-plugins' (or 'import-export'/'exporting'/'importing', see next point).
question about importing/exporting/import-export and _extensions/plugins_: many of the import-export bug reports are related to (python) extensions or their helper applications - how to tag these bugs? Always add both im/ex and ext-pl plus the filetype?
I always use 'extensions-plugins' for bugs related to the Extensions menu only. I see your point since some file filters are based on python proxy scripts. Which is better?: * Use 'extensions-plugins' only for Extensions; index reports with a tag related to the file format: pdf, eps, emf, uniconvertor... accompanied by 'import-export', 'exporting' or 'importing'. * Use 'extensions-plugins' for both Extensions and import/export formats based on scripts.
I'm unsure. It seems clearer to me to use the first method.
[ Background of above questions: there have recently been several (?) bug reports about importing failures (cdr, 0.47pre) that are really _UniConverter_ bugs. On windows, UniConverter is part of the Inkscape package - who is now responsible for handling the bug reports? How to tag them? ]
See above.
I see you started using the tag renderer. I will make some searches and add to that category.
Regards.
On 12/10/09 22:38, Pajarico wrote:
- Use 'extensions-plugins' only for Extensions; index reports with a
tag related to the file format: pdf, eps, emf, uniconvertor... accompanied by 'import-export', 'exporting' or 'importing'.
agreed - much clearer this way!
I see you started using the tag renderer. I will make some searches and add to that category.
I found it in a number of older confirmed bugs - it seems to me an important module of Inkscape and a good tag for reports about visual glitches e.g. when rendering complex paths. Do you know how much of it already falls into 'cairo' or is this transition still on-going?
btw - trying to keep track of known used (and missing) tags here: http://wiki.inkscape.org/wiki/index.php/User:~suv#bug_tracker:_tags - maybe this could turn into its own page?
~suv
On 12/10/09 22:38, Pajarico wrote:
On 6/10/09 07:38, ~suv wrote:
question about _filetypes_: should we use the file extensions as tags or delete them in general and only keep an agreed-upon subset of major ones like 'pdf' and 'eps' ('ps')? At the moment I'd favour to always add them as separate tag when relevant.
I think we should use the major ones. But then there are tags like 'javafx' (1 bug only), what to do with those??.
javafx: new internal extension, suggest to keep as tag http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/31574
There was 'cdr' too (it is part of UniConvertor, not Inkscape). Let's leave UniConvertor formats (like cdr) to the tag 'uniconvertor'.
UniConverter is currently used for input: ccx, cdr, cdt, cgm, cmx, plt, sk1, wmf output: plt, sk1, wmf
I just checked the UniConverter website - they have a link to their bug tracker on launchpad which could make it easier to link Inkscape export bug reports to https://bugs.launchpad.net/uniconvertor/. However the launchpad UniConverter project doesn't seem to be used at all. There's still the 'sK1 Project - Support Forum: UniConvertor bugreports' at http://sk1project.org/forum/viewforum.php?forum_id=6 which has more recent activity. Should we mark uniconvertor bugs as 'Invalid' and refer to the sK1 website?
~suv
UniConverter is currently used for input: ccx, cdr, cdt, cgm, cmx, plt, sk1, wmf output: plt, sk1, wmf
Oh, I thought wmf was internal. That's why I used it on my example on my previous post.
I just checked the UniConverter website - they have a link to their bug tracker on launchpad which could make it easier to link Inkscape export bug reports to https://bugs.launchpad.net/uniconvertor/. However the launchpad UniConverter project doesn't seem to be used at all. There's still the 'sK1 Project - Support Forum: UniConvertor bugreports' at http://sk1project.org/forum/viewforum.php?forum_id=6 which has more recent activity. Should we mark uniconvertor bugs as 'Invalid' and refer to the sK1 website?
~suv
I would drop a letter to UniConvertor developers suggesting them to use the bug tracker at Launchpad more (best solution) or inviting them to take a look at the 'uniconvertor' tag in our Launchpad's section now and then. The forum they're using would force us to get an account and forums are not the best way to manage bugs anyway (no duplicates, status, patches, attachments...)
The first step is to tag bugs with 'uniconvertor' and see how many of them there are. At first I'm going to tag them without removing any previous tag.Then will write a letter to UniConvertor authors exposing them the situation. But that will be in some hours, I've yet to take my bike from the repairman (who hadn't good news...)
Regards.
On 13/10/09 10:23, Pajarico wrote:
UniConverter is currently used for input: ccx, cdr, cdt, cgm, cmx, plt, sk1, wmf output: plt, sk1, wmf
Oh, I thought wmf was internal. That's why I used it on my example on my previous post.
oops - my fault - looks like wmf support on win32 is internal... else based on UniConverter (share/extensions/wmf_*put.inx):
current internal extensions (r22457 src/extension/internal/*.cpp): org.inkscape.effect.bluredge org.inkscape.output.png.cairo org.inkscape.output.pdf.cairorenderer org.inkscape.input.emf.win32 org.inkscape.input.wmf.win32 org.inkscape.output.emf.win32 org.inkscape.print.emf.win32 org.inkscape.input.gdkpixbuf.%s org.inkscape.input.gimpgrad org.inkscape.effect.grid org.inkscape.output.jfx org.inkscape.output.latex org.inkscape.output.odf org.inkscape.input.pdf org.inkscape.output.pov org.inkscape.input.wpg
and input/output/print (r22457 'src/extension/extension.h'): SP_MODULE_KEY_INPUT_SVG "org.inkscape.input.svg" SP_MODULE_KEY_INPUT_SVGZ "org.inkscape.input.svgz" SP_MODULE_KEY_OUTPUT_SVG "org.inkscape.output.svg.plain" SP_MODULE_KEY_OUTPUT_SVGZ "org.inkscape.output.svgz.plain" SP_MODULE_KEY_OUTPUT_SVG_INKSCAPE "org.inkscape.output.svg.inkscape" SP_MODULE_KEY_OUTPUT_SVGZ_INKSCAPE "org.inkscape.output.svgz.inkscape" SP_MODULE_KEY_PRINT_PS "org.inkscape.print.ps" SP_MODULE_KEY_PRINT_CAIRO_PS "org.inkscape.print.ps.cairo" SP_MODULE_KEY_PRINT_CAIRO_EPS "org.inkscape.print.eps.cairo" SP_MODULE_KEY_PRINT_PDF "org.inkscape.print.pdf" SP_MODULE_KEY_PRINT_CAIRO_PDF "org.inkscape.print.pdf.cairo" SP_MODULE_KEY_PRINT_LATEX "org.inkscape.print.latex" SP_MODULE_KEY_PRINT_GNOME "org.inkscape.print.gnome" SP_MODULE_KEY_PRINT_WIN32 "org.inkscape.print.win32"
But that will be in some hours, I've yet to take my bike from the repairman (who hadn't good news...)
:(
On 13/10/09 10:23, Pajarico wrote:
I would drop a letter to UniConvertor developers suggesting them to use the bug tracker at Launchpad more (best solution) or inviting them to take a look at the 'uniconvertor' tag in our Launchpad's section now and then. The forum they're using would force us to get an account and forums are not the best way to manage bugs anyway (no duplicates, status, patches, attachments...)
The sK1 project on https://launchpad.net/sk1 has recent activity, and its maintainer https://launchpad.net/~igor-e-novikov has commented on Inkscape/UniConverter bug reports before (see bug #387946 https://bugs.launchpad.net/inkscape/+bug/387946).
2009/10/25 Pajarico <pajarico@...400...>:
Wouldn't it be better to use a more descriptive name? Frankly, if I hadn't read this email I'd have no clue what it is supposed to mean.
Max
CLI is an often used acronym for Command Line Interface. This expansion comes up in a Google search and is the first item on Wikipedia's 'CLI' disambiguation page. I think it's OK, especially since the tags are mainly useful for developers, who are likely to know this acronym.
Regards, Krzysztof
-----Original Message----- From: Maximilian Albert [mailto:maximilian.albert@...1439...] Sent: zondag 25 oktober 2009 18:44 To: Pajarico Cc: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] [bug tracker] Guideslines for tags?
2009/10/25 Pajarico <pajarico@...400...>:
I started using the tag 'cli' for command line problems.
Wouldn't it be better to use a more descriptive name? Frankly, if I hadn't read this email I'd have no clue what it is supposed to mean.
I agree with Max. Just write it out "command line", like we do with the other tags. (I read it as "clear interrupts" assembly ;)
Cheers, Johan
participants (6)
-
unknown＠example.com -
Joshua A. Andler -
Krzysztof Kosiński -
Maximilian Albert -
Pajarico -
~suv