Community
Participate
Working Groups
Bugzilla 3.2 is on the horizon and so we need to do the testing necessary to ensure Mylyn is ready.
Frank, do you want to start some testing on your end and I'll get the rc installed on the vserver?
http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-3.2rc1.tar.gz
(In reply to comment #1) > Frank, do you want to start some testing on your end and I'll get the rc > installed on the vserver? Yes, I can start with testing. On my Machine that version is allready installed. Should we start a new JUnit for this version and include all existing tests?
I think we should create tests for any failures, not necessarily a whole new suite. You could comment in the test method that it is 3.2 specific.
Rob, the support for the new custom field types in in bug#226851
Created attachment 112501 [details] patch
Created attachment 112502 [details] mylyn/context/zip
Bugzilla 3.2 use the following new way. There are two places where an attribute has no lables. 1) Platform has select for rep_platform and op_sys 2) Importance has select for priority and bug_severity Should we provide an generic fix or should we do two specific implementation for the described two cases.
Created attachment 113068 [details] new version New Editor for two Combo Attribute is included in this patch
Created attachment 113069 [details] mylyn/context/zip
Great stuff Frank. As for our ability to automate testing, due to security precautions, upgrading perl modules isn't feasible on the vServer and this new release requires a few modules not currently installed. I've email Denis about this so will likely have a server running this week.
If this patch will support custom fields, can we also add support for flags at the same time?
(In reply to comment #11) > Great stuff Frank. As for our ability to automate testing, due to security > precautions, upgrading perl modules isn't feasible on the vServer and this new > release requires a few modules not currently installed. Have you seen http://www.bugzilla.org/releases/3.2/release-notes.html#v32_feat_install You don't need administrator-level access to your machine for the ney installation
(In reply to comment #13) > (In reply to comment #11) > > Great stuff Frank. As for our ability to automate testing, due to security > > precautions, upgrading perl modules isn't feasible on the vServer and this new > > release requires a few modules not currently installed. > > Have you seen > http://www.bugzilla.org/releases/3.2/release-notes.html#v32_feat_install > > You don't need administrator-level access to your machine for the ney > installation Hey that is really handy, thanks for pointing that out Frank. Unfortunately, as for our vServer, it is completely blocked from opening outbound network connections (for security reasons). The way we've installed in the past is to scp a bugzilla.tar up there then run the install as usual. All past installs have been fine and didn't require any more perl modules. The 3.2 stream seems to require a 3-4 modules (+ dependencies) that aren't already installed, so we're stuck. There are work-arounds which I've attempted but they become too time consuming. We're looking into replacing the vServer entirely and if this happens, will likely have the modules we need (since the current vServer is quite dated).
regarding comment#14, see bug#248363
Created attachment 114266 [details] Platform and Importance (In reply to comment #12) > If this patch will support custom fields, can we also add support for flags at > the same time? Kevin, I see you've already found the related bug but for others interested, flag support is being tracked on bug#186265. Also of note is that progress is being made on 3.2 realted custom attribute improvements on bug#186265. Frank, your patch updates the rich editor to reflect the new Bugzilla ui very well (with minor nits we can work out). Although the direction Bugzilla has taken with the Platform and Importance fields decreases the footprint slightly, in my opinion the lack of labels is somewhat confusing. Lets get Miks, take on these UI changes before we proceed. Mik, attached is a screenshot showing how platform and os have been mergedinto a double dropdown simply labled Platform. Similarly, priority and severity have been merged into Improtance. This has the potential to decrease the overall size of the attributes section but may be at the cost of clarity. Thoughts?
I like what they've done with merging these fields. But I think we should wait on changing the attributes section, since we need to consider which part of this belongs in the task editor header. For example, we already have a graphical way of indicating "Importance" with the task and priority icon, and could make that more prominent and editable.
(In reply to comment #17) > I like what they've done with merging these fields. But I think we should wait > on changing the attributes section, since we need to consider which part of > this belongs in the task editor header. For example, we already have a > graphical way of indicating "Importance" with the task and priority icon, and > could make that more prominent and editable. > Please be aware that using names other than what is indicated in the Bugzilla may cause conflicts with custom field attributes. For example, the image I saw used "Importance" for the combination of Priority and Severity. Many companies actually have service level agreements defined that dictate who is allowed to set Priority and who is allowed to set Severity. If I were recoding that section, I would probably change Importance to Pri./Sev. because a) it doesn't further overload meaning in these fields, and b) it actually takes even less space than Importance. :-)
(In reply to comment #18) > (In reply to comment #17) > > I like what they've done with merging these fields. But I think we should wait > > on changing the attributes section, since we need to consider which part of > > this belongs in the task editor header. For example, we already have a > > graphical way of indicating "Importance" with the task and priority icon, and > > could make that more prominent and editable. > > > > Please be aware that using names other than what is indicated in the Bugzilla > may cause conflicts with custom field attributes. For example, the image I saw > used "Importance" for the combination of Priority and Severity. This is the name used in Bugzilla 3.2rc1 so if this is a problem for you please report this to Bugzilla. > Many companies > actually have service level agreements defined that dictate who is allowed to > set Priority and who is allowed to set Severity. If I were recoding that > section, I would probably change Importance to Pri./Sev. because a) it doesn't > further overload meaning in these fields, and b) it actually takes even less > space than Importance. :-) >
(In reply to comment #19) > (In reply to comment #18) > > Please be aware that using names other than what is indicated in the Bugzilla > > may cause conflicts with custom field attributes. For example, the image I saw > > used "Importance" for the combination of Priority and Severity. > > This is the name used in Bugzilla 3.2rc1 so if this is a problem for you please > report this to Bugzilla. That's true in the bug update screen, however, it's not true in the bug entry screen. I'm still lobbying with the BZ community to change it in such a way that it allows administrators to determine which label is displayed. > > Many companies > > actually have service level agreements defined that dictate who is allowed to > > set Priority and who is allowed to set Severity. If I were recoding that > > section, I would probably change Importance to Pri./Sev. because a) it doesn't > > further overload meaning in these fields, and b) it actually takes even less > > space than Importance. :-) Of course, this is the "why"... :-)
Examples for previous comment: Create Bug: https://landfill.bugzilla.org/bugzilla-3.2-branch/enter_bug.cgi?product=dump%20unwanted%20bugs%20here View/Edit Bug: https://landfill.bugzilla.org/bugzilla-3.2-branch/show_bug.cgi?id=1
The major bugs to support 3.2 have been resolved. Frank, I've moved your patch for editor nits to bug#13941394.
