| Summary: | metabug for upgrade of bugzilla | ||
|---|---|---|---|
| Product: | Gentoo Infrastructure | Reporter: | Jeffrey Forman (RETIRED) <jforman> |
| Component: | Bugzilla | Assignee: | Jeffrey Forman (RETIRED) <jforman> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ciaran.mccreesh, dberkholz, greg_g, infra-bugs, ka0ttic, mr_bones_, smithj |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 59713, 80259, 89409, 92459, 92491, 92492 | ||
| Bug Blocks: | |||
|
Description
Jeffrey Forman (RETIRED)
2005-05-12 16:40:40 UTC
Operating systems:
@opsys = (
"All",
"BSDs",
"Linux",
"OS X",
"other"
);
Can we post things like "Needs to be able to submit bugs about Gentoo (General -ebuilds, emerges, whatever)" here? :) Bug locking please, k tnx. also update the hardware list to include 'sh', 'm68k', and 's390' archs added I've added 80259 as well, so we can have a field to specify the package version atom that is responsible easier. I wonder if ALL could be made a default search. An illustration of this problem - http://bugs.gentoo.org/show_bug.cgi?id=86047#c12. Jakub, If we made ALL the default search, we'll bring the DB to its knees. -Jeffrey Out of curiosity, is a rearrangement of the Products/Components out of the scope here, or is it being considered? Also, I think I should link here to a possible replacement of the "enter bug" procedure, as discussed in bug 58651 comment #27: http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-main.html Removed the mailto link on the 'reporter' field so that spam spiders have more problems parsing spam addresse. I've spoken to the buzilla devs about mangling emails, and there is a patch available for the CVS of bugzilla, which is very unstable. made enhancement bugs green on the buglist in bugstest, so you can filter out "real" bugs from feature enhancements. The default selected status are different http://bugstest.gentoo.org/query.cgi?format=advanced <label for="bug_status" accesskey="a"> <select name="bug_status" id="bug_status" multiple="multiple" size="7"> <option value="UNCONFIRMED" selected>UNCONFIRMED</option> <option value="NEW" selected>NEW</option> <option value="ASSIGNED" selected>ASSIGNED</option> <option value="REOPENED" selected>REOPENED</option> <option value="RESOLVED" selected>RESOLVED</option> <option value="VERIFIED" selected>VERIFIED</option> <option value="CLOSED" selected>CLOSED</option> </select> </label> http://bugs.gentoo.org/query.cgi?format=advanced <label for="bug_status" accesskey="a"> <select name="bug_status" id="bug_status" multiple="multiple" size="7"> <option value="UNCONFIRMED">UNCONFIRMED</option> <option value="NEW" selected>NEW</option> <option value="ASSIGNED" selected>ASSIGNED</option> <option value="REOPENED" selected>REOPENED</option> <option value="RESOLVED">RESOLVED</option> <option value="VERIFIED">VERIFIED</option> <option value="CLOSED">CLOSED</option> </select> </label> This is something similar to ALL option I guess, so if it is going to hammer the DB, then please ignore. I'm actually quite happy about that change. It means I won't have to manually select only open bugs every time I'm searching for a bug that still exists. What happened to CANTFIX, UPSTREAM, and all the other resolutions? those resolutions were a pain to change by hand. but i added them. supposedly there is an admin console in 2.19 bugzilla to fix the more easily. Gregorio, With regards to your comment, http://bugs.gentoo.org/show_bug.cgi?id=92449#c9 right now I am focusing on getting bugzilla back up on the new version. we can work out a re-entry procedure for adding new bugs later. But to be honest, working with these customizations is so time-intensive the less we mess with the template, the easier upgrades will be for us (infra). Tuan, With regards to your comment #12, i noticed that difference once you explained it. It seems fine right now, I'd rather not start changing the template. We can see how the DB handles it once we implement the upgrade. http://bugstest.gentoo.org/reports.cgi <-- is broken... Internal Error Bugzilla has suffered an internal error. Please save this page and send it to bugzilla@gentoo.org with details of what you were doing at the time this message appeared. URL: http://bugstest.gentoo.org/reports.cgi Unable to open the chart datafile ./data/mining/-All-. per comment 18 i found something out: 1. the link from reports in the bottom is wrong...inside the page, it should be called chart.cgi 2. it requires a group to be given persm to make charts. 3. not sure we'll enable this now. (its been disabled on our current bugs system and no one has really complained) so i'll just comment out that link. Not sure if this is related but HTTPS bugzilla looks pretty crappy now - no line breaks, ugly font... Jakub, I hope you do realize https://bugs.gentoo.org != http://bugstest.gentoo.org. This bug is NOT for bugs.g.o. I'm testing out a new version of bugzilla and this is what the metabug is for. If your comment 20 has anything to do with https://bugs.gentoo.org, please file it as a seperate bug. -Jeffrey Please, disregard Comment #20. Just to explain, both https://bugs.gentoo.org and https://bugstest.gentoo.org looked really bad, but it also turned out that I had problems with other HTTPS pages. "Automagically" disappeared after deleting the Firefox profile once again. This thing never survived any browser upgrade here. *sigh* mmm line wrapping fixed on bugstest wondering if i could get your guys' thoughts on this. i've removed the email from the reporter's tag at the top of a bug's listing in bugstest.g.o. this is to try and help avert spam spiders from grabbing email addresses. do you: (1) like just the name (2) want a name and mangled email (example: Jeffrey Forman <jforman_Of_gentoo.org> (3) keep it the way it was, with the mail unmangled Option 2 then 1, in that order for me. same as mcummings. 3 then 2. I've gone one step further from comment 24: I did it like redhat does it. When someone isn't logged in: all they get is a name When someone is logged in to bugzilla: they get the name, and a mangled email. Bug I used to test: http://bugstest.gentoo.org/show_bug.cgi?id=64733 Attempt logged in, and logged out. And look at the reporter change. Would you guys want the email link in there if you are logged in? Or am i being overly paranoid by mangling it even if you're logged in? -Jeffrey Leave the email link in a usable state please. Some of us actually make use of it. Ciaran, That's what I ended up doing. If you log in to bugzilla, you get the full unmangled name with email with link. If you are not logged in, and just browse to the link, all you get is the name. You'll notice I did the same sort of mangling with the names/emails on the comments part. and we're up.... And the upgrade is done...This bug is DONE DONE DONE. go Jeffrey go! Aron mentioned UTC for time/dates. still possible? Thats going to take a bit more work because of the fact that the host DB server needs to be on that time. Its currently on PDT and has other projects using it (mozilla/kerneltrap). I think they may change that eventually, but it may be a while. Just be patient! coppied and pasted from -dev (i think the email got lost in the clutter. -dev is WAY too high volume...) one more thing: comment #15 of bug 92622 shows the bug which was a dup as marked through. perhaps this is intentional (resolved bugs show this attribute?), but it is very annoying, and it makes it hard to see the bug number without clicking on it to go to the link. (In reply to comment #8) > If we made ALL the default search, we'll bring the DB to its knees. All right, so now the instructions are: >Enter a bug #, one, or multiple search terms: >Example: catalyst livecd Which of course returns nothing for bugs that are closed (see e.g. Bug 93060). So now the bug gets fixed recently, user has not run emerge sync yet, then even if he follows the instructions, he does not find anything and files a duplicate bug. Instructions on the "new bug" page are not any better: > search Bugzilla by entering two or three of the main words having to do with > your bug in this box. For example: pop3 mail or copy paste. > Look through the search results. If you get the Zarro Boogs message, Bugzilla > found no bugs that match. Check for typos, or add fewer or different keywords. Can (In reply to comment #8) > If we made ALL the default search, we'll bring the DB to its knees. All right, so now the instructions are: >Enter a bug #, one, or multiple search terms: >Example: catalyst livecd Which of course returns nothing for bugs that are closed (see e.g. Bug 93060). So now the bug gets fixed recently, user has not run emerge sync yet, then even if he follows the instructions, he does not find anything and files a duplicate bug. Instructions on the "new bug" page are not any better: > search Bugzilla by entering two or three of the main words having to do with > your bug in this box. For example: pop3 mail or copy paste. > Look through the search results. If you get the Zarro Boogs message, Bugzilla > found no bugs that match. Check for typos, or add fewer or different keywords. Can´t we at least get the hint about ALL (or FIXED) keyword back on the bugzilla main/new bug page? I hope that you don´t suppose that users will actually read the help, do you? :p Also, mentioning something like "emerge sync and try again, if you have not done so recently" could prevent some duplicate or useless (Plz. version bump! Huh? In portage for two days...) bug reports. Not that I hope that this will decrease the number of dupes significantly, but the instructions deserve improvement anyway. |
