Talk:QA/BSA/BugReport Details

    From The Document Foundation Wiki

    New Bugzilla Version Picker Items

    Decision

    After Discussion on libreoffice-qa we have a decision, please see BugReport Details#New Versions 2012-06-20! -- Rainer Bielefeld 2012-06-20T06:32:54 (CEST)


    Discussion, Terminated !

    Discussion obsolete because of #Decision -- Rainer Bielefeld 2012-06-16T13:34:04 (CEST)

    A new structure of available Versions in Bugzilla version picker will try to fulfill following conditions:

    1. Easy visible relation between Picker item and LibO version visible in Help Menu
    2. manageable number of items in picker
    3. easy queries
    4. alphanumerical sort of Version items is the same as release order
    5. Suitable for Automatic Version transfer via Bug Submission Assistant

    My (Rainer Bielefeld 2012-05-31T07:38:53 (CEST)) suggestion for a solution will be nearby Solution A. I dismissed "B" because of concerns you find in the blog.

    Most will remain as it was, but

    • We will leave away "LibO" and use the saved place for distinguishing information
    • Picker version will contain core of Version info from Help / About + Additional info (literally, what will ease to use Version in Custom Search
    • Bold Version info is the same as in Help/About
    • Italic is additional info in Bugzilla Version picker
    • In brackets here you find additional info, not used in Help or Bugzilla Version pickers
    Old New Note
    3.5 Daily 3.5.0 alpha0+ Daily
    3.5.5 RC1 3.5.5.1 RC
    3.5.5 release 3.5.5.2 release
    Master 3.6.0 alpha0+ Master use ends with upcoming 3.7.0 alpha0+ Master
    Master 3.7.0 alpha0+ Master use ends with upcoming 4.0.0 alpha0+ Master
    • Example for Picker contents (bold+italic part) in timeline (more or less)
    • 3.5.0 alpha0+ Daily (Daily builds in Branch)
    • 3.5.0 beta0
    • 3.5.0 beta1
    • 3.5.0.1 RC (for release candidate)
    • 3.5.0.2 RC (for release candidate)
    • 3.5.0.2 release (renamed from RC)
    In between 3.5.0 alpha0+ Daily (will go on)
    • 3.5.1.1 RC (for release candidate)
    and so on

    In between available:

    • 3.6.0 alpha0+ Master

    When Branch 3.6 will be Created:

    • 3.6.0 alpha (Test Alpha)
    • 3.7.0 alpha0+ Master (New Name for Master in accordance with Help/About, no more builds "3.6.0 alpha0+" available)
    • 3.6.0 alpha0+ Daily (Starts with first Daily Build in branch, I will have to check how they really are named)
    • 3.6.0 beta0
    • 3.6.0 beta1
    • 3.6.0.1 RC (for release candidate)
    • 3.6.0.2 RC (for release candidate)
    • 3.6.0.2 release (renamed from RC)
    • 3.6.1.1 RC (for release candidate)
    • 3.6.1.2 RC (for release candidate)
    • 3.6.1.2 release

    The Versions in Picker will look more complicated, but because they match with Help/About use should be without problems. And may be we will get an automatic Version transfer in Picker, soon? Number of Versions in Picker will not increase too much, instead of Master from now to eternity we will get an additional Master with every new major release.

    Please write down your concerns below, I will try to give an answer and do modifications in system if necessary

    Concerns

    Concern 1

    The version of daily builds is currently bumped to follow the version of the related official builds . The current[*] scheme is:

    • 3.6.0 alpha0+ - daily builds in master before the first official alpha
    • 3.6.0 alpha1 - official alpha1 build
    • 3.6.0 alpha1+ - daily builds from master or 3-6 branch after the alpha1 release but before beta1 release; they have changes on top of alpha1 release
    • 3.6.0 beta1 - official beta1 build
    • 3.6.0 beta1+ - daily builds from 3-6 branch after beta1 release but before beta2 release; they have changes on top of beta1 release
    • 3.6.0 beta2 - official beta2 build
    • 3.6.0 beta2+
    • ...
    • 3.6.0.1 RC - first official release candidate
    • 3.6.0.1+ - daily builds from 3-6 branch after rc1 release and before rc2 release; changes on top of rc1
    • 3.6.0.2 RC
    • ...
    • 3.6.1.0+ - daily builds from 3-6 branch after we create 3-6-0 branch for final 3.6.0 stabilization; it is planned close before 3.6.0rc2 tag
    • 3.6.1.1 RC' - first 3.6.1 release
    • 3.6.1.1+ - daily builds from 3-6-1 branch after 3.6.1rc1 release
    • ...
    • 3.6.2.0+ - daily builds from 3-6 branch after we create 3-6-1 branch for final 3.6.1 stabilization; the branch is usually created close before 3.6.1rc1 release
    • 3.6.2.1 RC
    • ...
    That's really a lot of versions, and we will get very few reports for each. I will reduce that - somehow -- Rainer Bielefeld 2012-06-05T22:31:07 (CEST)

    [*] We currently use 3.5.5rc0+ instead of 3.5.5.0+ in the 3-5 branch. IMHO, 3.5.5.0+ looks more consistent and we should use it.

    I agree -- Rainer Bielefeld 2012-06-05T22:31:07 (CEST)

    Concern 2

    1. Independent to all we have the problem that in the query mode Bugzilla shows the versions in order of creation. That's bad, but I can't change it. But may be I should do the rename action in a good sort order? No idea what the result will be, may be the sort order in the query Version picker will be messed up terribly.
    2. The Idea was to use the Help/about contents (like 3.6.0beta1) as Version info and add Info like "RC" or "release" after a blank. And I hope that the sort order in the Bug view (for existing Bugs), what is alphabetical, should be the correct historical order (at least in most cases). But checking my 3.8 test versions (I will delete them after tests will have been finished) unfortunately shows that the historical sort order will be broken. The problem is not the blank, but the missing tailing ".x" in the alpha and beta versions. Any Ideas? -- Rainer Bielefeld 2012-06-06T17:59:20 (CEST)


    Additional Ideas

    Idea 1

    Referring to #Concern 2

    1. We could write the version numbers in Help/About as 3.9.0.0beta1 instead of 3.9.0beta1. That would heal the sort order as you see in my 3.8.0.0beta0. But this trick will (of course) not work for already existing versions, and would be a change in the Version numbering / release engineering. Is it that worth? -- Rainer Bielefeld 2012-06-06T17:59:20 (CEST)


    Idea 1

    New "developer" Components

    Terminated

    Due to developer's suggestions I am planning to add some new Components to Bugzilla. I still have some sympathy for a solution that lists all that stuff starting with sdk as subcomponents of [1] ⓘ ►, but that would have the disadvantage that these items can not be selected by a simple selector-pulldown in Bugzilla. So we might have problemswith misspellings, ... . Currently I am planning to create new Components lie Libreoffice.

    Before I can add the Components and the suggested sub components I need short descriptions. I wrote down what I believe to know, developers are asked to complete texts for Components and sub components. Please do not worry about formatting issues or similar, I will do that, tho only important thing is that information is available. Please keep in mind that I currently do not know for what you need these components, so please feel free for big modifications of my draft.

    I want to keep Bugzilla readable for non developers, so we need some explication where currently only ???? is available. If possible we should avoid abbreviations what are not common knowledge. The Component Text will appear in Bugzilla as Help text. It's important that duplicates can be found without too much knowledge. An example: A bug that is visible in WRITER should be listed under component WRITER. Even if from developer's view it's related to Module writerfilter, it should not be useful to use an other Component than WRITER, because under a different component users (who observed the problem in Writer) will not find an already reported bug under a different Component.

    • But "A bug that is visible in WRITER should be listed under component WRITER" is not always possible and even counter-productive in many cases: if the bug is actually in some part of the code that is shared between all applications, then it may well have duplicates that are filed e.g. against Calc or Impress, and having it assigned to the Writer component doesn't really help. That is a big reason why i want more components. Mst

    All we do has to be consistent. We are discussing to move our bug tracker to an own Bugzilla, and that will be a mess with terrible lot of work if we do not keep clean the existing FDO Bugzilla.

    As long as the Components are not be available in Bugzilla the links below will not work (you can test links and read explications on the article page). Rainer Bielefeld 2012-05-17T12:32:43 (CEST) 

    Comments

    Basically, I would prefer to add categories by functionality rather than by names of source modules. If the code is reasonable, it should match well. Functionality names should be better understandable for users or bug triagers.By Petr Mladek 2012-05-31 

    end Comments


    My questions to developers

    The most important request here: simply modify this page if you believe it's necessary and that your idea might be common sense.

    Why that

    For each component request a short "... because ..." statement concerning the problem you want to solve would be useful. Please leave the comments here. To be more concrete:

    • Is a part of the problem you want to solve is to track Module related bugs?
      • If Yes, did you also consider alternatives?
        • Could a whiteboard key word be an alternative? The advantage of this solution would be that we can retain the user-visible part (WRITER - UI) and additionally have information concerning related software module.

    Please replace question marks by useful help texts

    1. for framework - gsl - drawinglayer (BTW, on module page it's written as 1 word)
    2. for framework - svl


    Example

    Libreoffice

    This is only an example, new Components start with sdk.

    If you can't find any other appropriate component:
    MinGW ⓘ ► for MinGW problems, [2] ⓘ ► for all other issues.


    The new Components

    sdk

    This is the LibreOffice software development kit UNO Runtime environment ⓘ ► for ?????????
    UNO API ⓘ ► for ?????????
    SDK ⓘ ► for ????????? 

    Alternatively

    uno

    "LibreOffice's underlying scripting and extension framework"
    Runtime ⓘ ►; the low-level implementation of the framework
    API ⓘ ►; the UNOIDL interfaces and their use
    SDK ⓘ ►; the LibreOffice software development kit 

    End Alternatively

    Comments
    Using a two-level approach, I would rename the first level to "UNO" ("LibreOffice's underlying scripting and extension framework") with three second-level items "Runtime" ("The low-level implementation of the framework"), "API" ("The UNOIDL interfaces and their use"), and "SDK" ("The Software Development Kit"). Sb 2012-05-16T08:24:30 (CEST)
    end Comments

    framework

    framework of the applications,
    possible sub components are: framework ⓘ ► for ?????????
    sfx2 ⓘ ►; This is the gui code, much of which is now deprecated.
    svl ⓘ ► for  ?????????
    svtools ⓘ ►; Tools on top of VCL. Common dialogs, file and print dialogs, wizards, vcl filters, lots of helper code.

    native graphics layer (gsl)

    concerning the visual class library and other modules (e.g. printing, PDF export, ...).
    VCL library ⓘ ►; Visual Components Library is responsible for the widgets (windowing, buttons, controls, etc.) operating system abstraction, including basic rendering (e.g. the output device).
    drawing layer ⓘ ► for ?????????
    PDF Export ⓘ ► for ?????????
    printing ⓘ ► for ?????????
    we already have Libreoffice-Printing 

    Comments
    1. I would leave printing bugs the existing Printing component. The name is clear for both developers and users. Maybe, we would rename it to Printing/PDF Export because it is closely related.
    2. I would use GUI or User Interface instead of Framework and GSL. IMHO, it is more clear for users and it well describes the remaining content of the two groups.
    3. Another solution would be to rename Framework to GUI and the rest of GSL to Graphics toolkit. IMHO, these are better understandable than the original names and basically describe the content.

    By Petr Mladek 2012-05-31 

    end Comments

    filters

    import/export code shared between applications
    xmloff ⓘ ► for ?????????
    filter ⓘ ► for ?????????
    sax ⓘ ► for ?????????
    unoxml ⓘ ► for ?????????
    package ⓘ ► for ?????????
    [3] ⓘ ► for????????? 

    Comments

    I would rename it to Filters Framework or even Import/Export Filters Framework to make the meaning more clear just by reading the name. By Petr Mladek 2012-05-31 

    end Comments


    [4] ⓘ ► for [5] ⓘ ► for


    [6] ⓘ ► for
    [7] ⓘ ► for 


    Comments

    We might want to add the category "I/O" for problems with file locking, webdav, samba and other file access problems. By Petr Mladek 2012-05-31

    Basically, I would prefer to add categories by functionality rather than by names of source modules. If the code is reasonable, it should match well. Functionality names should be better understandable for users or bug triagers. 


    end Comments


    Problems

    Lots of Modules

    I believe for more or less all Modules on <https://docs.libreoffice.org/index.html> a possibility to track bugs in those modules is required.

    That's simple, for example for a Component "Libreoffice" these Module names can simply be used at the beginning of the Summary Line, see my example, what might be added to the Bug Details Help line for easy report and query creation:
    accessibility ⓘ ► (Cares for accessibility. )
    afms ⓘ ► (External library. )
    animations ⓘ ► (Contains containers for the css::animation UNO API, used in slideshow and sd. )
    apache-commons ⓘ ► (Java libraries; used for logging and http/https access in Extensions, from http://commons.apache.org/ )
    apple_remote ⓘ ► (Adds support for the Apple Remote (a remote control) to control Impress. )
    autodoc ⓘ ► (Create HTML pages from C++, Java and IDL inline documentation. )
    avmedia ⓘ ► (Audio/Video media implementation. )
    basctl ⓘ ► (Controls and dialogs for Basic. Contains the Basic IDE. )
    basebmp ⓘ ► (Provides a BitmapDevice: the vcl software renderer )
    basegfx ⓘ ► (Algorithms and data types for graphics (e.g. polygons, vectors, matrices and the like - see that used in canvas). )
    basic ⓘ ► (Contains the StarBASIC Interpreter and in addition the GUI of VCLTestTool. )
    bean ⓘ ► (To use LibreOffice from Java applications. )
    beanshell ⓘ ► (Java interpreter from http://www.beanshell.org/ with some patches. )
    berkeleydb ⓘ ► (The Berkeley database. )
    bin ⓘ ► (Tools and scripts mostly not used during the build )
    bridges ⓘ ► (Bridges from various C++ ABIs, Java JNI, MS .Net to UNO and back. )
    cairo ⓘ ► (The graphics library, used for anti-aliasing. From http://cairographics.org/. )
    canvas ⓘ ► (New canvas implementation to improve rendering, various backends implement the new XCanvas API eg. Cairo / DirectX. )
    chart2 ⓘ ► (Chart implementation for LibreOffice Calc. )
    codemaker ⓘ ► (UNO interface declaration/stub generators for C++ (headers), Java (class files), ... the one for .Net is in cli_ure. )
    comphelper ⓘ ► (GUI-related helper classes )
    configmgr ⓘ ► (The configuration database - UNO services and some tools. )
    connectivity ⓘ ► (Contains database pieces, drivers, etc. )
    cosv ⓘ ► ("Common Services" part of autodoc. )
    cppcanvas ⓘ ► (Helper C++ classes for canvas, plus a GDIMetaFile-to-XCanvas converter. )
    cppu ⓘ ► (Type definitions/implementations for the core of UNO. The exported API is in C. )
    cppuhelper ⓘ ► (Helpers for using cppu in C++, e.g. templates for implementing UNO components, bootstrapping stuff. Get UNO up and running. )
    cppunit ⓘ ► (C++ port of the JUnit framework for unit testing. )
    cpputools ⓘ ► (Old way of doing component registration. Nowadays replaced by another stand-alone UI and tools called UNO package. )
    crashrep ⓘ ► (Reports crashes (Novell disabled that). )
    curl ⓘ ► (A URL manipulation engine from http://curl.haxx.se/. )
    dbaccess ⓘ ► (Database access tools, for "base" database application )
    desktop ⓘ ► (What used to be the desktop in StarOffice 5 - now the binary. ) /
    distro-configs ⓘ ► (Pre-canned distribution / platform configurations )
    dtrans ⓘ ► (Clipboard abstraction - data transfer. )
    editeng ⓘ ► (Edit engine. )
    embedserv ⓘ ► (To embed LibreOffice via OLE2. )
    epm ⓘ ► (Enhanced Package Manager, From http://freshmeat.net/projects/epm )
    eventattacher ⓘ ► (How basic handles events )
    expat ⓘ ► (Simple SAX parser library with added UCS2 support. )
    extensions ⓘ ► (Browser plugin, activex control, scanner bits. )
    extras ⓘ ► (Contains templates, clipart galleries, palettes, symbol font etc. )
    fileaccess ⓘ ► (Implements XSimpleFileAccess interface that makes the UCB interfaces actually usable (via UNO) and more intuitive. )
    filter ⓘ ► (Filter registration and some simple filters (also descriptions). )
    forms ⓘ ► (Embedded forms control and pieces (design forms in documents, fields and database driven). )
    formula ⓘ ► (Contains parts of the formula parser used outside Calc code. )
    fpicker ⓘ ► (Native file pickers for Unix and Windows (file open dialog) GTK+, KDE, Windows. )
    framework ⓘ ► (UI rewrite, toolbars, menus, UNO stuff, including accelerators and interaction, etc. )
    graphite ⓘ ► (Library for providing rendering capabilities for complex non-Roman writing systems. )
    hsqldb ⓘ ► (Java database engine from http://hsqldb.org/. )
    hunspell ⓘ ► (Library for spell checking. )
    hwpfilter ⓘ ► (Filter for a word processor file format popular in Korea (Hangul Word Processor). )
    hyphen ⓘ ► (Hyphenator library from http://hunspell.sourceforge.net )
    icc ⓘ ► (Library used to build the sRGB profile for PDF/A-1a export with patches. )
    icon-themes ⓘ ► (Icon repository for the applications )
    icu ⓘ ► (Library providing Unicode support, from http://site.icu-project.org/. )
    idl ⓘ ► (SvIDL Compiler. )
    idlc ⓘ ► (Contains the IDL compiler. )
    io ⓘ ► (Simple IO wrappers. )
    javaunohelper ⓘ ► (Makes it easier to use UNO with Java. )
    jfreereport ⓘ ► (Java library providing basic functionality for the report builder, from http://www.object-refinery.com/jfreereport/ )
    jpeg ⓘ ► (Support for jpeg-format. (Which library, where used )
    jurt ⓘ ► (JURT means Java Uno Runtime and implements most of Java UNO. )
    jvmaccess ⓘ ► (Wrappers so you can use all the Java Runtime Environments with their slightly incompatible APIs with more ease. )
    jvmfwk ⓘ ► (Wrappers so you can use all the Java Runtime Environments with their slightly incompatible APIs with more ease. )
    languagetool ⓘ ► (Style and grammar checker for various languages written in Java, from http://www.languagetool.org/ )
    libwpd ⓘ ► (From http://libwpd.sourceforge.net/. Not modified. WordPerfect filter - SAX api - emits callbacks when things happen. )
    libwpg ⓘ ► (From http://libwpg.sourceforge.net/. WordPerfect graphics filter. )
    libwps ⓘ ► (Microsoft Works file word processor format import library from http://libwps.sourceforge.net/. )
    libxml2 ⓘ ► (Gnome xml parser library written in C, from http://xmlsoft.org/ )
    libxmlsec ⓘ ► (XML signing, etc. From http://www.aleksey.com/xmlsec/. Heavily patched. )
    libxslt ⓘ ► (Gnome xslt library written in C, from http://xmlsoft.org/xslt/ )
    lingucomponent ⓘ ► (Spellcheck, hyphenator, thesaurus, etc. )
    linguistic ⓘ ► (Handles registered modules for spellchecker, hyphenator and thesaurus. )
    lotuswordpro ⓘ ► (Filter for file format of Lotus Word Pro. )
    lpsolve ⓘ ► (A mixed Integer Linear Programming (MILP) solver from http://lpsolve.sourceforge.net/. )
    lucene ⓘ ► (From http://lucene.apache.org/. (CH: What of it is used for what )
    MathMLDTD ⓘ ► (MathMLDTD implements XML Math format. )
    mdds ⓘ ► (Multi-dimensional data structure (mdds) library, available from http://code.google.com/p/multidimalgorithm/. )
    migrationanalysis ⓘ ► (Wizard to analyze potential problems when migrating from MSOffice to LibreOffice. )
    moz ⓘ ► (Used for security features, if nss is not available. )
    mysqlc ⓘ ► (The MySQL driver for LibreOffice. )
    mysqlcppconn ⓘ ► (From http://forge.mysql.com/wiki/Connector_C%2B%2B )
    mythes ⓘ ► (Library for handling thesaurus files from http://hunspell.sourceforge.net. )
    neon ⓘ ► (Web library to help deal with WebDAV or other protocols, from http://www.webdav.org/neon/. )
    nlpsolver ⓘ ► (This extension integrates into Calc and offers new Solver engines to use for optimizing nonlinear programming models. )
    np_sdk ⓘ ► (Netscape Plugin SDK. Header to build Mozilla plugins. )
    nss ⓘ ► (Containes the security libraries which are also part of moz. However nss is meant to be more current. )
    o3tl ⓘ ► (Very basic template functionality, a bit like boost or stl, but specific to LibO )
    odk ⓘ ► (Office development kit - implements the first step on the way to the LibreOffice SDK tarball. )
    offapi ⓘ ► (Contains all of the IDL files except those in udkapi )
    officecfg ⓘ ► (The schema and default settings for the OpenOffice.org configuration database. )
    oovbaapi ⓘ ► (Module for OpenOffice - VisualBasic interoperability. )
    oox ⓘ ► (Support for Office Open XML, the office XML-format designed by Microsoft. )
    openssl ⓘ ► (Open Source toolkit implementing SSL and TLS. )
    package ⓘ ► (Reading and writing ZIPs. )
    padmin ⓘ ► (Printer administration dialog - used lpr - obsolete with CUPS and fontconfig, but still used for some things. )
    postprocess ⓘ ► (Postprocessing and checking of files delivered by other modules. )
    psprint_config ⓘ ► (Contains ppds for use by psprint when not using CUPS. )
    python ⓘ ► (Python interpreter from http://www.python.org/ )
    pyuno ⓘ ► (UNO bindings for the Python programming language. )
    qadevOOo ⓘ ► (Testsuite. )
    rdbmaker ⓘ ► (Makes registries for openoffice for storing type data )
    readlicense_oo ⓘ ► (Read the LibreOffice license when starting up. )
    redland ⓘ ► (Redland RDF library (librdf) from http://librdf.org/ )
    regexp ⓘ ► (This is a regexp parser. )
    registry ⓘ ► (Registry reading, etc. )
    remotebridges ⓘ ► (UNO services dealing with interprocess bridges. )
    reportbuilder ⓘ ► (Oracle report builder extension, from http://extensions.services.openoffice.org/project/reportdesign. )
    reportdesign ⓘ ► (Part of LibreOffice Base )
    rhino ⓘ ► (JavaScript engine/interpreter written in Java, used to provide JavaScript extensions. )
    ridljar ⓘ ► (Implements types for the Java Uno typesystem. )
    rsc ⓘ ► (Resource Compiler. )
    sal ⓘ ► (System abstraction layer; rtl, osl and sal )
    salhelper ⓘ ► (C++ helpers to make use of sal easier. )
    sane ⓘ ► (Scanner library from http://www.sane-project.org/ )
    sax ⓘ ► (Wrapper around expat using UNO. )
    saxon ⓘ ► (XSLT and XQuery Processor from )
    sc ⓘ ► (Spreadsheet application code. )
    scaddins ⓘ ► (Extra functions for calc. )
    sccomp ⓘ ► (The (linear) solver for LibreOffice Calc. )
    scripting ⓘ ► (This module provides the source code for the Scripting Framework. )
    sd ⓘ ► (The core directory for the impress/draw applications. )
    sdext ⓘ ► (Extensions for the Impress and Draw applications. )
    sfx2 ⓘ ► (This is the gui code, much of which is now deprecated. )
    shell ⓘ ► (System helpers - launching URI, recently used files, system integration, external mailer support, gconf integration etc. )
    slideshow ⓘ ► (Contains the new impress slideshow engine introduced in OO.o 2.0 )
    smoketestoo_native ⓘ ► (Smoke test for each component of LibreOffice. )
    sot ⓘ ► (Compound file storage tools code. )
    starmath ⓘ ► (Formula editor code for writer (sw). )
    stax ⓘ ► (Library implementing the Streaming API for XML. (CH: Which one, probably the one by )
    stoc ⓘ ► (Registries, reflection, introspection implementation for UNO. )
    store ⓘ ► (Streams, mmaps, etc. )
    svtools ⓘ ► (Tools on top of VCL. Common dialogs, file and print dialogs, wizards, vcl filters, lots of helper code. )
    svx ⓘ ► (Contains graphics related helper code. Lots of the draw and impress code is in this shared library. )
    sw ⓘ ► (Writer application code. )
    swext ⓘ ► (Writer extensions (currently only MediaWiki Extension). )
    sysui ⓘ ► (.desktop files for different distros. )
    tail_build ⓘ ► (This module exist only to take advantage of the ability of gbuild to build )
    testtools ⓘ ► (Testing tools )
    tomcat ⓘ ► (From http://tomcat.apache.org/. Patched. )
    toolkit ⓘ ► (Abstract windowing thing, UNO implementations of windows stuff so that it can be used from Basic. )
    tools ⓘ ► (Predates sal - string etc . functions, url manip, stream stuff, polygons, etc. )
    twain ⓘ ► (Windows scanner support. )
    ucb ⓘ ► (Universal Content Broker (has ucp) which do things like convert files to strings in content broker world. )
    ucbhelper ⓘ ► (C++ wrappers to help make using content providers easy. )
    udkapi ⓘ ► (Low level UNO stuff API IDL files )
    udm ⓘ ► (Forms part of autodoc. )
    unixODBC ⓘ ► (Library and API with which to access Data Sources from http://www.unixodbc.org/ )
    UnoControls ⓘ ► (Separate process and thread for progress bars, etc. )
    unoil ⓘ ► (As offuh but for Java UNO: Maps IDL into java classes definitions. )
    unotools ⓘ ► (Helpers for C++ use of UNO. )
    unoxml ⓘ ► (UNO wrappers for XML services. )
    ure ⓘ ► (Contains the UNO Runtime Environment (URE). )
    uui ⓘ ► (Contains an Interaction Handler for the ucb and other uses. Works via VCL. )
    vcl ⓘ ► (Visual Components Library is responsible for the widgets (windowing, buttons, controls, etc.) operating system abstraction, including basic rendering (e.g. the output device). )
    vigra ⓘ ► (Computer vision library in C++ from http://hci.iwr.uni-heidelberg.de/vigra/. )
    wizards ⓘ ► (Java wizards for db setup, importing, tutorials, etc. )
    writerfilter ⓘ ► (The writerfilter module contains import filters for Writer, using its UNO API. )
    writerperfect ⓘ ► (Word Perfect filter, wrapper for libwpd. )
    x11_extensions ⓘ ► (Headers for XRender support )
    xmerge ⓘ ► (For converting documents among from and into formats and also for merging them. )
    xml2cmp ⓘ ► (Part of the LibreOffice SDK. )
    xmlhelp ⓘ ► (Help reader and viewer for online help. )
    xmloff ⓘ ► (Contains common xml import and export filter logic. )
    xmlscript ⓘ ► (XML dialogs. )
    xmlsecurity ⓘ ► (Stuff for document signing. )
    xpdf ⓘ ► (PDF-viewer library from http://www.foolabs.com/xpdf/. )
    xsltml ⓘ ► (XSLT MathML Library from http://xsltml.sourceforge.net/. )
    zlib ⓘ ► (Compression library from http://www.zlib.net/. )

    to create this lot of stuff only took few minuts, and with a link in Bugzilla Component hepl texts everybody would have a chance to understand for what those "sub components" are (I took Component Libreoffice here so that the Links will create working bug reports or queries). But I doubt that that would be useful. For Tracking Module related Bugs I currently prefer a solution whiteboard key word or similar.

    Names already used

    If we would want to track bugs related to Module slideshow, we have to regard that for Component Presentation we already have a sub component SLIDESHOW ⓘ ►. I did not check for other duplicates.

    This BugReport Details draft is for discussion concerning tdf#31593

    Prepared Links for Bugzilla Search and Bug Submission

    What do you think?

    Should be improved?!

    Subcomponent BASIC for Component BASIC?

    Seems not useful, but may be we should have Subcomponents for the various interpreters? -- Rainer Bielefeld 2011-08-19T11:05:42 (CEST)

    More flexible Template

    1. For some applications might be useful to add search items. For examples, Draw and impress share may functionality. So it would be useful to search DRAW + Impress for Subcomponents. I added some details on Template talk:FdoSCS2 -- Rainer Bielefeld 2011-08-20T08:30:05 (CEST)

    Online Help

    In the classical definition, Online Help is "the" help system of a software, the term "online" has nothing to do with the term "online" of a modem or similar like "being connected to the internet". You can read this in Wikipedia, and in this way "Online Help" has been used in OOo Issuezilla.

    It seems that currently there is a shifting of the sense of "Online Help" (please also see the Wikipedia text) and, of course, I do not have any problem with using it in this way; I never understood this "online" for the normal Help system.

    But we should do that in a consequent way.

    The latest changes in the text replacing WIKIHELP by ONLINEHELP seem to be no good Idea, Jan Holesovsky had asked to use WIKIHELP in the Bugzilla subject line.

    To get a final solution for this confusion of ideas I filed a tdf#33863 -- RBd 2011-02-03T07:26:49 (CET)

    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Talk:QA/BSA/BugReport_Details&oldid=120334"