[Libreoffice-qa] Bug Fixed in 4.2 branch, broken in 4.1 daily, status thoughts?

[V Stuart Foote]

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.