[Libreoffice-qa] [LibreOffice Bugzilla Migration] We're done! Please visit the new site to reset your password!
mstahl at redhat.com
Tue Jan 27 04:38:57 PST 2015
On 27.01.2015 08:12, Robinson Tryon wrote:
> On Tue, Jan 27, 2015 at 1:20 AM, Tommy <barta at quipo.it> wrote:
>> +1. we really need to remove a lot of those useless keywords
> Here's the current list of keywords:
> ALL: What should go?
> bisected (255)
> The bug has been successfully connected to a code commit that
> introduced the bug (such as with "git bisect").
> bisect_pending (0)
> The bug seems likely to benefit from bisecting, (such as easy to
> reproduce, etc.), but the bisect has not yet been performed. See also
> the "bisected" keyword.
this sounds similar to BibisectRequest - which one to keep?
> cleanup0407 (2)
> April 2007 bug cleanup.
> have-backtrace (232)
> bugs that have a useful backtrace
> i18n (26)
> Xorg Internationalisation issues (i18n)
sounds potentially useful, we don't have a "component" with similar
scope (but if we keep it the description needs to remove "Xorg" and it
should be merged with "l10" as they seem very similar)
> janitor (9)
> Cleanup bugs, usually trivial.
sounds like EasyHack? DELETE
> l10n (51)
> Xorg/X11 Localisation issues
see "i18n" above
> licence (2)
> Files with licence problems (e.g. mixing incompatible licences,
> missing/non-permissive copyrights, et al)
not sure if we want this, best to get BoD's opinion on that...
> love (8)
> Marking a bug with this keyword means that you're willing to help
> someone fix the bug, or that it should be fixable by a beginner
> without any help. This should ONLY be set by a maintainer or people
> familiar with the code base, and ONLY when it looks like a project
> suitable for a new developer looking for a task.
covered by EasyHack -> DELETE
> movetoxkc (0)
> Bugs that should be moved to xkeyboard-config, if still applicable.
> NEEDINFO (51)
> The bug does not have enough information in order to solve the
> problem. Please read the comments and add the relevant information
> required to aid in solving the problem.
this is a status, so doesn't need to be a keyword too?
> notourbug (2)
> It's not really our bug, but we might work around it anyway.
RESOLVED NOTOURBUG -> DELETE?
> patch (21)
> Bugs with a valid patch.
the patch attachment should have the "patch" flag set which can be
queried so why do we need this?
> regression (3392)
> Xorg bug regressions (issues previously fixed but somehow broken again)
keep the all-time favorite, remove "Xorg" from description though
> security (6)
> Security-sensitive bugs
sure, let's keep them in the public bug tracker :D
> want-backtrace (13)
> Bugs whose triage could be greatly accelerated with the addition of a
> backtrace from the crash.
hmm sounds like it could be useful...
> x12 (0)
> Bugs that require a protocol version bump.
>> and add some [keywords]
>> that are nore useful.
> We have a number of "tags" that we put in the Whiteboard right now
> (also see advanced page)
> Many of those could become keywords.
> ALL: Proposals on which ones?
"confirmedRegression" never served any purpose and should be summarily
"possibleRegression" could be a keyword, unless it's considered too
transient a state... is that a criterion? hmmm... why not just add it...
"confirmed:VERSION:OS" "noRepro:VERSION:OS" "needsSOFTWARE"
"needsHARDWARE" "target:X.Y" "summary:comment#" are not fixed so cannot
"bibisected" should be keyword
"odf" and "odf_validation" should be keywords
"a11y" sounds useful as a keyword
"perf" sounds useful as a keyword
"interoperability" could be a keyword too, although perhaps a better
name is required that indicates this is about Microsoft Office and its
formats in particular ("MSOinterop"? "MSO"? "MSinterop"? "MSOffice"?).
there are *lots* of easy-hack related ones... not sure about those?
perhaps better leave them in the whiteboard since we may often add
additional ones etc. and the keyword list may become cluttered?
More information about the Libreoffice-qa