@Mal, It is really rather simple, with a code base of several million lines, isolating the source of a regression or anti-feature becomes important both in triaging an issue and especially for isolating the problem in source code. That point of first introduction comes with the earliest build -- not the most recent release.
Every commit to LibreOffice and the OOo source before that is recorded--and it is possible both to review exact changes that cause a problem--the challenge is isolating the issue. >From a QA/triage perspective knowing the release build (or the daily build for contemporary work in the master branch) lets us dig deeper into the code. When we can include a fully bisected description -- i.e. prior to this commit it was fine, after this commit it has gone bad -- the developers have more incentive and a much better chance of locating the exact issue, and then deciding on cost of fixing it. The fix could be a single conversion factor, or could be hundreds of lines of refactored source code--some things are trivial, some things are not justified. But before that can be determined the cause has to be isolated--and that can only be done at the earliest occurrence. One of the reasons the project keeps the archive of prior releases available for folks to install in parallel and test--knowing the earliest occurrence is key. Stuart =-refs-= http://downloadarchive.documentfoundation.org/libreoffice/old/ https://wiki.documentfoundation.org/Installing_in_parallel -- View this message in context: http://nabble.documentfoundation.org/Question-on-bugs-tp4172959p4172968.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
