Description of problem: See https://lists.fedoraproject.org/pipermail/devel/2015-November/216400.html Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: There should be a "lightweight" clone button that will just copy the absolute minimum of information from the upstream bug into the downstream bug. Additional info:
A better solution would be to make the default "Clone This Bug" button lightweight, and have a new button "Clone Everything" that would clone in the same manner as the current "Clone This Bug" button. I expect more people will chime in here to describe exactly what does and does not need to happen when we clone an upstream bug to downstream.
Hi Rich, changing the current behaviour would require us getting the stake holders to agree. Adding a "clone lite" would require an if condition, a menu entry, some tweaking, and a list of things that have to be cloned. i.e. "the absolute minimum of information" actually needs to be specified. Given no one else has spoken up, maybe you just want to specify what you would like. :)
Well, I was hoping people who are troubled by cloning would chime in here and provide more information, but they didn't. So if you want to leave this bug open in the hopes that someone will provide a decent feature request, that's fine, and if you want to close this as WONTFIX, that's fine too.
Hard for people to 'chime in' if they don't know about the bug... The biggest issues when cloning for me are: 1) that the entire chain of comments on the original is dumped into the new bug as its 'Description' 2) that everyone CCed on the original is CCed on the clone 3) that the Blocks:, Keywords: and Whiteboard: fields are copied, as this means RHEL bugs wind up being Fedora release blockers or listed for entry on the Fedora common bugs page, etc (all the stuff we track with those BZ metadata fields) It's a bit tricky to say "this is what must be" because there are various use cases for cloning, I guess. But the very common case for RHBZ is 'cloning' a bug from Fedora to Red Hat. It might be nice to have a cloning workflow for this case which at least doesn't do 2) or 3). 1) is more of a general thing; I guess in my ideal world the user would be asked whether they want to clone just the original Description or all the comments too.
"Copy bug" shall: 1: copy the original comment #0 2: add a link to the original bug (external tracker?) 3: there is no 3, just visit the other bug if you want to read more, or use clone if you want a lot of things copied.
I agree with Jeff and Adam. :) Additionally, IMHO, it would be nice if either 'copy bug' or 'clone bug' required a additional comment to be added, and had a template in it with something like: "I am copying/cloning this bug because: " or the like.
Tested on QA environment Result: Pass Steps: Added a new link 'copy this bug' which will copy: summary, comment #0 With template: This bug was initially created as a copy of bug #****
This change has been deployed to partner Bugzilla [1] for pre-release testing, if your testing reveals any issues please update this bug. 1: https://partner-bugzilla.redhat.com/
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug.