jmadero wrote > This is a general problem that I think we shoudl just talk a bit about. If > we confirm a bug on 4.1 but it's fixed in 4.2 master - what status is > appropriate?
Joel, As the support tail continues to stretch us thin, performing QA bug triage and commenting Works for Me (noting specific build details of course) really does seem the correct action for issues against earlier releases but that are proven functional in current developmental builds. I see it as in the best interest of moving the project along on all fronts. I really think the more useful QA action, as you attempted, is to assist the original poster, and any collaborating reporters, to test that fixes available in daily builds of master (currently 4.2.0.0alpha0+), or of the daily master of pending releases (currently 4.0.5.0, or 4.1.0.0 beta2+), does actually fix the bug for them and to document so in Bugzilla or to otherwise facilitate involvement of the devs. While we can't ask every user to start using the latest daily build--for specific issues we should expect a user originating an issue to do so--and thereby allow our QA process to verify the fixes pushed out by devs are valid. Even if there is no probability the patch will be backported to an earlier release. The reporting user then having seen that it works, can decide if the newer build is more useful to their needs. Also keep in mind that the devs may mark a bug Resolved Fixed but then annotate a Whiteboard target value for it, e.g. "target:4.0.5, target:4.1.1", for a 4.0.3.3 bug they've fixed but that won't be pushed down to 4.0.4. As active QA participants I see nothing wrong in reading that annotation and then telling a user "so it'll be broken for the foreseeable future but by 4.2 release you'll be good to go" if that is the way the dev sees it. But, if we find it to be a really serious issue, we can elevate the importance, or add it to MAB for the affected release and solicit ESC discussion. I don't believe these normal QA actions are that off putting to those users that actively track issues they've reported. The process does meet expectations of users and developers who both need the feedback. I see my role in QA as facilitating the flow of detailed information in both directions. Stuart -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Bug-Fixed-in-4-2-branch-broken-in-4-1-daily-status-thoughts-tp4061558p4061572.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/