Community
Participate
Working Groups
When I create a new bugzilla task, the attribute "OS" comes pre-selected with "Windows Vista", while when using the web interface it detects correctly "Windows XP". I'm not sure if the bug editor uses the same mechanism as the web interface, i.e. the detection comes from server metadata, but in any case it would be nice to have the same detection mechanism.
I also find this quite annoying. Especially because Eclipse's BugZilla rejects Vista as an OS.
Me too.
More over, attributes section is collapsed by default and I am always forget to change it... Interestingly, that most often I am changing it to "All".
I know what you mean. It seems like auto-detecting the OS does more harm than good for Eclipse-based stuff, since most of the time the bugs are for All platforms. We've managed to successfully get rid of all Bugzilla preferences to date, but I wonder if this warrants one?
(In reply to comment #4) > I know what you mean. It seems like auto-detecting the OS does more harm than > good for Eclipse-based stuff, since most of the time the bugs are for All > platforms. For Java-based stuff the OS does not matter very much, since it is multiplatform :) But for other product domains, or native stuff like SWT it is a very important information. So if it can be auto-detected correctly (presuming that in most cases the user is reporting the bug from the environment where it occurred), I vote for it.
Update: 'All' now selected if the platform is not recognized. Currently platform detection is based on a call to Platform.getOS() which is then mapped to a hard coded list of options. On a windows based system we get 'win32' back which doesn't help differentiate between the different windows variants. Any thoughts on how we could improve this(renamed report to reflect general need for improvement)?
Created attachment 52059 [details] mylar/context/zip
Make win32 resolve to Windows XP, which the Eclipse mark studies have shown is by far the most used Windows OS. Do that and we can consider this resolved, at least until someone complains that Vista is not being auto-detected once it ships. So for now we avoid adding the preference.
The side effect will be that the bugzilla installs that just have "Windows" as an option will get defaulted to "All".
System.getProperty("os.version") would help to discover what Windows version the user is running. On my machine, a Windows XP SP2, it returns "5.1". I found this page: http://support.microsoft.com/kb/q189249/ It describes each internal version number for each branding name. We just need to map them (supposing the String returned by os.version always follow the major+"."+minor pattern).
I wonder what will it be for 64-bit version of XP and Vista...
*** Bug 197948 has been marked as a duplicate of this bug. ***
This may be non-trivial for the following reasons: The bug submitted can only have a platform/os chosen from the list a setup by the repository administrator: https://bugs.eclipse.org/bugs/ has a list different from standard bugzilla as it was configured so. Also the administrator can setup parameters defaultopsys and defaultplatform to set the fall through. This is desired behavior as each bugzilla owner can have different requirements as to the granularity of the reported Platform/OS. So whatever else, Mylyn must try and match the platform/os as expected by the specific repository. The ability to get at platform/OS information is decided by the JRE and the Eclipse code itself: Example: The Eclipse.org bugzilla install has as OS descriptor for OSX the string "MacOS X", while the string returned by System.getProperty("os.name") is "Mac OS X". The different use of space prevents any matchup by the current algorithm, so it always comes up as 'All'. This may also be reason Vista is reported differently. NOTE: maybe the eclipse bugzilla admin can change the label from 'MacOS X' to 'Mac OS X', than at least the current code works? For a bugzilla used to support Eclipse development, I feel the OS and Platform labels should match whatever is returned by a Java system call,as Java is the main 'bug context' for bugs.clipse.org. What still needs to be investigated: What happens when you submit a bug without the OS and platform set, will bugzilla fill it in then? How does bugzilla find the OS and platform information, does it use the browser identification string? (see bug 184514) If so that string should include platform and OS information that bugzilla can use. Should we have a per repository Advanced preference for the default platform/OS?
I like the idea of setting platform in the repository configuration. Another alternative could be to remember last chosen options and restore them when filling in the next bug. Though in both of those cases we still need some level of autodetection that would be used on the first occurrence.
From Bugzilla::WebService::Bug.pm "create" EXPERIMENTAL Description This allows you to create a new bug in Bugzilla. If you specify any invalid fields, they will be ignored. If you specify any fields you are not allowed to set, they will just be set to their defaults or ignored. [...] Params Some params must be set, or an error will be thrown. These params are marked Required. Some parameters can have defaults set in Bugzilla, by the administrator. If these parameters have defaults set, you can omit them. These parameters are marked Defaulted. Clients that want to be able to interact uniformly with multiple Bugzillas should always set both the params marked Required and those marked Defaulted, because some Bugzillas may not have defaults set for Defaulted parameters, and then this method will throw an error if you don't specify them. [...] "op_sys" (string) Defaulted - The operating system the bug was discovered on. "platform" (string) Defaulted - What type of hardware the bug was experienced on. [...] Yes and because it is experimental, there isn't a way yet to see whether the defaults are set :-(
Rob, can you assign this bug to me for the time being? Maarten
Certainly...
Looking at code in BugzillaRepositoryConnector I noticed the following: Reporting Plaftorm options are sorted and the first one is selected, in most installations this is 'All' OS options are not sorted and the last one is selected, in Eclipse.org this is 'Windows Vista-WPF' Why this sorting and why the different default selection?
Bug 185991 just got resolved, so The Eclipse.org Bugzilla now wants "Mac OS X" with proper spaces... Mac OS X works OK now and is correctly recognized. That means its now only a question of matching the different Windows & Liux response strings.
(In reply to comment #18) > Looking at code in BugzillaRepositoryConnector I noticed the following: > Reporting Plaftorm options are sorted and the first one is selected, in most > installations this is 'All' > OS options are not sorted and the last one is selected, in Eclipse.org this is > 'Windows Vista-WPF' Both platform and OS should start with the first option, usually All. The check in the Advanced setting for the repository to see if a default has been selected. - if yes, report that - if no, try and deduce from System.getProperty("os.name")/System.getProperty("platform.name") Attached is a screenshot of the proposed advanced settings, I tried to minimize size :-)
Created attachment 74915 [details] mylyn/context/zip
Created attachment 74916 [details] screenshot of proposed additional Advanced setting If unselected, guess starting from All if selected always report the selectred platform/OS
Is this platform default selection and guessing something for the BugzillaRepositorySettimngsPage or should it be in the AbstractRepositorySettingsPage?
I think this stuff is actually specific to bugzilla, though the platform detection facility could be handy to have as a some kind of standalone utility. Though I don't really know any specific use cases besides bugzilla (jira connector don't need that).
The code for deriving the os would ideally be (In reply to comment #18) > Looking at code in BugzillaRepositoryConnector I noticed the following: > Reporting Plaftorm options are sorted and the first one is selected, in most > installations this is 'All' > OS options are not sorted and the last one is selected, in Eclipse.org this is > 'Windows Vista-WPF' > Why this sorting and why the different default selection? This is likely legacy code. You could consider moving the platform detection code to TasksUiUtil for the time being. The ui you propose looks about right to to me (with addition of a ':' at the end of the label).
Created attachment 75221 [details] Setting default platform and OS in Bugzilla additional settings One problem with platform detection is that every bugzilla installation can have it own set of values. The currnet code does a reasonable job, for some bugzilla's. Missing some values as reported such as Windows Vista-WPF are more easily handeled by setting a default value for platform and OS than by ever more elaborate detection code. The improvements are: - when defaults are setm use them for new bugs - when not set, start guessing from All/All (rather than All/Windows Vista) - when guessing works, use the guessed values Possible hardening: - the defaults should be unset, when they are no longer allowed values in the repository This check is best done when updating the (cached) configuration.
Created attachment 75222 [details] mylyn/context/zip
This is looking good Maarten! Just a couple nits: - Lets not read in the configuration to set default platforms for the platform/OS combos in the BugzillaRepositorySettingsPage since retrieving the configuration can block upon first retrieval. It's an advanced setting anyway so user should know what they want to select. - Our convention when adding comments is to add them above the line the comment is about rather than than at the end so as not to break formatting - If you could prepend the tag [patch] to the bug summary when a patch is ready that can speed responsiveness
> - Lets not read in the configuration to set default platforms for the > platform/OS combos in the BugzillaRepositorySettingsPage since retrieving the > configuration can block upon first retrieval. It's an advanced setting anyway so > user should know what they want to select. Well to populate the list I need the values from the configuration, a open text entry is not an option I think! IF configuration is not null (means has been retrieved?) AND in the cache THEN populate AND enable pop up. ELSE disable option altogether. So I need a method that returns the configuration if its in the cache OR null when it has never been retrieved yet, as would be in initial setup. I now retrieve if configuration not null and no forced refresh... The other nits: will do that from now on.
Created attachment 76811 [details] Bug159397-patch-v2 When the repository is null, meaning it has never been accessed, the Platform/OS setting is disabled completely, preventing retrieving the configuration of an unverified repository. If the repository has been acessed, the configuration is retrieved to set the popup values. Items to do: - error handling on exceptions. Is there a preferred generic eclipse or mylin error logging mechanism? - validating that the values manually set remain legal in case of changes on repository (very infrequent I assume).
Created attachment 76812 [details] mylyn/context/zip
(In reply to comment #13) > What still needs to be investigated: > What happens when you submit a bug without the OS and platform set, will > bugzilla fill it in then? > How does bugzilla find the OS and platform information, does it use the browser > identification string? (see bug 184514) > If so that string should include platform and OS information that bugzilla can > use. see https://bugzilla.mozilla.org/show_bug.cgi?id=380170 that the browser identification string
(In reply to comment #30) We're getting there. In terms of UI, lets change the setting to "Autodetect platform and os" and have it checked by default. If the user unchecks this, retrieve the configuration (show progress in the wizard during this) then populate and enable the combos. How does this sound? This way we won't block the ui upon initial opening (i.e. when they double click on Eclipse.org for the first time, the repository exists but configuration doesn't so will block). > Items to do: > - error handling on exceptions. > Is there a preferred generic eclipse or mylyn error logging mechanism? Currently we use the StatusHandler singleton methods as appropriate. This will be refactored to use the platform's StatusManager in the future. > - validating that the values manually set remain legal in case of changes on > repository (very infrequent I assume). Yes, at some point we could validate these upon configuration update (which happens automatically at least once a day).
(In reply to comment #33) > We're getting there. In terms of UI, lets change the setting to "Autodetect > platform and os" and have it checked by default. If the user unchecks this, > retrieve the configuration (show progress in the wizard during this) then > populate and enable the combos. How does this sound? OTT?, I added an explanatory tooltip instead :-) > > - error handling on exceptions. > > Is there a preferred generic eclipse or mylyn error logging mechanism? > Currently we use the StatusHandler singleton methods as appropriate. This will > be refactored to use the platform's StatusManager in the future. I'm just logging the CoreException now using StatusHandler > > - validating that the values manually set remain legal in case of changes on > > repository (very infrequent I assume). > Yes, at some point we could validate these upon configuration update (which > happens automatically at least once a day). This will go into populating the popup, if the respective option has disappeared, revert back to All and clear the option!
Created attachment 76980 [details] Swithed optio to "Autodetect Platform and OS" Defaults to autodetect, enabled after the repository has been acessed at least once.
Created attachment 76981 [details] mylyn/context/zip
Patch applied, ip log updated. This is great Maarten. Made the retrieval of cached configuration api (removed java doc about use for testing) (Frank I know you were wanting to use this too). Once this method became available I was able to lazily load the configuration post wizard creation. This allowed displaying progress for configuration retrieval upon selection of the autodetection check box.
