On 12/01/2015 10:16 AM, Christian Lohmaier wrote: > > 5.0.0.3 and 5.0.0.4 beta2: 42 > between rc3 and rc4 > > As long as the merge-to-one-version indicates what version was set > prior to the unification, I don't see the information loss, but it > should be a standardized comment, so that you could still use queries > for those versions. Ah I see the confusion here. I'm talking about cases where _after the merge happens_ we are asking users to go back and download archived versions to try to narrow down where their regression was introduced. I agree that if the version was already set to begin with then it's not a big deal, but after the merge happens, if we're asking users to "narrow down the regression 'as much as possible'" but then we are taking away their ability to actually set the version...that seems like a problem and pretty confusing.
This is why the 6 month rule IMHO makes sense. This gives QA 6 months to triage the bug, try to determine if it's a regression, and try to get users to assist as much as possible by narrowing down the version to the most precise possible (absent bibisecting/bisecting). After 6 months it probably is a lot less likely that the user would care enough to test the bug against older versions so it makes sense to purge at this point. 2-3 months turnaround is IMHO too short when it can take 60 days just to triage the bug (before there is a single touch by QA). Best, Joel
_______________________________________________ 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/
