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/
