GNOME Bugzilla – Bug 433607
Update bugzilla from 2.20
Last modified: 2009-08-16 21:01:35 UTC
Versions later than 2.20 have many nice new features. It would be great if bugzilla.gnome.org could be updated to a later version.
I lack the time to do so. Help is appreciated.
How could I help? What kind of help would you be looking for and from whom?
I guess you need a list of patches applied locally, and update them to work with 3.0.1. bkor probably has such a list somewhere.
The bigger things are: * patch-status (drop down lists on show_bug.cgi to easily change the status of a patch... the entire status stuff is custom.. upstream only has flags) * Boogle, see Bugzilla/QueryParse.yp in bugzilla-newer * using postgres (need to fix all custom reports) * porting all reports * switching the UI (easiest) * showing who is a dev (hard, need one SQL to determine this; in 3.0 I'm use groups to determine who is the dev of a product.. it is very hard to get the comments + 'are-you-are-dev' in one SQL.. see bugzilla.gnome.org module Bugzilla/Bug.pm, GetComments) Note: if you check out bugzilla-newer (2.20), do a cvs diff on it to see the changes vs upstream bugzilla.gnome.org module contains the 3.0 version, obviously it isn't finished
FTI on postgres (Pg) docs: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ (I knew about the site, but it was way too technical before.. now it is better.. still not great) http://www.sai.msu.su/~megera/postgres/fts/doc/ http://www.sai.msu.su/~megera/postgres/fts/fts.pdf http://www.sai.msu.su/~megera/postgres/talks/fts-pgcon2007.pdf
Alpha version of FTI for Postgresql: https://bugzilla.mozilla.org/show_bug.cgi?id=365258 Rolf: Please drop by #bugs on irc.gnome.org and ping me (nickname bkor). Most likely available in the evenings; CET/CEST timezone.
So, after consulting LpSolit & some consideration (mostly regarding time it takes to code a proper solution & staying close to upstream), I think it is better just to check for specific groups for the developer/maintainer stuff for the next bgo. It will be a bit like the: [% FOREACH group = comment.author.direct_group_membership %] in Bugzilla CVS HEAD.. although I have to check what direct_group_membership does This means the only big problems are (in order of difficulty): * patch-status (need to make it much less hackish than it is now) * Boogle (I hope not too much changed in the table structure) * porting custom reports (Pg support, make use of objects, etc) * changing UI (the library.gnome.org layout)
Oh, forgot about points... Currently they are pretty hacky and so I'll ignore how it is done ATM. In the upgrade, I want to track the number of open/closed/add_comments on a userid basis. And whenever the user opens/closes/add a comment, I'll update the user right away. Note: This is slightly complicated in the closing case. This as we only want to grant max 1 user a closure per bug. I'm thinking of storing a who_closed_it (something better) column in the bugs table. If that is set, the user is substracted 1 closure. After that the bugs.who_closed_it is updated with the new user + new user gets additional 1 bugs_closed. Not sure how easy that is to do. Might have to wait for the Bug.pm update code in 3.1 (dev for 3.2). This is the solution I want to push upstream btw. If LpSolit doesn't complain here ;) Or perhaps use triggers. That would be interesting. I wonder if all the databases Bugzilla supports have triggers (Pg of course; MySQL perhaps... depends on what minimum version we require).
Thomas Thurman has claimed the patch-status conversion.
(In reply to comment #8) > This is the solution I want to push upstream btw. If LpSolit doesn't complain > here ;) What do you want to bring upstream *exactly*?
(I'm thomas@thurman.org.uk here-- maybe I should be tthurman@gnome.org everywhere...)
Created attachment 95271 [details] [review] Changes from upstream for 2.20.5 These are the diffs from upstream version 2.20.5, in case anyone wants to save themselves the trouble of generating them themselves. About half of the text is Template Toolkit code and the rest is mostly Perl.
Okay, so, here we are. I have put together a changeset against 3.0.3: https://bugzilla.mozilla.org/attachment.cgi?id=318513 and I raised a bug at bugzilla.mozilla.org about it: https://bugzilla.mozilla.org/show_bug.cgi?id=431438 The bugzilla maintainers say it is a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=431438 (which has no code attached yet). 431438 is not due to see the light of day until Bugzilla 4.0. What do you think we should do? Should we wait to upgrade b.g.o until upstream reaches 4.0, or should we apply these changes to upstream 3.0 and not bother waiting for them?
Bugzilla 4.0 won't be released before next year, so that's very far from now. You can either apply the patch you attached on b.m.o to bugzilla.gnome.org or use flags instead, which is the recommended way. none = no flags set at all obsolete is already a state available for attachments, even in 2.20 accepted-commit_now = review+ approval+ needs-work = review- accepted-commit_after_freeze = review+ approval? committed = committed+ (or even better: resolve the bug as FIXED) rejected = review- (or resolve the bug as WONTFIX if you don't want the fix at all, or approval-) reviewed = review+ As you can see, the whole attachment status thing can be replaced by 2 or 3 flags: review, approval and eventually committed. I'm surprised bkor didn't suggest this before. He is used to our review/approval process on b.m.o.
And now the upstream folks say 431438 is not going to be in 4.x either. Are we giving up on ever moving away from 2.x for b.g.o, or is there another alternative?
Done. :-)
Thanks, Max! Applause