Michael Meeks-2 wrote > > The reason I graph regressions each week is to try to add focus there; > if you can think of another more encouraging way - that'd be > appreciated. > Hi. Unfortunately those graphs are discouraging in many ways. Especially if one thinks about upgrading LO...
Michael Meeks-2 wrote > > We (the ESC) made a strategic > decision to take some regressions there - in order to have much greater > sharing of the filter code, such that we have less code, and hence our > bug fixes have more impact across all Microsoft import and export > filters. > Does QA OKeyed this decision? What QA actions were taken before such move? Regression tests prepared? Any tests in general? Manual tests? Michael Meeks-2 wrote > > There is testing before committing. > Tests as regression tests or tests as is it green on tinderbox or it builds on commiter's computer? Michael Meeks-2 wrote > > One strategic thing we -badly- need is the ability to get stack traces > with full symbols out of QA. With > that information we can double or better the productivity of bug fixing > - without it we are half-blind. > I am starting to doubt that it helps. I recently delivered Windows bt to most crash bugs I could find. Prepared wiki page about it. Asked for review of that page. Silence. Few of the bugs were fixed, without any comment if my bt was useful. Will keep this work, but I don't see that bugs with bts are fixed quicker. Michael Meeks-2 wrote > > Fridrich has been working on getting stack traces / symbol servers > setup for Windows for the last several months; he is currently on > vacation - no doubt he'll give an update on that when he gets back. It > is an enduring frustration to me to be missing that piece. > I think I put few cents for this myself on ML and trying to gather nice resources in bug https://bugs.freedesktop.org/show_bug.cgi?id=50350. Someone is working on it? Great. It is still UNCONFIRMED... Michael Meeks-2 wrote > > It's really not clear to me what you're looking for: surely you're not > asking for the whole project to stop working on features, and focus > exclusively on bugs for a year ;-) that seems an unrealistic expectation > to me - we have to move forward as well as fix our huge legacy of bugs, > as well as the new bugs we create. > I would be happy if I achieve the change in base workflow - new feature in the codebase? Splendid! But unit tests, testcases and manual testing done before commiting. QA OKeyed the feature? Then you can commit. Focusing exclusively on bugs in one of next release (be it 3.7 or 3.8) would be a great idea, as please remember - a feature is a no go, when there are still 123bugs (123bugs as one, two, three actions needed to get LO crash). Also, if I understand correctly, from 3.7 there will be a possibility to introduce working patches from a sister project. It would be great to bury the hatchet and improve both kids at once. Best regards. -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Fwd-tdf-announce-The-Document-Foundation-announces-LibreOffice-3-6-with-a-wealth-of-ns-tp4000177p4001009.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/
