Hi Joel, all
jmadero wrote > The problem really is that at least *I* do often time request users to > go back and install older versions to help narrow down where a > regression was introduced. This is particularly useful when a user is > complaining about their regression not getting love - at this point I > start heavily suggesting they do some of the lifting themselves to move > it forward (bibisect themselves, if that's not possible to go back and > install older versions and try to narrow down to a beta/rc where the > issue was introduced). I've actually found this to not only be useful > for the particular bug but also useful in recruiting new people. I don't see any incompatibility in asking people to use several versions (actually I do that using Portable versions of LibreOffice from WinPenPack) and reducing the number of versions in the drop list. If a user is able to tell that a bug was introduced between 4.0.0 and 4.0.1, a bibisect in that range should be able to find the problematic commit/patch? What would be the advantage to have the user install 4.0.0 Beta1, Beta2, RC1, etc? Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Bugzila-4-3-x-versions-cleanup-tp4167758p4167859.html Sent from the QA mailing list archive at Nabble.com. _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
