Robinson Tryon wrote > Sure. That's us running into the limitations of Bugzilla, really. > [...] > Bugzilla isn't quite that customizable.
Hi! Disagree. It is only the way how this project use (or rather not use) Bugzilla features. To solve the issues mentioned I would propose using flags. Robinson Tryon wrote > And the backportRequest:X.y tag is a very specific way for us to > communicate our intentions with the developers. > [...] > We don't currently have a way to indicate a status for each branch > that's active, but if we were to add that, then we could say NEW for > 4.4 and RESOLVED for 4.5. I'm not sure of the best way to add that > without making things more confusing... Bugzilla isn't quite that > customizable. Branching. Lets imagine we have active flags for following current LO branches (it is an example, so do not validate the versions or naming please): - target4.5 - target4.4 - target4.3 A joedoe commits a patch to 4.5 and 4.4 branches. Gerritbot could set the flags automatically (instead of whiteboarding): - target4.5 + - target4.4 + - target4.3 _ (unset) We want the patch to be backported to 4.3, as this is serious bugfix and 4.3.7 slot is available. To request this we set flag target4.3 to ? requesting an action from a commiter (if he has the Bugzilla account - IMHO he should have one to Assign the bug to himself). He do not have time so he denies it by setting a flag to target4.3 -. The bug has the following flags set in the end: - target4.5 + - target4.4 + - target4.3 - Affected branches. To indicate which branch is affected one could set the following flags: - affected4.5 + - affected4.4 + - affected4.3 + All those flags give us information which branches got fixed and which not. If archive flags would be shown (for inactive branches), this could help the bibisecters: - affected4.5 + - affected4.4 + - affected4.3 + - affected4.2 - Why this is better than whiteboard? Flags are sortable, visible by product/component, you don't need to type long strings, we know who set the flag, developers see the requests in My request tab, we can search the flags (https://bugs.documentfoundation.org/page.cgi?id=quicksearch.html#advanced_examples) - just imagine that there could be a flag:target4.3? or flag:target4.3- saved search or whine to find people who can backport it. For me this would be far better workflow than abusing whiteboard, where you can type everything (and I see that more and more informations go there). With flags, those can be made inactive, so you cannot set them or deleted if you do not care about them anymore or just not visible in the UI. Not mentioning the security options to request and grant them... One could also decide that there should be full version history - target4.3.x scheme used to indicate the specific release. Hope it helps. Best regards. P.S. I can imagine that flags could be used for many other things like requesting: - a documentation update - moztrap test - relnotes update - bibisecting etc. P.S.2 There is a chance that Bugzilla will deal better with branches when Sightings feature is ready - see https://bugzilla.mozilla.org/show_bug.cgi?id=55970. Unfortunately this is very old bug... -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-On-the-topic-of-Backporting-bugs-fixed-on-master-tp4138618p4138627.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/