Closed
Bug 36133
Opened 25 years ago
Closed 24 years ago
bug-swapping between multiple instances of bugzilla
Categories
(Bugzilla :: Bugzilla-General, defect, P3)
Tracking
()
VERIFIED
FIXED
Bugzilla 2.12
People
(Reporter: dmosedale, Assigned: endico)
Details
(Whiteboard: 2.12)
Attachments
(5 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•25 years ago
|
||
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?
Reporter | ||
Comment 2•25 years ago
|
||
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
Reporter | ||
Comment 3•25 years ago
|
||
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.
Comment 5•24 years ago
|
||
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
Assignee | ||
Comment 6•24 years ago
|
||
Assignee | ||
Comment 7•24 years ago
|
||
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
Comment 8•24 years ago
|
||
Dawn - are you continuing work on this, or would you like me to hack at it a
bit? :-)
Gerv
Assignee | ||
Comment 9•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
Dawn - let me know if/when you actually want me to try this out or to test this.
Thanks.
Assignee | ||
Comment 11•24 years ago
|
||
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";
Comment 12•24 years ago
|
||
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";
}
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Comment 14•24 years ago
|
||
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.
Assignee | ||
Comment 15•24 years ago
|
||
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.
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
Assignee | ||
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
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).
Assignee | ||
Comment 20•24 years ago
|
||
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.
Comment 21•24 years ago
|
||
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?
Assignee | ||
Comment 22•24 years ago
|
||
Assignee | ||
Comment 23•24 years ago
|
||
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.
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
Dawn - when will attachments be handled?
Comment 26•24 years ago
|
||
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.
Assignee | ||
Comment 27•24 years ago
|
||
lisa: i don't have any plans to handle attachments soon. do you have a
lot of attachments to move?
matthew: worksforme
Comment 28•24 years ago
|
||
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?
Comment 29•24 years ago
|
||
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
Comment 30•24 years ago
|
||
Err, by "query screen" I meant bug_list.cgi, not query.cgi.
Assignee | ||
Comment 31•24 years ago
|
||
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>
Assignee | ||
Comment 32•24 years ago
|
||
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.
Comment 33•24 years ago
|
||
dawn - the status text you add for attachments is fine. Thanks.
Comment 34•24 years ago
|
||
Just stabbing at the dark here, but would a "bug copy" facility ever be useful
as well as move?
Comment 35•24 years ago
|
||
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
Comment 37•24 years ago
|
||
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
Comment 38•24 years ago
|
||
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?
Comment 39•24 years ago
|
||
this works. if there are functional bugs, open new ones for that
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 40•24 years ago
|
||
Sorry for the spam, but I needed to be able to query for all of these correctly.
Target Milestone: --- → Bugzilla 2.12
Comment 41•24 years ago
|
||
VERIF, seeing as this was a feature request bug, and new bugs should be opened
for any problems with it.
Gerv
Status: RESOLVED → VERIFIED
Comment 42•23 years ago
|
||
Moving closed bugs to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•