Jump to content

QA/Bugzilla/Fields/Whiteboard/Advanced: Difference between revisions

From The Document Foundation Wiki
m replacing redirects (automated)
Jmadero (talk | contribs)
Completely New Design (In Progress)
Line 8: Line 8:
= Getting Started =  
= Getting Started =  
[[File:Whiteboard image.png|250px|right]]
[[File:Whiteboard image.png|250px|right]]
This is our complete Whiteboard status page. If you're looking for the basics please visit [[QA/Bugzilla/Fields/Whiteboard|this link]]
= Getting Started =
'''Note:''' This page is currently in progress


The '''Whiteboard''' text box on FreeDesktop.Org (FDO) is where QA puts specific terms to help organize our bug tracker. Unlike the '''Keywords''' text box, there are no restrictions on what can go in the '''Whiteboard''' box but we encourage users and QA only to put words that are on the approved list.
This is our '''comprehensive''' whiteboard status page. It includes many details about every whiteboard status which we currently use as well as details about ones which are no longer in use. If you're looking for a less comprehensive page please see our [https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard whiteboard basics page].


Notes on use:
The Whiteboard text box on FreeDesktop.Org (FDO) is where QA, Developers, and users can put specific terms to help organize our bug tracker. Unlike the [https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords Keywords ][https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Keywords field], there are no restrictions set by the bug tracker on what can go in the Whiteboard box. This being said we have some general guidelines:
* Do NOT use the Whiteboard for random comments!
* Separate the tags by a whitespace (e.g. "this_tag that_tag another_tag"); '''do not use commas'''
* Individual tags should never contain whitespace, use an underscore instead (e.g. "data_loss").


= Common Whiteboard Tags/Statuses =
* use whiteboard status sparingly, many things can be accomplished by appropriately using version, OS, keywords, and comments
* Whiteboard status' not listed below should be “vetted” (discussed) on the [http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa QA list] before adding a new one
** If a new whiteboard status is desired, please email the QA list and explain what purpose it would serve.


These are some of the most common '''Whiteboard''' status' which should be used when appropriate. For the complete list of terms along with more advanced instructions about how QA uses '''Whiteboard'''please be patient as the page is being developed.
= Complete List of Accepted Whiteboard Tags =
== Automatic Messages ==
=== Target ===
'''Description: '''target refers to the version(s) where a commit which fixes the problem can be expected to be seen.


Note:
'''Use: '''Generally “target” is automatically entered when a developer commits a patch specifically to fix a bug reported on the bug tracker. Users, QA and Developer should generally not manually enter “target” into whiteboard, the only exception is when the automatic system did not tag the bug and a developer or QA member knows the exact commit which fixed the bug and what version of LibreOffice will see the patch. In these cases a QA member can mark a bug as “target:x.x.x.x” where x.x.x.x is the version(s) of LibreOffice where the commit was pushed to.
Please do not just add random words to '''Whiteboard''' text box - most words should be approved by the QA team (either through mailing list or during QA call) before being used unless you are an active contributor to the team.


== Specific OS Requirement ==
'''Example''': target: 4.2.0.0 – this means that a commit which fixes the problem was committed to the 4.2.0.0, and therefore if a user or QA member tests 4.2.0.0 they should not see the bug any longer.
Should be used '''only''' be used if the bug is '''confirmed''' to only affect a specific OS.
**OS-XP
**OS-W8
**OS-Ubuntu


=== BSA ===
'''Description: '''BSA refers to “Bug Submission Assistant” and when in the whiteboard means that the bug was submitted through our bug submission assistant. For more information about BSA click [https://wiki.documentfoundation.org/QA/BSA/BugReport_Details here].


'''Use: '''Always entered automatically, no need to ever manually put BSA into whiteboard.


== Bibisect ==
=== PossibleRegression ===
* '''bibisected: ''' A complete bibisect has been done, log and output are attached to bug. Instructions on how to bibisect can be found here: [[QA/HowToBibisect]].<br />
'''Description: '''PossibleRegression is entered when a user has stated that the bug was not present in a previous release of LibreOffice and therefore it's a regression. The point of this status is so that QA can confirm that there is a regression and do the follow up steps needed for regressions (bibisect, etc . . .)


* '''PreBibisect: '''The bug is is present in the earliest commit in the bibisect package(s). Only use this if you are using the 4.0 bibisect package or the 3.5 bibisect package, as the tagged versions in the other bibisect packages do not go back as far.<br />
'''Use: '''PossibleRegression is entered automatically when a user enters a previous version in BSA where the bug was not present. PossibleRegression can be manually entered by a user when they are reporting directly to the bug tracker (ie. Not through BSA) if they believe that the bug is a regression – if they do this they should write in the bug description when the bug was not present.


* '''bibisectrequest: ''' If a bug is marked as a regression between 3.5.4 and 4.2 master a bibisect is appropriate and thus requesting one (using bibisectrequest status) is a good way to highlight the bug and get someone to bibisect at their earliest convenience.<br />
== Currently In Use ==
=== a11y ===
'''Description: '''Used when the bug report is about an accessibility issue. Accessibility refers to bugs and enhancements which affect individuals with special needs. Applicable for both enhancement requests and bug reports.


* If you can do Bibisect and are willing to help to narrow down the Version where the bug appeared, you can use [https://bugs.libreoffice.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=PLEASETEST&chfieldfrom=-2d&chfieldto=Now&list_id=87479&product=LibreOffice&query_format=advanced&status_whiteboard=bibisectrequest&status_whiteboard_type=allwordssubstr&title=BibisectRequest%20Bug%20List&ctype=atom this] [http://en.wikipedia.org/wiki/Atom_Feed Atom Feed] to get message for new Bugs with Whiteboard entry ''bibisectrequest'' (what should be removed when you did the Bibisect).
'''Use: '''Manually entered by someone who knows about accessibility problems. These are specific to bugs which would affect the way that individuals with special needs interact with LibreOffice – generally not appropriate if it is just a request to make something easier for everyone.


== Releases ==
=== bibisected ===
* '''target:X.Y.Z''' for the next [[ReleasePlan|Release]] where the fix will be available (no Beta, RC, ...)
'''Description: '''Used for letting developers know that the bug has been bibisected. For more information on bibisect see  '''LINK'''
** It must be target followed by a colon (:) then the version number.  It must be one word without whitespace in order for it to be usable via regexp search.
** A target marker should always be set by the developer working on the bug, never by the reporter.
** At the time of bug resolution, the developer should set the target marker to indicate to which version the bug fix will be applied (if it has not been already set).
** If a bug in a stable version vanished in the Master (or in a later stable Version) '''without a known fix''', a developer or QA member should change the Bug report Status to ''WORKSFORME'' with Whiteboard '''target entry in parenthesis''' with the first known version without the bug like "(target:4.0.0)". If the problem vanished in a Master version, in a comment the complete Master build ID what has been tested without seeing the bug should be mentioned. So other users seeing the problem during their tests can find out easily where they can await a version without the bug.


== OS-Specific ==
here.
* '''OS-Specific''': The list below is a short list of whiteboard statuses appropriate if it's very specific to an OS


== Other Statuses ==
'''Use: '''Should be manually entered by the person attaching the bibisect details after bibisecting a bug.
* '''BSA''' means that this bug has been submitted using the [[QA/BSA|'''B'''ug '''S'''ubmission '''A'''ssistant]]
* '''PossibleRegression''' indicates that this ''may'' be a regression, but has not yet been independently confirmed.
** The BSA sets this value (instead of the keyword '''regression''') if it believes that a bug is a regression.
*'''[https://bugs.libreoffice.org/buglist.cgi?status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=numberformat&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=PLEASETEST&component=Spreadsheet&product=LibreOffice  numberformat]'''
:Used by developers to identify bugs related to Calc's number format handling code.
* '''perf'''
:for performance issues
* '''odf''' is a very general keyword for any kind of interoperability problem in consuming or producing ODF documents
* '''odf_validation''' is specifically for bugs about LO producing invalid or non-conforming ODF documents


* '''experimentalEnabled''' for behavior which is evident only when the user has checked Tools > Options > LibreOffice > General > "Enable experimental (unstable) features".
=== EasyHack ===
* '''rtf_filter''': to distinguish general RTF related bugs form particular ones related to the ''new'' RTF import filter. This helps to track down those new filter related bugs more easily. Use of this key word needs detailed knowledge concerning new filter. Experts are Miklós Vajna, Lubos Lunak , Cédric Bosdonnant (for example).
'''Description: '''Used to denote a bug which has been determined to be a good start for a new developer on the project.
* '''lhm-limux''': used to mark a bug as significant for the City of Munic Limux-project. Should be assigned only by members of the City of Munic, and is used to filter those bugs.
* '''VOTE''': Invitation to use the (still experimental and inofficial) [[Vote for Enhancement]]


*'''NeedAdvice''': This should only be used after several QA members have been confirmed to have tried to triage but the bug is too complex to do so or a setup that no QA member has is needed (current example: webdav)
'''Use: '''Developers should be the only ones to use this whiteboard status. Developers add this status after they provide code pointers to fix the bug.


*'''SummaryUpdate''': This means that this bug had more than 20 bugs and thus required the additional information in the comments to be summarized. The tag is added when that is done and removed if another update of the summary is needed for additional comments. See {{fdo|73993}} for details.
=== NoRepro:VERSION:OS ===
'''Description: '''Used when you are unable to reproduce the bug but are not comfortable closing the bug as  '''LINK'''


== Temporary/Private-Use/Special ==
WORKSFORME. Includes information about what version was used and the operating system of the tester.  
* Whiteboard key words only created for a terminable project, private use or similar:
** '''hfmuc2012''': ''H''ack''F''est''MU''ni''C''h2012 decision to use it for bugs as Lionel Mamane's  goal to tackle during that event
** some other key word [https://bugs.libreoffice.org/buglist.cgi?status_whiteboard_type=anywords&query_format=advanced&list_id=243167&status_whiteboard=test2%20datapilot%20comment58%20summary%20sliedeshow%20experimentalEnabled%20PATCHESWELCOME%20NEEDINFO%20INTEROPERABILITY%20infoprovider%20impasse%20feature%20experimentalEnabled%20%20data_loss%20complextest%20ux-feedback%20&product=LibreOffice still needing clarification]


= Development: Whiteboard Statuses for EasyHacks =
'''Use: '''Generally used when the testing environment is different than the testing environment of the bug reporter so closing the bug as WORKSFORME status is less applicable. Used mostly by QA members and developers.


[[Development/Easy Hacks/Bugzilla Whiteboard Statuses|EasyHacks have a number of specific Statuses]] that are used to track their progress, including statuses in the following categories:
'''Example(s): '''NoRepro:4.1.3.2:Ubuntu, NoRepro:4.1.3.2:Windows7, NoRepro:4.2.0.1:OSX
* General
* Difficulty
* Skills
* Topic


= Design: Color Handling =
=== Confirmed:VERSION:OS ===
'''Description: '''Can be used to say that the bug was confirmed on a particular OS and using a particular version of LibreOffice.


Looks like there might be 1-2 standardized tags regarding color handling. (''Note: Is this still relevant? Something we can just clean up?'')
'''Example(s): '''Confirmed:4.1.3.2:Ubuntu, Confirmed:4.1.3.2:Windows7, Confirmed:4.2.0.1:OSX


* [[Design/Whiteboards/Color Handling#Relevant Bugs]]
'''Use: '''Not frequently used but can be used when wanting to add more information to a confirmed bug. Should always include “Confirmed:” and then version and OS (see examples above).
 
=== BibisectedNewer ===
'''Description: '''Used in cases where a bug has been confirmed to be a regression but the regression occurred after the last commit in the latest bibisect package.
 
'''Use: '''If a regression is confirmed on master or on a recent daily build then it's likely going to be too new to be bibisected. QA should still try to bibisect the bug just in case the bad commit is within the bibisect range.
 
=== BibisectRequest ===
'''Description: '''Used to let us know that a bibisect is needed.
 
'''Use: '''All confirmed regressions after 3.5.0 should have a BibisectRequest whiteboard status unless the bug is specific to Windows (which should be confirmed prior to removing a BibisectRequest). Many bugs that affect Windows will also affect Linux and OSX so they can be bibisected successfully.
 
=== ConfirmedRegression ===
'''Description: '''Is used if a bug is confirmed to be a regression.
 
'''Use: '''If a bug is confirmed to be a regression then a user, QA, or developer can put ConfirmedRegression into the whiteboard. If this is done the individual should also put in the comments what version worked (and is confirmed to have worked) and what version does not.
 
=== DifficultyBeginner ===
'''Description: '''Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that not only is the bug an easy hack, it is “really easy” and can be done by individuals who have beginner skills in computer science.
 
'''Use: '''Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.
 
=== DifficultyEasy ===
'''Description: '''Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that the bug is fairly easy but not quite easy enough for beginners.
 
'''Use: '''Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.
 
=== DifficultyInteresting ===
'''Description: '''Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that while the bug is considered to be an easy hack by our experts, it could be quite challenging for a new developer on the project. Generally people who tackle these should be relatively comfortable with programming generally.
 
'''Use: '''Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.
 
=== NeedsSOFTWARE ===
'''Description''': Used to highlight a particular piece of software that is required to triage the bug.
 
'''Use: '''Only used for unique software requirement. Not appropriate for “NeedsMicrosoftOffice” as Microsoft Office is relatively common but if the bug only affects MicrosoftOffice2013 then using “MicrosoftOffice2013” is appropriate. Also not appropriate for “NeedsWindows” (setting version to “Windows(all)” is sufficient, but if a particular version of Windows is needed (such as XP) it is appropriate.
 
'''Examples''': NeedsAlfresco, NeedsDuplexPrinter, NeedsWebDAV, NeedsWindowsXP
 
 
== No Longer In Use ==
Really '''no longer in use – please do not use these status''''
 
=== Accessibility ===
'''Description: '''Replaced by a11y – see description there.
 
'''Use: '''No longer used. Replaced by a11y.
 
=== bibisected35older ===
'''Description: '''Was used to indicate that the bug was present before the bibisect35 package.
 
'''Use: '''No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see  '''LINK'''
 
here.
 
=== bibisected35 ===
'''Description''': Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect35 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see  '''LINK'''
 
here.
 
'''Use: '''No longer used. Replaced by “bibisected”.
 
=== bibisected36 ===
'''Description''': Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect36 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.
 
 
Use: No longer used. Replaced by “bibisected”.
 
=== bibisected35newer ===
'''Description: '''Was used in the past to say that a regression was introduced after the bibisect35 package.
 
'''Use: '''No longer used.
 
=== bibisected36older ===
'''Description: '''Was used to indicate that the bug was present before the bibisect36 package.
 
'''Use: ''' No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.
 
=== bibisected40 ===
'''Description''': Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect40 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.
 
'''Use: ''' No longer used. Replaced by “bibisected”.
 
=== bibisected40newer ===
'''Description: '''Was used in the past to say that a regression was introduced after the bibisect40 package.
 
'''Use: '''No longer used.
 
=== bibisected40older ===
'''Description: '''Was used to indicate that the bug was present before the bibisect40 package.
 
Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.


[[Category:QA]]
[[Category:QA]]
[[Category:Bugzilla]]
[[Category:Bugzilla]]
[[Category:Fields]]
[[Category:Fields]]

Revision as of 19:46, 4 June 2014

This page is the complete page for the Whiteboard (aka status_whiteboard) field in Bugzilla.

Getting Started

Getting Started

Note: This page is currently in progress

This is our comprehensive whiteboard status page. It includes many details about every whiteboard status which we currently use as well as details about ones which are no longer in use. If you're looking for a less comprehensive page please see our whiteboard basics page.

The Whiteboard text box on FreeDesktop.Org (FDO) is where QA, Developers, and users can put specific terms to help organize our bug tracker. Unlike the Keywords field, there are no restrictions set by the bug tracker on what can go in the Whiteboard box. This being said we have some general guidelines:

  • use whiteboard status sparingly, many things can be accomplished by appropriately using version, OS, keywords, and comments
  • Whiteboard status' not listed below should be “vetted” (discussed) on the QA list before adding a new one
    • If a new whiteboard status is desired, please email the QA list and explain what purpose it would serve.

Complete List of Accepted Whiteboard Tags

Automatic Messages

Target

Description: target refers to the version(s) where a commit which fixes the problem can be expected to be seen.

Use: Generally “target” is automatically entered when a developer commits a patch specifically to fix a bug reported on the bug tracker. Users, QA and Developer should generally not manually enter “target” into whiteboard, the only exception is when the automatic system did not tag the bug and a developer or QA member knows the exact commit which fixed the bug and what version of LibreOffice will see the patch. In these cases a QA member can mark a bug as “target:x.x.x.x” where x.x.x.x is the version(s) of LibreOffice where the commit was pushed to.

Example: target: 4.2.0.0 – this means that a commit which fixes the problem was committed to the 4.2.0.0, and therefore if a user or QA member tests 4.2.0.0 they should not see the bug any longer.

BSA

Description: BSA refers to “Bug Submission Assistant” and when in the whiteboard means that the bug was submitted through our bug submission assistant. For more information about BSA click here.

Use: Always entered automatically, no need to ever manually put BSA into whiteboard.

PossibleRegression

Description: PossibleRegression is entered when a user has stated that the bug was not present in a previous release of LibreOffice and therefore it's a regression. The point of this status is so that QA can confirm that there is a regression and do the follow up steps needed for regressions (bibisect, etc . . .)

Use: PossibleRegression is entered automatically when a user enters a previous version in BSA where the bug was not present. PossibleRegression can be manually entered by a user when they are reporting directly to the bug tracker (ie. Not through BSA) if they believe that the bug is a regression – if they do this they should write in the bug description when the bug was not present.

Currently In Use

a11y

Description: Used when the bug report is about an accessibility issue. Accessibility refers to bugs and enhancements which affect individuals with special needs. Applicable for both enhancement requests and bug reports.

Use: Manually entered by someone who knows about accessibility problems. These are specific to bugs which would affect the way that individuals with special needs interact with LibreOffice – generally not appropriate if it is just a request to make something easier for everyone.

bibisected

Description: Used for letting developers know that the bug has been bibisected. For more information on bibisect see LINK

here.

Use: Should be manually entered by the person attaching the bibisect details after bibisecting a bug.

EasyHack

Description: Used to denote a bug which has been determined to be a good start for a new developer on the project.

Use: Developers should be the only ones to use this whiteboard status. Developers add this status after they provide code pointers to fix the bug.

NoRepro:VERSION:OS

Description: Used when you are unable to reproduce the bug but are not comfortable closing the bug as LINK

WORKSFORME. Includes information about what version was used and the operating system of the tester.

Use: Generally used when the testing environment is different than the testing environment of the bug reporter so closing the bug as WORKSFORME status is less applicable. Used mostly by QA members and developers.

Example(s): NoRepro:4.1.3.2:Ubuntu, NoRepro:4.1.3.2:Windows7, NoRepro:4.2.0.1:OSX

Confirmed:VERSION:OS

Description: Can be used to say that the bug was confirmed on a particular OS and using a particular version of LibreOffice.

Example(s): Confirmed:4.1.3.2:Ubuntu, Confirmed:4.1.3.2:Windows7, Confirmed:4.2.0.1:OSX

Use: Not frequently used but can be used when wanting to add more information to a confirmed bug. Should always include “Confirmed:” and then version and OS (see examples above).

BibisectedNewer

Description: Used in cases where a bug has been confirmed to be a regression but the regression occurred after the last commit in the latest bibisect package.

Use: If a regression is confirmed on master or on a recent daily build then it's likely going to be too new to be bibisected. QA should still try to bibisect the bug just in case the bad commit is within the bibisect range.

BibisectRequest

Description: Used to let us know that a bibisect is needed.

Use: All confirmed regressions after 3.5.0 should have a BibisectRequest whiteboard status unless the bug is specific to Windows (which should be confirmed prior to removing a BibisectRequest). Many bugs that affect Windows will also affect Linux and OSX so they can be bibisected successfully.

ConfirmedRegression

Description: Is used if a bug is confirmed to be a regression.

Use: If a bug is confirmed to be a regression then a user, QA, or developer can put ConfirmedRegression into the whiteboard. If this is done the individual should also put in the comments what version worked (and is confirmed to have worked) and what version does not.

DifficultyBeginner

Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that not only is the bug an easy hack, it is “really easy” and can be done by individuals who have beginner skills in computer science.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

DifficultyEasy

Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that the bug is fairly easy but not quite easy enough for beginners.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

DifficultyInteresting

Description: Developers add this to easy hacks (see EasyHacks whiteboard status) to indicate that while the bug is considered to be an easy hack by our experts, it could be quite challenging for a new developer on the project. Generally people who tackle these should be relatively comfortable with programming generally.

Use: Used exclusively by developers who have done the work (provided code pointers) to move the bug to an easy hack.

NeedsSOFTWARE

Description: Used to highlight a particular piece of software that is required to triage the bug.

Use: Only used for unique software requirement. Not appropriate for “NeedsMicrosoftOffice” as Microsoft Office is relatively common but if the bug only affects MicrosoftOffice2013 then using “MicrosoftOffice2013” is appropriate. Also not appropriate for “NeedsWindows” (setting version to “Windows(all)” is sufficient, but if a particular version of Windows is needed (such as XP) it is appropriate.

Examples: NeedsAlfresco, NeedsDuplexPrinter, NeedsWebDAV, NeedsWindowsXP


No Longer In Use

Really no longer in use – please do not use these status'

Accessibility

Description: Replaced by a11y – see description there.

Use: No longer used. Replaced by a11y.

bibisected35older

Description: Was used to indicate that the bug was present before the bibisect35 package.

Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see LINK

here.

bibisected35

Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect35 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see LINK

here.

Use: No longer used. Replaced by “bibisected”.

bibisected36

Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect36 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.


Use: No longer used. Replaced by “bibisected”.

bibisected35newer

Description: Was used in the past to say that a regression was introduced after the bibisect35 package.

Use: No longer used.

bibisected36older

Description: Was used to indicate that the bug was present before the bibisect36 package.

Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.

bibisected40

Description: Replaced by “bibisected”. Was used in the past to say that the bug was bibisected with the bibisect40 package. This package is now incorporated into the bibisect 43all package. For information about bibisect see here.

Use: No longer used. Replaced by “bibisected”.

bibisected40newer

Description: Was used in the past to say that a regression was introduced after the bibisect40 package.

Use: No longer used.

bibisected40older

Description: Was used to indicate that the bug was present before the bibisect40 package.

Use: No longer used. Replaced by a new version field “PreBibisect.” If a bug is present before the earliest bibisect commit – set the version to “PreBibisect” and leave a comment explaining the change. For more information about bibisect see here.