Community
Participate
Working Groups
It might be already on your list :) Bugzilla 2.20 is out. http://www.bugzilla.org/news/ There are some great new features, which I'd like to see at Eclipse.org. - Bugzilla Queries as RSS - Higher-Level Categorization of Bugs (above "Product") - Regular Reports by Email of Complex Queries ("Whining") http://www.bugzilla.org/releases/2.20/new-features.html
Thanks for pointing this out. I think the new features warrant bumping up the priority. D>
Planning this for early november. Denis to sanbox, test and transition. D.
Denis, could you please notify on the report when a sandbox of the 2.20 install is available? I need to update Mylar's support for Bugzilla.
I'll notify here and likely send an e-mail to all committers asking to test. D.
A sandbox install of 2.20 is at https://node1.eclipse.org/bugstest/ Currently Operating Systems and Platforms have been reset to default, which is an issue I'll solve. If anyone sees anything, please comment here (not in the sandbox). I'll be performing the upgrade this Sunday, Nov. 6/05 at 6:00am Eastern. D.
(In reply to comment #5) > A sandbox install of 2.20 is at https://node1.eclipse.org/bugstest/ 404 :( BTW, should we really expose "nodes" via URLs? ;) > Currently Operating Systems and Platforms have been reset to default, which is > an issue I'll solve. If anyone sees anything, please comment here (not in the > sandbox). They are now managed in the database. You don't need to edit files for cutomizing OS/Platform/Severity/Priority values anymore.
(In reply to comment #6) > 404 :( Yeah I forgot to copy the Apache config file to the common location. It gor overwritten with the cluster common file =) > BTW, should we really expose "nodes" via URLs? ;) Perhaps not, but node1 is the only one accessible from the Internet. If someone decides to use it, imagine the surprise on their face when I decide to shut ir down for maintenance! > They are now managed in the database. You don't need to edit files for > cutomizing OS/Platform/Severity/Priority values anymore. I know... They just weren't migrated. The list reverted to Windows, Linux, and Mac. I also need to change the index.cgi page to remove that stupid ant. D.
It was working for me for a while yesterday but I'm back to getting a 404: https://node1.eclipse.org/bugstest/ This is a problem Mylar we provide a Bugzilla UI that is dependent on Bugzilla versions and customizations, and quite a few people use it to connect to bugs.eclipse.org (not to mention that 300 people installed the new Mylar version yesterday as a result of bloggage). I haven't been able to test against this enough to update our implementation and so the Mylar support will stop working with eclipse.org once the switch is made. I'm currently trying to test against the bugzilla.mozilla.org version but any eclipse.org-specific customizations mean that the changes might still break on eclipse.org (I do realize that this fragile implementation is lame, but we're stuck with it for the short term). I can't say whether a single technology project is enough reason for you to delay the switch, but I do think that there should be more time with the preview site being available for community review before making such a switch.
(In reply to comment #8) > It was working for me for a while yesterday but I'm back to getting a 404: > https://node1.eclipse.org/bugstest/ I re-enabled it. It had disappeared somehow. > (I do > realize that this fragile implementation is lame, but we're stuck with it for > the short term). I think it's unfair to delay upgrades to the community because of a "fragile implementation". Eclipse.org's bugzilla is unmodified and uncustomized on purpose so we have the relative freedom of being able to upgrade quickly and painlessly. *sigh* This doesn't scale. Imagine if I had to co-ordinate with all Eclipse projects because they do screen-scraping. How much time do you need? D.
The key help here is that the Bugzilla is unmodified and uncustomized. So I've already been able to make much of the functionality work by testing against bugzilla.mozilla.org. I hope to do the rest today. So I'm still scrambling but hope to be OK with the weekend switch. But for the future, I think that it really is important for projects/community to have a preview version that's working for a full week before switching. And no, I don't think that you should have to worry about individual projects' needs because that doesn't scale. I see this being similar to how the Eclipse SDK offers integration builds before a milestone release--you're not supposed to use internal APIs, but you have a chance to do fixes before the new version goes live if you're offering the community valuable functionality built on them.
(In reply to comment #10) > The key help here is that the Bugzilla is unmodified and uncustomized. So I've > already been able to make much of the functionality work by testing against > bugzilla.mozilla.org. I hope to do the rest today. Mhm. I'm just curious, shouldn't the Mylar architecture support different Bugzilla versions?
Mylar's Bugzilla component supports 2.16, 2.18, and soon 2.20. The problem is that Bugzilla doesn't offer a good interfaces for working with queries and reports, so Bugzilla plug-ins (like Mylar's Bugzilla client, the dated Platform Team's, and Redhat's fork of that) are inherently Bugzilla version dependent. There is an open report for having Bugzilla offer a web service API to make things like integrated Eclipse plug-ins not require version-dependent XML/HTML scraping: https://bugzilla.mozilla.org/show_bug.cgi?id=224577
Just fyi, I've made good progress thanks to the eclipse.org version being a standard 2.20. Tonight's 0.4.1 release of the Mylar Bugzilla Client should either fully or mostly support Bugzilla 2.20. But naturally there hasn't been any testing by Mylar users other than me, and next week's bug reports will be the true test. Thankfully Mylar is released weekly...
Looks like we're still on 2.18. What's the new ETA for 2.20?
(In reply to comment #14) > Looks like we're still on 2.18. What's the new ETA for 2.20? I sent this out shortly after your message. Posting here for completeness: 5. Bugzilla upgrade postponed ============================= I was unable to set aside enough time to properly test the Bugzilla upgrade to 2.20, so I postponed it. The new date for the upgrade is during our maintenance window this Sunday, Nov. 13/05 at 6:00am Eastern. http://wiki.eclipse.org/index.php/WebMaster#Upcoming_Maintenance D.
Denis: I've been watching for the update today in order to test against it, and assume it has been postponed. When you have the new ETA could you please either post on this report or on the Upcoming Maintenance page? Thanks.
So when is the 2.20 move planned for? The Upcoming Maintenance page is still showing the old date and I haven't noticed any updates posted or sent out (did I miss something?). I'm not trying to rush this, I just need to know the date in order to plan around it.
I'll do it today... Sunday, Nov. 20 around 12:00 Eastern. It seems to be the only time I have outside of the work week. D.
Bugzilla has been upgraded to 2.20. All seems to work well. I'll iron out the remaining issues monday morning. If you see anything unusual (besides the big freekin' ant picture when you login) please write it here. D.
Thanks for the notifiaction Denis. Things are working well so far, and I will post here if I notice anything unusual. One small nit is that this gets added to the top of every query result page: "Bugzilla would like to put a random quip here, but no one has entered any." The random quip thing seems a bit too cute and noisy, and I'm wondering if it's possible to turn off (mozilla.bugzilla.org's 2.20 config doesn't have them).
(In reply to comment #20) > The random quip thing seems a bit too cute and noisy, and I'm wondering if it's > possible to turn off (mozilla.bugzilla.org's 2.20 config doesn't have them). > Yeah, I noticed that when I tested it. The documentation talks about a param called enablequips but for the life of me I can't find where it's set. D.
(In reply to comment #21) > Yeah, I noticed that when I tested it. The documentation talks about a param > called enablequips but for the life of me I can't find where it's set. editparams.cgi -> quip_list_entry_control
(In reply to comment #22) > editparams.cgi -> quip_list_entry_control That's not it.. It just disables adding new quips. If I add enablequips => 'off', to the data/params text file, it works until I run checksetup.pl again. Checksetup.pl seems to generate that file from .. something. D.
Mhm. I don't know if you can set this in "localconfig". Also interesting in checksetup.pl: add_setting ("display_quips", {"on" => 1, "off" => 2 }, "on" );
(In reply to comment #23) > That's not it.. It just disables adding new quips. If I add Got it! It's now a user preference. https://jbugs.ics.j.intershop.de/bugs/editsettings.cgi
Closing as fixed. Bugzilla 2.20 seems relatively stable. D.
