Closed Bug 36133 Opened 25 years ago Closed 24 years ago

bug-swapping between multiple instances of bugzilla

Categories

(Bugzilla :: Bugzilla-General, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
Bugzilla 2.12

People

(Reporter: dmosedale, Assigned: endico)

Details

(Whiteboard: 2.12)

Attachments

(5 files)

On developer day, I promised to look into the possibility of running multiple instances of Bugzilla and allowing bugs to be swapped between them. I've done some thinking on this, and talked to a few people, and I think this is something that we would like to do. This is not something that I can devote effort to immediately, but I should be able to spend some time on it in a couple of months. A reasonable way to go about this probably involves serializing a bug into XML and then sending it across the network and deserializing it (parallelizing it? :-). A large part of the motivation for this relates to the ability for folks who have written their own packages based on Mozilla to be able to keep track of their bugs in their own instance of Bugzilla, which still being able to move bugs that are truly in the core code back to the mozilla.org instance with ease. There was also concern about the number of Netscape 6 bugs being (incorrectly) filed in bugzilla.mozilla.org. My hope is that this number has gone down significantly since Netscape fixed their feedback form.
So does this imply that the original bug that got moved would then be synced with the active bug on bugzilla.mozilla.org, and not merely copied?
My plan was that a new resolution would be create, called RESOLVED: MOVED, and link would be provided to the new copy of the bug. That is, it would be similar to a DUP bug and would not be kept in sync.
Status: NEW → ASSIGNED
Dawn is now taking this on; reassigning to her.
Assignee: dmose → endico
Status: ASSIGNED → NEW
Yes... 1) Need to a MOVED resolution in. 2) endico working on a script to at least mail bug info to our INBOX for easy paste into a Bugscape bug. 3) Need to see if we can query from Bugscape and see all Bugzilla related bugs for query also.
Dawn - how's this going? :-) I've downloaded and installed Bugzilla myself now, so if you want any testing doing, I might be able to help :-) Gerv
Attached patch bug moving patch (deleted) — Splinter Review
The bug moving code should be fairly usable by now. The code i have so far is checked in with the exception of changes to three existing bugzilla files which are included in the attached 06/13/00 10:36 patch file. Things that are still lacking include: 1) there's no way to configure this yet. We need to be able to set a list of sites that we exchange bugs with and a list of people who are able to move bugs to each site. Presently, this is hard coded into the script. 2) This code mails xml formatted bugs to a given email address and provides importxml.pl that reads the message and enters the bug into the target db. Whoever sets this up will have to provide a mechanism to notice bug emails and run the import script. 3) This doesn't yet change the state of moved bugs. For now you'll want to change the moved bugs to closed by hand. Eventually I want to make a new bug status called 'moved'. If you're one of the lucky ones blessed as a bug mover you'll see an additional 'Move to Bugscape' (this needs to be configurable too) button on show_bug pages and on the "move many bugs at once" pages. Right now pressing this button only generates an email it doesn't actually make any changes to the bug since importing still has to be done by hand. If you want to use this incomplete code for moving real bugs then for now, the person importing bugs should go back to the original bug, close the bug out and add 'moved' to the status whiteboard so we can identify bugs later that need to have the status changed to closed. This code is checked in but its not installed on bugzilla.mozilla.org yet.
Status: NEW → ASSIGNED
Dawn - are you continuing work on this, or would you like me to hack at it a bit? :-) Gerv
Gerv, yes i'm continuing to work on it but feel free to play with it. The prototype bug moving code is installed on bugzilla.mozilla.org now. I've set up an aka alias called bugscape-import@netscape.com. So far the way it works is this... If you're looking at a bug or at the "change several bugs at once" page and you're logged in as leger, lchiang, endico or dmose, you will get a "move to bugscape" button. Pressing this button writes up the bug(s) as xml and mails it to bugscape-import@netscape.com. That's it so far. Nothing actually happens to the bug on bugzilla. Its not marked closed or anything. That's not implemented yet. For now its safe to test this code without mucking up bugs. For now the bugscape-import alias sends mail to me. I made Namachi a co-owner of this AKA alias and I expect him at some point to create an alias on bugscape.netscape.com and subscribe this to alias to bugscape-import. To import bugs, pipe a bug message from this alias into importxml.pl which will create a new bug in bugscape for each bug in the mail file as long as the person who moved the bug has an account on bugscape. Once you've verified this works you'll want to set up the alias to do this automatically. There is a bug in the moving code. It 'moves' all bugs on the bug list page, not just the checked ones. This code doesn't move attachments, although it does make a note of them. A quick fix would be to hack importxml.pl to print out the attachment url from the original db and let people look at it there.
Dawn - let me know if/when you actually want me to try this out or to test this. Thanks.
shiva, you'll want to apply this patch to change bugscape's default product for (for bugs with unknown products). Per Jan's mail from this morning. In the long run the best answer is to make this configurable. I haven't actually tested this. Make sure there's not a problem here with product names that contain whitespace. Index: importxml.pl =================================================================== RCS file: /cvsroot/mozilla/webtools/bugzilla/importxml.pl,v retrieving revision 1.3 diff -r1.3 importxml.pl 245,246c245,246 < $values .= "\'Browser\',\n"; < $product[0] = "Browser"; --- > $values .= "\'From Bugzilla\',\n"; > $product[0] = "From Bugzilla"; 248c248 < $err .= "Moving to default product \"Browser\".\n"; --- > $err .= "Moving to default product \"From Bugzilla\".\n";
I have applied the changes to importxml.pl. It looks like the first condition becomes true as a result the bug is assigned to Product 'Browser' and the first component 'Activation'. Please verify? Also I am getting some parsing errors. my @product; if (defined ($bug_fields{'product'}) && (@product = grep /^$bug_fields{'product'}$/i, @::legal_product) ){ $query .= "product,\n"; $values .= SqlQuote($product[0]) . ",\n"; } else { $query .= "product,\n"; $values .= "\'From Bugzilla\',\n"; $product[0] = "From Bugzilla"; $err .= "Unknown product $bug_fields{'product'}. "; $err .= "Moving to default product \"From Bugzilla\".\n"; }
Attached patch replacement bug moving patch (deleted) — Splinter Review
this patch adds a new bug status 'MOVED' and changes bugs to this status when they are moved. The bug display page restricts unblessed people from reopening new bugs. (the change multiple bugs page does not yet). Moving multiple bugs at once is fixed now and only checked bugs are moved.
I've checked in a new version of importxml.pl which now works correctly when invoked by a sendmail alias. Also included a comment at the top of the file explaining how to set up this alias. When I hear from Shiva that this is working on bugscape I will leave testing mode and apply the patches to bugzilla that set moved bugs to the moved state. Note that keyword handling isn't implemented yet. Keywords from the original bug are noted in a comment in the new bug but aren't actually inserted into the keywords field. (yet) We need to go through the list of keywords and set ones that exist in the new database and make a note of those that don't.
Attached patch the latest patch (deleted) — Splinter Review
oops ignore the 06/29/00 13:14 patch. It has a bug where people who are able to move bugs can't comment on them because it moves the bug instead. This patch sets moved bugs to a new status 'moved' which puts bugs in a state where they can't be re-opened. (since the bug actually lives in the other instance now). A bunch of stuff that used to be hard coded in is now configurable via params. You need to synch with the tip for this to work. (or at least importxml.pl) See the test implementation at http://landfill.bluemartini.com/bugzilla/show_bug.cgi?id=17 although you can't move bugs unless you've been blessed, and even so, pressing the move button only sends the bugs to me, not to another bugzilla. Also, landfill can't be set up to receive bugs.
Moving is a resolution. You hint so yourself: <blockquote>'moved' which puts bugs in a state where they can't be re-opened.</blockquote> Resolutions are semi-permanent, status usually isn't. Nitpick, <embed content-type=text src='internet explorer'> ------- Additional Comments From endico@mozilla.org <mailto:endico@mozilla.org> 2000-06-29 16:36 ------- Bug moved to <http://beefaroni.splot.net/> by endico@mozilla.org <mailto:endico@mozilla.org>. </embed> The mover's name isn't needed more than once, and that can be in the Additional Comments From <mover> header The comment need only include the destination Bug moved to <dest> as <bug#> See also the format for importing to bugzilla from bugscape or the other old systems (I don't know their bug numbers).
i already (just) removed the extra 'mover' address. when you move a bug the comment is 'Bug moved to http://blah.com/' As I said, 'moved' is special because it puts bugs into a state where they can't be reopened (since the bug actually lives in the other instance now). Therefore it should be a status. Lisa, speak up if you disagree. You mentioned something earlier about verifying moved bugs.
I had said that if "moved" is a status, then there should be a corresponding resolution so that the field is not empty. It may be good to "verify" a moved bug so that the bug doesn't get moved in error and thus can be reopened. What do you think, Dawn?
Attached patch 'MOVED' is now a resolution (deleted) — Splinter Review
Changes I've made since the last patch: Moved is now a resolution, not a status. I added some words to the "bug moved to" message in moved bugs noting that its the responsibility of the bug mover to verify that the bug moved successfully and to paste in the new bug number (which they recieve by mail after the bug is imported). Hopefully this can be automated some day. "View Bug Activity" now correctly shows bug movement. Keywords are now handled. If the old keyword exists in the new db then the keyword is set, otherwise a note is added to the comment. Attachments still aren't handled. The status of moved bugs isn't changable (except by admins) from show_bug.cgi, however I neglected to add this check to the 'change multiple bugs at once' screen so it is possible to re-open moved bugs after all.
Move test between amok.netscape.com/bugzilla and bugscape.mcom.com is successfuly working. It creates bug properly in the destination database and mails the reporter. dawn is working on applying the move changes to bugzilla. After that lchiang and leger can test the system.
Dawn - when will attachments be handled?
It looks like the resolution is not turning up on the query screen, so you just see "RESO " instead of "RESO MOVE". See bug #45205 for example.
lisa: i don't have any plans to handle attachments soon. do you have a lot of attachments to move? matthew: worksforme
dawn: I never know what may be attached to a bug report :-) If move of attachments is not going to implemented in this first rev, can you include some text in the moved bug to let the user know that attachments aren't moved and the attachments, if any, would have to be manually saved to the local system and then re-attached to the bugscape bug?
Problem can be seen at the last row of: http://bugzilla.mozilla.org/buglist.cgi?bug_status=RESOLVED&product=Webtools which is for me: 45205 2000-07-11 asa@mozilla.org RESO Webtools 0 M18 yet another bug moving test bug
Err, by "query screen" I meant bug_list.cgi, not query.cgi.
Lisa: attachments aren't completely ignored. Their existance is noted, (in an error message) but they aren't actually transferred. Is this enough to alert you to go back and move the attachment by hand? for example: http://amok.netscape.com/bugzilla//show_bug.cgi?id=43841 --- Unknown bug field "attachment" encountered while moving bug <attachment> <attachid> 10644 </attachid> <date> 07/11/00 18:57 </date> <desc> flameon.png </desc> </attachment>
matthew's problem is due to the fact that the shadow database isn't synced with the main db and doesn't know about the moved status yet. I've changed configure.pl so this shouldn't happen again in the future. This inconsistancy is harmless and there's only one moved bug so far. Since syncing the db is brings bugzilla to its knees i'll wait for the problem to fix itself when the normal nightly db sync happens tonight.
dawn - the status text you add for attachments is fine. Thanks.
Just stabbing at the dark here, but would a "bug copy" facility ever be useful as well as move?
Matt - we decided "bug copy" was too dangerous as the copies would get out of sync. You can always move it back, after all. Dawn - is this code now checked in and "finished", from your point of view? Gerv
if it's finished, please close. thanks. marking 2.12
Whiteboard: 2.12
importxml.pl should set the 'everconfirmed' flag when the Status is different from UNCONFIRMED. Otherwise, when an imported bug is reassigned, it gets into state UNCONFIRMED instead of NEW. See also bug#32398
ping endico... is this done? cyeh said to close, but no one did. There's since been a comment about a bug in the moving code. Maybe this should be closed and that be a new bug report? Or should that be fixed before this is closed?
this works. if there are functional bugs, open new ones for that
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Sorry for the spam, but I needed to be able to query for all of these correctly.
Target Milestone: --- → Bugzilla 2.12
VERIF, seeing as this was a feature request bug, and new bugs should be opened for any problems with it. Gerv
Status: RESOLVED → VERIFIED
Moving closed bugs to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: