[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #17 from tromey at gcc dot gnu dot org 2010-02-11 20:18 --- It would be really great if someone would update the sourceware.org bugzilla at the same time, so we could run a single version on the machine. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #18 from LpSolit at netscape dot net 2010-02-11 20:23 --- (In reply to comment #17) It would be really great if someone would update the sourceware.org bugzilla at the same time, so we could run a single version on the machine. Wow, http://sourceware.org/bugzilla/ runs Bugzilla 2.17.5, a development snapshot which was released in November 2003 and which got replaced the week after by 2.17.6 because it had a security hole. You guys like to live dangerously. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #19 from dberlin at gcc dot gnu dot org 2010-02-11 20:44 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 It has the security patch ;) None of this would have been a big deal if it hadn't taken bugzilla 10 years to decide on custom fields ;) THe main changes in both bugzilla is to remove the opsys/platform fields and add our triplet fields. On Thu, Feb 11, 2010 at 3:23 PM, LpSolit at netscape dot net gcc-bugzi...@gcc.gnu.org wrote: --- Comment #18 from LpSolit at netscape dot net 2010-02-11 20:23 --- (In reply to comment #17) It would be really great if someone would update the sourceware.org bugzilla at the same time, so we could run a single version on the machine. Wow, http://sourceware.org/bugzilla/ runs Bugzilla 2.17.5, a development snapshot which was released in November 2003 and which got replaced the week after by 2.17.6 because it had a security hole. You guys like to live dangerously. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #20 from LpSolit at netscape dot net 2010-02-11 20:58 --- (In reply to comment #19) None of this would have been a big deal if it hadn't taken bugzilla 10 years to decide on custom fields ;) No comment! :-D THe main changes in both bugzilla is to remove the opsys/platform fields and add our triplet fields. Porting triplet fields should be trivial to do. About the OS/platform fields, we only need to hide it from the UI and let Bug.pm ignore them. I did it once already, for another Bugzilla, and it's really easy. Daniel, how do you plan to do the upgrade? I'm willing to help, but we need a test installation and all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #21 from LpSolit at netscape dot net 2010-02-11 21:03 --- About merging both Bugzilla installations into a single one, the problem is about bug IDs. They would conflict. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #22 from tromey at gcc dot gnu dot org 2010-02-11 21:05 --- Yes, I think we should not merge the databases. All I meant was that we should have a single version of the code running. And, when upgrading, upgrade both instances at the same time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #23 from LpSolit at netscape dot net 2010-02-11 21:08 --- (In reply to comment #22) All I meant was that we should have a single version of the code running. That's doable, see http://www.bugzilla.org/docs/tip/en/html/multiple-bz-dbs.html. Can someone confirm this bug? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-11 21:08:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #16 from LpSolit at netscape dot net 2010-02-10 19:48 --- (In reply to comment #15) No such check for adding comments from email replies, but adding a comment doesn't require privileges (and the password for an autocreated account is of course sent to the email address for that account, so an impersonator won't get the password). I don't know about the functionality for doing anything else by email. Newer Bugzilla releases no longer send you an email with your password in it. They send you an email with a URL in it which brings you to a page where you enter your name and password (this avoids creating fake accounts with invalid or undesired email addresses). About what you can do by email, newer releases let you edit almost all aspects of bugs, including the CC list, assignee, severity, priority, bug status and resolution, etc... etc You can even attach files if you want to (in Bugzilla 3.6). :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-09 19:54 --- I cannot find the emails saying why this has not been done yet but I remember the issue comes down to custom fields which need to be moved correctly over to the new version of bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #2 from LpSolit at netscape dot net 2010-02-09 19:58 --- (In reply to comment #1) I cannot find the emails saying why this has not been done yet but I remember the issue comes down to custom fields which need to be moved correctly over to the new version of bugzilla. Well, from what I can see, this is trivial enough to port. You only have one drop-down field (Reported against) and five free text fields (Known to work, Known to fail, Host, Target, Build). Both types exist in Bugzilla 3.4. I can certainly help if you need some help with the upgrade (I am one of the main developers of Bugzilla). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #3 from joseph at codesourcery dot com 2010-02-09 20:18 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 I think the call for volunteers at http://gcc.gnu.org/ml/gcc/2008-03/msg00276.html still applies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #4 from LpSolit at netscape dot net 2010-02-09 20:22 --- Hey Daniel, still need some help? :) -- LpSolit at netscape dot net changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #5 from joseph at codesourcery dot com 2010-02-09 20:33 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 There may be a few local code changes (Daniel mentioned email handling) to carry over (it's quite possible newer versions don't need code changes for whatever the local changes do, but have some better way to achieve the desired effect), as well as converting the database schema. I expect we can get you a copy of the database if you'd like to help with the conversion. As for the code changes, our Bugzilla code is all in CVS http://gcc.gnu.org/cvs.html so you can check it out and see exactly what local modifications have been made. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #6 from LpSolit at netscape dot net 2010-02-09 20:45 --- Hard to see all the changes made to 2.20 via CVS. Is there a patch somewhere done against vanilla Bugzilla showing all the customizations which have been done? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #7 from jsm28 at gcc dot gnu dot org 2010-02-09 21:01 --- Created an attachment (id=19830) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19830action=view) Local Bugzilla changes Here's a diff generated with cvs -z9 diff -uN -rBUGZILLA_2_20 -rHEAD. There are some oddities - cases where there appear to be GCC-related things both before and after the diff - that could relate to CVS peculiarities of some kind, or to BUGZILLA_2_20 not quite being a tag for unmodified upstream. So checking out the sources and generating a diff from a vanilla 2.20 release tarball may be safer to show exactly what's changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-02-09 21:09 --- Created an attachment (id=19831) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19831action=view) Diff from tarball Here is a larger, probably more accurate diff generated using a release tarball. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #9 from joseph at codesourcery dot com 2010-02-09 21:15 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 I think we agreed some time ago to remove the gccbug script - if we do that then we shouldn't need to bring over anything related to processing incoming GNATS-formatted email submissions (just make the gcc-gnats address bounce with a pointer to Bugzilla). So that may reduce the extent of local code needing porting to a new Bugzilla version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #10 from LpSolit at netscape dot net 2010-02-09 21:44 --- Could someone having access to the Bugzilla server install the PatchReader Perl module? It's way easier to read patches this way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-02-09 21:45 --- (In reply to comment #10) Could someone having access to the Bugzilla server install the PatchReader Perl module? It's way easier to read patches this way. I think it is already installed, just the attachments need to be marked as patches which I just did. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #12 from LpSolit at netscape dot net 2010-02-09 22:11 --- The changes in the core code do not look too terrific and should be easy to port (some of which are now useless in the 3.4 code). I guess most changes in contrib/bug_email.pl can go away now that we have email_in.pl, but I have no idea what the Python and other Perl scripts in contrib/ are doing. Note that many of the existing scripts in contrib/ are now gone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #13 from joseph at codesourcery dot com 2010-02-10 00:20 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 The main email-related functionality for GCC is: all bugs in the gcc product automatically get CC:ed to gcc-bugs@gcc.gnu.org (maybe other lists depending on the component, or for other products). Email replies get body and attachments automatically entered in the relevant bug, with an account created for the sender if they didn't already have one. If you preserve that, most of the important email handling functionality is there. There is I think some mechanism for other bug manipulations by email, but I don't think many people (if any at all) use it. contrib/regress-submit.pl might once have been used for automatic bug submissions by regression testers, but there hasn't been such submission for years, so I think it can be ignored. User accounts with email addresses @gcc.gnu.org automatically get some extra privileges. I don't know where this is configured. As noted, we can reasonably kill gccbug and so ignore anything related to GNATS. As discussed, there are various new fields added to GCC Bugzilla - while some of the standard Bugzilla fields are removed as inapplicable (build / host / target is the proper way of describing the platform where a GCC bug is observed). There are also some changes to the set of states a bug can be in. Hopefully the conclusion will be that we don't need GCC-specific scripts in contrib/ but can preserve the various GCC-specific logic (possibly implemented in a better way using newer 3.4 infrastructure). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #14 from LpSolit at netscape dot net 2010-02-10 00:29 --- (In reply to comment #13) Email replies get body and attachments automatically entered in the relevant bug, with an account created for the sender if they didn't already have one. If you preserve that, most of the important email handling functionality is there. Is there any check that the email sender is really the one he pretends to be? It's easy to hack the From: header of emails from the email client and impersonate another user (e.g. to gain privileges). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5
--- Comment #15 from joseph at codesourcery dot com 2010-02-10 02:29 --- Subject: Re: Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.4.5 On Wed, 10 Feb 2010, LpSolit at netscape dot net wrote: --- Comment #14 from LpSolit at netscape dot net 2010-02-10 00:29 --- (In reply to comment #13) Email replies get body and attachments automatically entered in the relevant bug, with an account created for the sender if they didn't already have one. If you preserve that, most of the important email handling functionality is there. Is there any check that the email sender is really the one he pretends to be? It's easy to hack the From: header of emails from the email client and impersonate another user (e.g. to gain privileges). No such check for adding comments from email replies, but adding a comment doesn't require privileges (and the password for an autocreated account is of course sent to the email address for that account, so an impersonator won't get the password). I don't know about the functionality for doing anything else by email. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43011
