Community
Participate
Working Groups
Although Bugzilla 3.2 isn't released yet, I'm just opening this bug to track dependent tasks.
I filed this in the wrong place...
cc'ing the usual Mylyn suspects
Thanks Denis. Rob: Are we good with Bugzilla 3.2?
(In reply to comment #3) > Thanks Denis. > > Rob: Are we good with Bugzilla 3.2? I'll need to get back to you on that (tracking testing of this on bug#246260).
Denis, do you have a sandboxed 3.2rc1 running I could test against?
I don't, sorry.
BZ 3.2 has been released: http://www.bugzilla.org/releases/3.2/new-features.html We'll let it simmer for a bit and upgrade when it's feasible to do so.
Denis, the version of Mylyn currently distributed in Ganymede doesn't support Bugzilla 3.2. bug#252297 has been addressed but is only available in the weekly Mylyn builds. My concern is that if bugs.eclipse.org is upgraded to Bugzilla 3.2, many users will hit with this bug. We may be able to do a Mylyn maintenance release in early January. If possible, could we coordinate the 3.2 upgrade for that time? Otherwise this fix will not be available until the next Ganymede maintenance build (Feb 25).
(In reply to comment #8) > My concern is that if bugs.eclipse.org is upgraded to > Bugzilla 3.2, many users will hit with this bug. Waaaaaa! That would be bad. I know it work out better to do the maintenance when fewer people are around, but I'd +1 waiting for a working Mylyn. http://dev.eclipse.org/blogs/eclipsewebmaster/2008/11/21/mylyn-indispensable/
We can certainly wait till early January.
(In reply to comment #10) > We can certainly wait till early January. Thanks Denis. Will touch base in the new year then.
Denis, to make the transition as smooth as possible to Bugzilla 3.2, we are planning on including this support in Mylyn for Ganymede Update 2. The later we push updating to Bugzilla 3.2 after the release of Ganymede Update 2 the better since more people will have installed the update (and will therefore not experience any problems with Bugzilla 3.2 when using Mylyn). But as long as the update happens after Update 2 is available, we can ask people to download the update if experiencing problems submitting to bugs.eclipse.org. How does this fit with your timeline?
(In reply to comment #12) > Denis, to make the transition as smooth as possible to Bugzilla 3.2, we are > planning on including this support in Mylyn for Ganymede Update 2. What? I don't understand. Bugzilla 3.2rc1 was out August 12, 2008, so I would have expected Mylyn to support 3.2 long before today. As I've said before (bug 113042 c9) I think it's unfortunate that you're asking us to delay new Bugzilla features to the community. We're willing to work with you to make sure Mylyn and Bugzilla work well together, but I think the position we're currently in is highly undesirable. Bugzilla 3.4 is currently in development, and snapshots are already available. Can we expect Mylyn to be 3.4-ready by the time it's released in May 2009? http://www.bugzilla.org/releases/3.4/
(In reply to comment #13) > (In reply to comment #12) > > Denis, to make the transition as smooth as possible to Bugzilla 3.2, we are > > planning on including this support in Mylyn for Ganymede Update 2. > > What? > > I don't understand. Bugzilla 3.2rc1 was out August 12, 2008, so I would have > expected Mylyn to support 3.2 long before today. > > As I've said before (bug 113042 c9) I think it's unfortunate that you're asking > us to delay new Bugzilla features to the community. We're willing to work with > you to make sure Mylyn and Bugzilla work well together, but I think the position > we're currently in is highly undesirable. I agree that the current situation is not desirable and we will do our best to minimize the chances of this happening in the future. Mylyn 3.0.2 (out with Ganymede Update 1 in September) did not include support for one critical change made in Bugzilla 3.2. Our next opportunity to make this fix available is to the community is Update 2 in late February. > Bugzilla 3.4 is currently in development, and snapshots are already available. > Can we expect Mylyn to be 3.4-ready by the time it's released in May 2009? > http://www.bugzilla.org/releases/3.4/ We are working the bugzilla.org crew to ensure we get the most out of the Bugzilla 3.4 release and testing to ensure Mylyn 3.2 (released with Galileo) will work properly with Bugzilla 3.4.
(In reply to comment #14) > [...] Our next opportunity to make this fix available is to > the community is Update 2 in late February. Sorry folks but that is just plain wrong. You can make available any 3.0.x fix release prior to Update 2. Remember, the release train does not limit you to make releases *only* as part of the release train. > We are working the bugzilla.org crew to ensure we get the most out of the > Bugzilla 3.4 release and testing to ensure Mylyn 3.2 (released with Galileo) > will work properly with Bugzilla 3.4. This is now getting off-topic. But I think all guys using Mylyn with Bugzilla are in big trouble with this strategy. The whole point of the Eclipse plug-in concept is that connectors can be developed _and_ released *independent* from the main Mylyn stuff. For the record, I'm strongly against any further delays of the Bugzilla update. It's great that the webmasters are very patient and brave to wait for the Mylyn team catching up.
(In reply to comment #15) > This is now getting off-topic. But I think all guys using Mylyn with Bugzilla > are in big trouble with this strategy. The whole point of the Eclipse plug-in > concept is that connectors can be developed _and_ released *independent* from > the main Mylyn stuff. Yes, we could consider independent Bugzilla Connector releases in the future for issues such as this. The concern though is that a great portion of Eclipse users wait for the service updates before upgrading anyway. btw, if people wish to use Mylyn with Bugzilla 3.2, the weekly builds include the necessary fix: http://www.eclipse.org/mylyn/downloads/
(In reply to comment #16) > The concern though is that a great portion of Eclipse > users wait for the service updates before upgrading anyway. I don't share that concern. I consider the group of Mylyn users hitting Eclipse Bugzilla on a very active level very experienced developers. Most of them probably have Eclipse Committer privileges and develop Eclipse plug-ins themselves. Another observation I made is that if there is a need to upgrade, people will upgrade.
(In reply to comment #16) > Yes, we could consider independent Bugzilla Connector releases in the future > for issues such as this. The concern though is that a great portion of Eclipse > users wait for the service updates before upgrading anyway. We (webmasters) normally send out lots of warnings and communication about upcoming upgrade work on all our software, services and infra, and post-upgrade notifications. Such notifications could include 'your Mylyn connector will need to be upgraded; download it here'.
(In reply to comment #18) > (In reply to comment #16) > > Yes, we could consider independent Bugzilla Connector releases in the future > > for issues such as this. The concern though is that a great portion of Eclipse > > users wait for the service updates before upgrading anyway. > > We (webmasters) normally send out lots of warnings and communication about > upcoming upgrade work on all our software, services and infra, and post-upgrade > notifications. Such notifications could include 'your Mylyn connector will need > to be upgraded; download it here'. Okay great. We're moving the release of Mylyn 3.0.4 ahead to tomorrow evening (Friday Jan 23) so the fix will be available for consumption and we won't block you any further. It would be great if we could inject a message about upgrading Mylyn to the latest release (3.0.4) and pointing people to http://www.eclipse.org/mylyn/downloads/ when the 3.2 upgrade takes place!
Guys, please hold off on making the upgrade/announcement for day or two if possible so that we can have one more look at the cosequences (I'm on a plane right now, land in 10 hours). Bugzilla usage stays are dominated by non-committees as far as I know, so the vast majority of Bugzilla/Mylyn users will not get this message and will be affected.
stays -> stats
(In reply to comment #20) > [...] Bugzilla usage stays are dominated by > non-committees as far as I know, so the vast majority of Bugzilla/Mylyn users > will not get this message and will be affected. They are not affected because bug 252297 (the bug in Mylyn which requires the update) is only relevant to committers. Non-committers shouldn't change a bug status (do they even have those permissions?).
(In reply to comment #22) > They are not affected because bug 252297 (the bug in Mylyn which requires the > update) is only relevant to committers. Non-committers shouldn't change a bug > status (do they even have those permissions?). Right, non-committers in general cannot change bug status.
We will re-review the potential impact first thing on Monday and report back with a proposal on how we can get the upgrade done asap without affecting too many users. Regarding changing status, yes we do see non-committers changing status regularly. They can do this if they own the bug. For projects with a large contributor community, like Mylyn, that happens regularly.
(In reply to comment #24) > Regarding changing status, yes we do see non-committers changing status > regularly. They can do this if they own the bug. For projects with a large > contributor community, like Mylyn, that happens regularly. Yes, you're right Mik
Here's the plan we propose for the Bugzilla 3.2 rollout. Note that the assumption I'm making here is that the current Eclipse update mechanism is not working well enough for us to expect non-committer users to update via the Mylyn update site. We have seen way too many users fail to update to relevant bug fixes to assume that, and way too many P2 failures that make it effectively impossible for users to diagnose update problems. As such, we have to continue assuming that the Ganymede SR process is the main way that users consume Mylyn releases. The bugs.eclipse.org Webalizer logs back this up. 1) Mylyn team releases Mylyn 3.0.4 on Wednesday (tomorrow) 2) Denis stages the Bugzilla 3.2 instance at his convenience, we get the usual 2 weeks to test against that 3) The Bugzilla 3.2 update goes live with Ganymede SR2 on February 25th If there is opposition to postponing the Bugzilla 3.2 update until February 25th, we support an earlier update in the sense that we will already have released Mylyn 3.0.4 on our update site. But someone else else will need to decide that doing that provides overall net value to bugs.eclipse.org users, a large portion of which use the Mylyn rich client and not the Web UI. For the future, we would like as much as possible to coordinate Mylyn client releases with major Bugzilla releases. But we don't know how to make bugs.eclipse.org users consume our updates those on a faster interval than the coordinated releases. The best suggestion so far is that we implement support for a bugs.eclispe.org service message to the header of the Mylyn task editor.
(In reply to comment #26) > coordinated releases. The best suggestion so far is that we implement support > for a bugs.eclispe.org service message to the header of the Mylyn task editor. I like that idea
(In reply to comment #27) > I like that idea Created bug 263528.
A security fix (CSRF) introduced in Bugzilla 3.2.2 breaks rich clients from modifying bugs (Mylyn included): https://bugzilla.mozilla.org/show_bug.cgi?id=26257 I've filed the following bug to request the changes necessary to ensure Mylyn (and other rich clients to Bugzilla) can continue to function correctly: https://bugzilla.mozilla.org/show_bug.cgi?id=476678 This further motivates the need for us to implement bug 263528 since security fixes of this nature are necessarily hidden from the broader community. We are investigating the possibility of backporting a fix and releasing a Mylyn 3.0.5 for Ganymede Update 2. Discussion will be ongoing on bug263318, I'll keep yo posted of any major changes.
IMPORTANT Denis: which Bugzilla 3.2.x version are you planning on updating to? Bugzilla 3.2.2 was released on Tuesday Feb 2nd (yesterday), and contains a security fix which prevents rich clients from submitting bugs without resorting to screen scraping. Rob's comment above has details. We are working with the Bugzilla lead via https://bugzilla.mozilla.org/show_bug.cgi?id=476678 and he is currently planning on putting out a fix in a month. We have a work-around that we could put into Ganymede SR2 if necessary, we just need to understand your plans here.
Right now I'm going with 3.2.2. We run mod_perl.
(In reply to comment #30) > currently planning on putting out a fix in a month. Or I could just apply the very trivial patch there on that bug.
(In reply to comment #32) > Or I could just apply the very trivial patch there on that bug. That would be great. We have now started implementing the client end of this patch, and Rob will have some news tomorrow.
Denis: If you plan to go ahead with the update before Ganymede SR2 goes out, I think that we need the following things to happen in order not to end up with a onslaught of bug reports and unhappy bugs.eclipse.org users: 1) Create a service message on top of each bug listing similar to how Mozilla does this, pointing people to update their Mylyn client to support htis new version. The link should go to: http://eclipse.org/mylyn/downloads/ People using Mylyn will try to fall back to the web UI via the facility we have for that, so this is the only reliable way we know of informing the majority of users, who won't get the message that was sent to committers. 2) Apply the Bugzilla patch once that's done (they're still iterating on it) 3) Upgrade to Bugzilla 3.2.3 once that's out, since the patch will be in it's final form and there are other relevant fixes coming.
(In reply to comment #33) > (In reply to comment #32) > > Or I could just apply the very trivial patch there on that bug. > > That would be great. We have now started implementing the client end of this > patch, and Rob will have some news tomorrow. For progress on the Mylyn Bugzilla fix feel free to tune into bug#263318.
Mylyn 3.0.5 supports the security measures introduced in Bugzilla 3.2.2 and is now available from the standard update sites: Eclipse 3.4: http://download.eclipse.org/tools/mylyn/update/e3.4 Eclipse 3.3: http://download.eclipse.org/tools/mylyn/update/e3.3
(In reply to comment #36) > Mylyn 3.0.5 supports the security measures introduced in Bugzilla 3.2.2 So ... does that mean I can proceed with the upgrade?
(In reply to comment #37) > (In reply to comment #36) > > Mylyn 3.0.5 supports the security measures introduced in Bugzilla 3.2.2 > > So ... does that mean I can proceed with the upgrade? Yes, Mylyn 3.0.5 was included in Ganymede update 2 and is also available from our update sites (http://eclipse.org/mylyn/downloads) so if in your email to the community you could include another brief message about updating (to 3.4.2 and/or Mylyn 3.0.5) that would be great. Are you going to be making a sandbox available again as part of this update?
+1: I'd like to see Bugzilla 3.2+ installed so we can get XMLRPC (bug 266901), in order to permit Bugzilla/CVS and Bugzilla/SVN change tracking for Hudson-based Athena CBI builds (bug 253281). Any progress on this?
I'm planning the upgrade for July. There is quite a lot of new stuff in 3.2 (including a snazzy new UI) and I fear massive backlash (and broken stuff) if I upgrade before Galileo is released. By July, the Galileo pressure will be relieved, and the new Bugzilla 3.4 will have shipped, so I will likely just sit this one out. Two for the price of one. http://www.bugzilla.org/releases/3.4/ MYLYN GUYS: Bugzilla 3.4 will be in Release Candidate soon *nudge* *cough* get 3.4 support in Galileo? *cough* bug 261868 *cough*
Thanks for the heads up Denis. Will you be doing the UTF-8 conversion at that time as well?
> Will you be doing the UTF-8 conversion at that time as well? Yes, if it doesn't explode...
Denis, would it be possible to include a line in the repository configuration you're serving up to indicate the encoding used in the db? For example: <db_encoding>ISO-8859-1</db_encoding> ...added right after the <bz:install_version/> element? Then if present, we'll make use of what's specified there otherwise we'll use what is explicitly set on the Task Repository in Mylyn.
Is this something that is part of later Bugzillas?
<bz:installation rdf:about="https://bugs.eclipse.org/bugs/"> <bz:install_version>3.0.4</bz:install_version> <db_encoding>ISO-8859-1</db_encoding> <bz:maintainer>webmaster@eclipse.org</bz:maintainer> Looks weird... Can we call it <bz:db_encoding> instead? FWIW, here's what I use: sed -e '/<bz:install_version>/ a\ \ <db_encoding>ISO-8859-1</db_encoding>' config.xml
> Looks weird... Can we call it <bz:db_encoding> instead? Nevermind... I just noticed in the other bug that you've committed the code. The line is there now, but since we use mirrors for the config.xml you'll need to wait a bit for it to propagate.
Thanks Denis, looks like the following termination elements are missing from the updated config doc: </bz:installation> </RDF> fyi, this is not part of future Bugzillas and is eclipse.org specific just to get through the transition period.
(In reply to comment #47) > Thanks Denis, looks like the following termination elements are missing from the > updated config doc: > > </bz:installation> > </RDF> > > fyi, this is not part of future Bugzillas and is eclipse.org specific just to > get through the transition period. Actually it looks like a few other elements aren't terminated (bz:target_milestones, product) and flags is possibly missing altogether. So something might have got truncated during the sed?
The sed wasn't working as expected. Have a look now, everything should be there.
Perfect, thanks Denis.
Robert, I hear BZ 3.4 will be out sometime in August. Does Mylyn already support it?
Denis: Robert is currently on vacation. I've CC'd Shawn who is covering for him in his absence. It's very likely that we'll have additional work to do in order to support Bugzilla 3.4. Would it be reasonable to schedule the upgrade to coincide with Galileo SR1 (September 25th)? That would ensure that all the Mylyn-based Galileo's out there work. It would also provide enough time to wait to update to 3.4.1 if there are any breaks in 3.4.0, as with the last Bugzilla release cycle. In the meantime, we'll start working on porting to Bugzilla 3.4 (bug 283761).
(In reply to comment #52) > It would also provide enough time to wait > to update to 3.4.1 if there are any breaks in 3.4.0, as with the last Bugzilla > release cycle. Denis: Bugzilla 3.4.1 is out, with a security advisory as the reason again (http://www.bugzilla.org/releases/3.4.1/release-notes.html). I wonder if we'll end up with a 3.4.2 before Galileo SR2. Rob: What's the status of Mylyn support for Bugzilla 3.4.x?
(In reply to comment #53) > Rob: What's the status of Mylyn support for Bugzilla 3.4.x? Core functionality has been verified against 3.4.1 with no known regressions. Testing is ongoing.
False incomings appear upon opening tasks due to changes in how the description is being wrapped in 3.4.1. Investigating on bug#286041.
Scheduling the upgrade for Saturday, Aug. 29. There is a sandbox here, which I'm actively working on, so it may or may not work at any given time: https://bugs.eclipse.org/bugstest/
Denis, we have a patch available (on bug#286041) that will fix the regression in Bugzilla wrt the line wrapping of xml. Once applied, Mylyn users will no longer get false incoming on bug descriptions upon opening the task editor. This patch has been submitted to bugzilla.org for inclusion in the next maintenance build but it would be excellent to have this applied as part of this weekends migration to 3.4.1. Is this feasible?
Yeah, let's get the Bugzilla team to sign-off on the patch. That would make me real happy.
Okay, we'll try to move the review along at bugzilla.org. I just discovered another issue upon testing with https://bugs.eclipse.org/bugstest/. Seems that short/local users is now enabled on bugstest and is resulting in failure when submitting from Mylyn (created bug#287217). We'll look into this today to determine if this is a Mylyn or Bugzilla regression. Is there any particular reason short names has now been enabled? Could you go live this weekend without this feature enabled?
> Is there any particular reason short names has now been enabled? Um, because I ran the update and it turned itself on? Is this a parameter? What is this short names that you refer to?
The setting I am referring to is found at Administration > User Authentication > emailregexp. Changing this to ^[^@]+ is usually done to just allow local users names (no @somewhere.com just the username) but this doesn't make sense for eclipse.org/bugs anyway so I doubt this has been changed. The problem I'm seeing results from there being short names output in the xml where full email would normally be. https://bugs.eclipse.org/bugstest/show_bug.cgi?ctype=xml&id=283877 Have a look at fields such as reporter where the full name is specified followed by a short form of Mik's email address. This is where I would expect to see the full email returned instead of the short form. Could the email addresses have been truncated in the database?
> Have a look at fields such as reporter where the full name is specified > followed by a short form of Mik's email address. Are you logged in? If not, isn't this Bugzilla's new 'don't show emails to anonymous users' feature? I'm logged in to bugstest, and I see all of Mik's email address.
Indeed, when logged out, the email address (including, and past the @) is truncated.
So work around is to require them to authenticate first. I know that this is a change to the bugzilla connector default settings, but really if they are using Mylyn they are probably going to report or add a note at some point so might as well ask them to login.
(In reply to comment #63) > Indeed, when logged out, the email address (including, and past the @) is > truncated. Thanks for pointing this out Denis. I'll mark bug 287217 as invalid.
Denis, I upgrade to Bugzilla 3.4.1 on one of the boxes and noticed something strange. In 3.4.1 they changed the way passwords are encrypted/hashed which breaks Apache database authentication. Did you test this?
(In reply to comment #66) > Denis, I upgrade to Bugzilla 3.4.1 on one of the boxes and noticed something > strange. In 3.4.1 they changed the way passwords are encrypted/hashed which > breaks Apache database authentication. Did you test this? So here is some more background. https://bugzilla.mozilla.org/show_bug.cgi?id=211006 The password field now contains additional characters which are not part of the password but describe the hashing algorithm used. For one of the Apache boxes I solved the issue by using the Apache authentication module for Bugzilla. https://bugzilla.mozilla.org/show_bug.cgi?id=392482 Passwords of users are automatically migrated whenever a user with an old password logs in. There is a tool available for resetting all old password. https://bugzilla.mozilla.org/show_bug.cgi?id=471844
> Denis, I upgrade to Bugzilla 3.4.1 on one of the boxes and noticed something > strange. In 3.4.1 they changed the way passwords are encrypted/hashed which > breaks Apache database authentication. Did you test this? Gunnar, thanks for the pointer. I had read about this, but for some reason I didn't click... I'll have to update Babel, our site login, EPIC, Live, etc. I don't use Apache auth, I simply compare-crypt in PHP. PHP supports most modern hashes, though, so I'll just use the same logic as found in the Bugzilla code.
I'll have to patch the auth code in IPZilla too, so that it can authenticate with crypt and SHA-256.
Well, we're running Bugzilla 3.4, but in CGI mode. mod_perl wouldn't initialize. I'll resolve that this week.
FWIW, Bugzilla is now running in mod_perl. I needed to specify an addition libs path in /etc/apache2/mod_perl-startup.pl
