This is __really__ my last attempt to get this in: Please add "Unix" (or better: Platform: "Unix", OS: "All Unix") to the "Platform" list. This is _neccesary_ for bugs which appear on all unix-platforms, like file naming problems/convertions (like the "libXXX.so ist not an uniqure shared library name - name it ebtter libMozXXX.so"-bug), compiler-related problem ("like gcc >= 2.95 requires -fpermissive on most Unix-platforms or build will fail"-bug) and so on. I can list at least 20 things which are common to all Unix-Platforms - setting this only on one platform causes duplicate bugs or (worst case) two module owners are working on a bugfix seperately because on is Linux, another is from the Solaris party :-((

To save time, bug 14934 (for `Windows 2000') could be fixed at the same time as this one. (There could be an `All Windows' OS field value, too ...) [Marking bug 14934 as dependent on this one, though they're really siblings]

I don't like this. Because it makes the rules for platforms more complicated, and people will then complain how they can't get all their Linux bugs by selecting for "Linux". You can't win, unless you make the platform field allow a "set of platforms", which is hard to implement. But I'm leaving this bug open as a place for discussion.

What about adding a new option "Software Platform" which contains "Specific" (e.g. only occurs on selected OS), "Win32" (including Win95/98/NT/2000), "Unix" (Linux/Solaris/AIX/Unicos etc.) etc. ?

I do like the idea of being able to search by "Software Platform". This could be accomplished by adding a new <SELECT> and underlying field, or by adding options like "Any Unix", "Any Windows", and "Any MacOS" to the existing "OS" <SELECT>. Either way there would be an increased cost of processing to map the common names to the list of specific OS names that would be OR'd together for the database query. I tend to think it would be more straightforward for the form user not to add a field. Independently (because the various Unix OS could always be multiply-selected as OS) the search wanted by Roland.Mainz@informatik.med.uni-giessen.de could be done in a natural-looking way if the "Platform" <SELECT> contained "Any" - which would act as if nothing was selected as all. Together, these would allow a search for Platform:Any and OS:Any Unix, which would be a natural way to express the part of the query limiting the search to just Unix-like OS on any platform. But the Platform:Any may be judged unnecessary. There certainly are bugs in the database now that are marked "MacOS 8.6" for instance, when they really apply to "Any MacOS". Setting Platform to "Macintosh" and leaving OS blank to specify "Any MacOS" would lead to bugs related to Linux on Mac being found when searching for all MacOS bugs. Of course, the searcher could always think a bit and realize that the search should have each of the MacOS versions multiply-selected in the OS <SELECT>, but "Any MacOS" would be easier to get right (What's the mouse-click equivalent of a typo?). So strictly speaking none of this is needed if every user can be counted on to always multiply-select appropriately in both Platform and OS for each search, but in the real world, adding the "Any ..." items to the OS <SELECT> and processing them as appropriate before querying the database may be worth the effort. What doesn't make any sense to me is to overload the term "Platform" to mean in some cases a hardware platform and in other cases a software platform. That way lies only confusion.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

what i think you want, is a search for all platforms like 'MacOS'. this is not possible given the current database schema, but might be possible when we break the schema out.

adding whiteboard word 'schema' so i can keep track of schema enhancements

*** Bug 67224 has been marked as a duplicate of this bug. ***

*** Bug 59810 has been marked as a duplicate of this bug. ***

clarifying summary a bit and removing dependency to an unrelated res/dupl bug

So does anyone have a bug asking for hardware platforms? 32bit, 64bit, big endian, little endian, intel endian, ... Part of this can be handled by creating search options that behave like trees: All Platforms All Unix Linux HPUX ... Win32 9x 95 98 ME nt 3.51 4 2k XP macos 7.x 8 .0 .1 .5 .6 9 .0 0 4 .1 html sort of supports this [i think only to one level of indentation] clicking All platforms would select it and all its children (everything). Clicking MacOS and then control clicking win32 would select macos [all children] and win32 [all children]. As for allowing someone to mark something as occuring on all unixes, for now i'd suggest the whiteboard [unix] [win32] [posix] ... hardware issues could definitely get keywords.

We already have a hardware field. It's called `Platform'. If your bug is in PPC Linux, it's Platform: Macintosh, OS: Linux. If your bug is in FreeBSD on a Sparc, it's Platform: Sun, OS: FreeBSD. Et cetera. Anyway, that's nothing to do with this bug -- restoring original summary.

Adding default QA contact to all open Webtools/Bugzilla bugs lacking one. Sorry for the spam.

see also bug 63872 (Same request for Win32)

Taking all of cyeh's Bugzilla bugs.

Moving to new Bugzilla product ...

*** Bug 101490 has been marked as a duplicate of this bug. ***

*** Bug 63872 has been marked as a duplicate of this bug. ***

*** Bug 122699 has been marked as a duplicate of this bug. ***

*** Bug 125659 has been marked as a duplicate of this bug. ***

This bug should be fixed for the next version of bugzilla, imho. It has been around way too long. For a quick fix, lets just get Win32, Unix All, and Mac All into the database. Using Timeless's suggestion would be good for a more appropriate future fix. as in: Win32 9X, ME 95 98 ME NT 4.x 2000 XP See also: bug 127147

*** Bug 127034 has been marked as a duplicate of this bug. ***

See also bug 9468, "Be able to select more than one platform/OS in Platform and OS fields".

*** Bug 136823 has been marked as a duplicate of this bug. ***

CCing Dave and Dawn: timeless has a good idea for the future of bugzilla itself, but for bugzilla.mozilla.org itself, would it be possible to have the generic Mac, Win32 and Unix added to the list on the next server update?

After talking to timeless on IRC, it appears a problem with just adding the Win32, Unix, and Mac fields would be that people might file under Win32 when the bug occured on Win98, and that would cause a loss of information if they didn't specify the operating system. Bug 9468 would be a better choice, but require a major architecture change.

somewhere out there i had a proposal to have three fields Hardware Toolkit OS IA32 PresentMgr OS/2 Sparc Xlib Solaris8 68k MacClassic MacOS8.1 IA64 Win32 WindowsXP PaRisc Gtk HPUX11 Alpha Qt OpenVMS Altivec Carbon MacOSX MIPS Gtk SGI PPC Be BeOS5 ARM Photon QNX6.3 Sparc64 Motif Solaris9 StrongArm VGALib NetBSD I think i hit most hardwares, most toolkits and most os's (I know i omitted some bsds, Amiga, NeXT, and linux but they aren't interesting and i ran out of useful hardware sets)

timeless: I prefer comment #11. My eyes came out of my sockets when looking at comment #27 (no offence :-) The heirarchy you showed could be shown in combo boxes that change entries based on selection of the previous box (like on query.cgi). Any additional information about the OS (Windowing system, window manager, etc) can be attained from the reporter in the bug report or additional comments. Also, having OS based on hardware platform or vice-versa is the wrong way to go about it. The platform should be independent since you can have multiple hardware platforms on one OS and vice-versa. It will make things too complicated. Leave that up to the Bug Triagers to pick out faulty entries. This, in tandem with bug 9468 would be a killer combination.

*** Bug 155427 has been marked as a duplicate of this bug. ***

I dont think 'All Windows' is appropriate. there is another problems besides the data loss mentioned in comment #26 Windows bugs tend to occur in all versions of Windows 9x series (95, 98, 98 SE, ME) Windows NT (NT 4, NT5/2000, XP) is a less buggy ill ignore windows 3.11 and windows CE (i guess CE uses the NT kernel). so if you are going to hack something into the present system i would recommend something like Windows 9x kernel (95, 98, ME) Windows NT kernel (NT, 2000, XP)

It will be very useful to have more than one options for the O/S. See bug #76831. This bug affect some Windows O/S and everyone have been bickering over it. That bug doesn't make sense because Win95 is not the same as WinNT. So, if instead of something like "Windows (ALL)" options. How about instead of the scrollbar, use the textarea with more than one selection option. Like what I saw under this bug status category, like "New, Resolved, Duplicate, Invalid, etc" when I use the bugzilla search option. That will help to reduce the problem and allow us to move on. This is the most cost effective method and this make the most sense.

According to what I have been told, the problem with this is that people won't choose a specific OS and will choose "All Windows" instead of their specific version even if the bug doesn't pertain to all operating systems. Perhaps the solution is allowing a combo box (like the Status box on query.cgi) where someone with significant permissions can choose more than one entry in this box if it applies to more than operating system. Only people that are given permission to do this would be able to alter the bug. This would include: People it is assigned to and people with the permission bits. I don't even think it would be necessary for the reporter to be able to add operating systems.

I like being able to check off each platform - although that's really covered under bug 9468 instead. Whatever the resolution, there has to be some way of indicating more than just one Win32 OS, etc. BTW: Why are all OSs available regardless of the platform chosen? (MacOS really shouldn't be listed under OS if the platform selected is PC...)

Re: Comment 32 > According to what I have been told, the problem with this is that people won't > choose a specific OS and will choose "All Windows" instead of their specific > version even if the bug doesn't pertain to all operating systems. Doesn't bugzilla default to the OS that is posting the bug? If the submitter is the type of person who would select 'all windows' instead of their particular version I think they wouldn't even bother to change it if bugzilla has already pre-selected it.

I agree that the default OS should be the current OS. But this is done correctely for me ( Mac OS 9.x) since the last changes to the submit form. I suggest also that the multi-os keywords can be set only by authorized persons.

OK, how about this idea... leave platform alone. split the existing OS field into two separate fields. First field is OS: Windows, Mac OS, Mac OS X, Linux, SunOS, etc. Second field is OS Version: 3.1, 95, 98, ME, NT, 2000, XP or 8.6, 9.0, 9.1, 9.2 or 10.0, 10.1, 10.2 etc The OS Version field would have all possible values listed in it initially, and the available selections would be pared down via Javascript based on which OS is selected if Javascript is available. The OS Version field would contain an "All" or "Any" choice, no matter which OS was chosen. Anyone think that sounds reasonable? Only problem I can think of with that is data migration from the old way... since the OS field is installation-specific, we'd have to force the admin to draw a map for us of how to split up the fields...

your proposal doesn't solve anything. we need each field to be multiselect and we need to be able to indicate platform, toolkit and os. js intelligence will cause problems. when someone decides to do something we didn't expect the js intelligence will cause data corruption. otoh, there's nothing wrong with divorcing the query form from the actual form fields, you could search for 'windows' and have it magically convert that to whatever the admin selected was windows. we can do something similar for enter bug, and it'd probably be possible to create a simplified edit bug which worked differently. if multiple os's were listed and the user didn't have edit bugs, it could just list the os's and allow the user to check another os as affected. this can be transparently stored by bugzilla in the status whiteboard. when a user with edit bugs sees it, they can remove it from the whiteboard and select the real osversion in the multiselect. What happens if a bug occurs in Linux 3 (it'll happen) and Windows 4 but not Windows 3 and not Mac OS <any>? your scheme doesn't handle it. In the three fields as multiselect, this is easy: [IA32] [Gtk, Win32] [ Linux 3, Windows 4] When the user does a query we don't have to actually show IA32 for simple users, it can still be listed as 'pc'. Javascript can be taught to prefer a toolkit if one isn't selected, so selecting windows 4/98 would select win32 and ia32 if nothing is selected for them. note that autodetection will have already prefilled 2-3 of the fields in normal conditions.

> your proposal doesn't solve anything. we need each field to be multiselect > and we need to be able to indicate platform, toolkit and os. multiselect is bug 9468 and is a separate issue. Yes, this can be done separately, although there's no reason it has to - this bug is a much less major change and is thus more likely to be implemented sooner - things tend to happen in stages around here, which is a good thing. Your average user has no clue what a toolkit is. You're grasping at straws. > js intelligence will cause problems. when someone decides to do something we > didn't expect the js intelligence will cause data corruption. Why? If os versions are tied to OSes (like components are currently tied to products) then why couldn't the back end reject it just as easily? > What happens if a bug occurs in Linux 3 (it'll happen) and Windows 4 but not > Windows 3 and not Mac OS <any>? your scheme doesn't handle it. That's covered in bug 9468

all versions of an os should be solved by multiselect. just resolve this as a duplicate of that and be done with it.

I would actually agree that making OS a multiselect (perhaps as a custom field) is the correct way to solve this. If that's the eventual goal, splitting the field in two now will cause migration headaches, both now (as Dave outlines) and later. Gerv

Why not some form of checkbox grid, like e.g. http://bugzilla.mozilla.org/userprefs.cgi?tab=email ? Users without permissions could be limited to adding one check per submit and removing none.

Multiselect is the best way to solve this bug. Interestingly if OS Z is availible on platform X and platform Y, and someone found a bug that is occurs on X-Z v1.0 , and on Y-Z v2.0, but not on X-Z v2.0 or Y-Z v1.0 multiselect will not fix the problem. If the user selects [X,Y][Z v1.0,Z v2.0] then if someone queries for X-Z v2.0 they will get the bug even though it does not apply. There is no good solution for that problem is there?

It strikes me with the dependency trees within Bugzilla it would be simpler to keep it as it is, and raise separate bugs for each platform. The first bug raised would have the full description; subsequent bugs only need to say something like "This is bug X on platform Y". I agree with the previous post that says that when someone raises a bug on, for instance, Windows NT, the temptation to simply select "All Windows" will lead to unnecessary inaccuracies and problems with searching for bugs for, e.g., Win98. It could make individual bugs somewhat untidy if the fixes for several platforms were all contained in one bug report. If a bug was raised against Win95 and Win98, then later on someone says it also reproduces on WinNT, they would have to modify the original bug. But bugs need confirmation, and this process could get lost if the new platform was simply added to the original. It would be better for a new bug to be raised stating "This is bug NNN on WinNT", then the dependencies updated to reflect the close association, then confirmation would take place as normal, and any platform dependent stuff (as WinNT is substantially different from Win9x and the fix could well be equally different) would go in the new bug and not clutter up the original. If this feature is implemented it would be necessary for searches on a specific platform also to bring back bugs raised for the All X type. Obviously a search on bugs for Win98 should bring back bugs for Win98 and bugs for "All Windows" and "All Platforms". With my above suggestion a search for Win98 bugs would bring back some original bugs and some "This is Bug X on Win98" bugs, which isn't a problem as the latter will have hyperlinks to the full bug report. This bug also means that a bug report will not be closeable until it is fixed on all specified platforms, whereas if left as is a bug that requires separate fixes on several different platforms can be fixed and closed separately for each platform.

Once you have created a Bug, the OS list includes OS/2. But during the initial creation process, the OS list omits OS/2. I have had to go in immediately after creating a Bug & modify it just to get it correctly classified as OS/2. Please add OS/2 to the list during the creation process. In fact, it looks to me like the list in a Bug is complete & really ought to be the one you put up in the Bug creation process.

wildwilly@fuse.net: the thing you're complaining about is entirely unrelated and entirely gerv's idea. complain to him somewhere else.

wildwilly@fuse.net: if you are on OS/2, the guided list should contain OS/2. If it does not, file a bug. Gerv

I know everyone is ignoring it, but NT could be NT 3.51 as well. Micro$oft uses "NT3" "NT4" "NT5" to differentiate various versions; Most of the time "NT" does not mean "NT3 or NT4 or NT5" but simply "NT4" I see no difference between this and, say, versions of MacOS, or even kernel versions of Linux. Can one count on all versions always increasing? Perhaps instead of GROUPING versions one should aim to specify a RANGE of versions, as in Min: Max: ----- ------ Win32 Win32 95 ME WinNT WinNT 3 5 Just my 2c.

Well, if you do that, you'll have to remember that there are different versions of NT5. NT5.0 = Windows 2000, NT5.1 = Windows XP and NT5.2 = Windows 2003.

Enhancements which don't currently have patches on them which are targetted at 2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. Consideration will be taken for moving items back to 2.18 on a case-by-case basis (but is unlikely for enhancements)

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

So it seems as though the general concensus is that a multiple select field for the OS/platform would be good. Currently this bug is marked as target milestone 2.22. I know 2.20 freeze and cleanup is underway but is there any actual plan to do this (multi-select) in 2.22 or does it just get bumped to the next target milestone every freeze with no firm plans for implementation?

it's almost certainly going to be bumped unless someone steps forward.

Reassigning bugs that I'm not actively working on to the default component owner in order to try to make some sanity out of my personal buglist. This doesn't mean the bug isn't being dealt with, just that I'm not the one doing it. If you are dealing with this bug, please assign it to yourself.

You can now clone bugs (new feature since 2.20, bug 81642), you can customize the list of OSes and platforms using editvalues.cgi (new feature since 2.20, bug 281876) and bug 9468 will allow you to select several OSes and platforms. This bug doesn't need any special additional work.

> bug 9468 will allow you to select several OSes and platforms Except for the fact that bug 9468 doesn't look like it has any hope of being fixed anytime soon.

(In reply to comment #55) > Except for the fact that bug 9468 doesn't look like it has any hope of being > fixed anytime soon. Which isn't required to fix this bug as you can already add entries such as "All windows" or "All Mac" using editvalues.cgi.

Wow. Shouldn't this me marked as fixed since this is an added feature you just placed in there instead of worksforme? Worksforme suggests that this could work prior to 2.20 which you still distribute on bugzilla.org (1.18.3) Otherwise, I can confirm that the solution LpSolit suggested, works. Anyways, I think what Jason said on comment 55 is correct. There is currently no method of selecting multiple operating systems. For example, filing a bug that might be present in both unix and mac os x flavours because they are a similar style os, which probably wouldn't be filed for windows. But since that bug is still open, theres no need to keep this one open too.

> Which isn't required to fix this bug as you can already add entries > such as "All windows" or "All Mac" using editvalues.cgi. Okay, then bug 9468 should never have been mentioned as one of the things that fixes this. However, if this *is* to be considered fixed, then WORKSFORME isn't the correct resolution (as pointed out in comment 57). This didn't just magically start working - it's now working because of the other bugs that have been fixed and which have been identified in comment 54 (except for bug 9468).

Per my comment 54, this is now doable since 2.20.

Only the assignee of a bug (the person working on it) should be setting a target milestone. At best, others can only set blocking flags. Also, since this is now fixed, a target milestone makes little sense.

Primo, all FIXED bugs must be targetted to the version where they were fixed. Secundo, I'm an official reviewer and the QA manager of the Bugzilla project. So please this field untouched. Thanks!

Bug 281876 was the one fixing this.

I really object to this bug being marked as fixed. Unfortunately it has the important conversation so the summary needs to be rewritten. <blockquote src="irc:justdave@irc.mozilla.org"> Maybe we need OS and OS Version to be separate fields there's a lot of UI changes in the 3.0 upgrade, it'd be a perfect time to do things like that. lots of disruptive things at once. :) once we have 3.0 we get custom fields, and select boxes are one of the types available. so we could add an additional select box for OS version and make the OS field just be the overall OS then you get the best of both camps. (searching is the main excuse given by the people who want only the OS) we kind of also need it where the valid choices in a select box are dependent on the choice in another select box, too. Like someone who chose Windows for OS would get 2000, XP, Vista etc for OS version, someone who chose Mac OS X would get 10.1, 10.2, etc yes [classifications/products/components have that code] does. but that's not flexible code, it's very tied to product/component </blockquote> <blockquote src="irc:timeless@irc.mozilla.org"> justdave: unfortunately we kinda need to split the other way too although maybe your split is equivalent to the split i wanted i think i basically split {hardware}{platform}{osversion} platform would be something like Cocoa/Carbon of course how we should platform to users could be different i just wanted a way to distinguish between platform, because platforms can be very different <p class="note offtopic"> note that cloning is a *disaster* some clever "process" people forced it upon us at work i'm not alone in hating it we're now mass cloning bugs to move between products and an engineer recently eloquently explaining how cloning causes problems (in short you lose all the important comments as soon as the bug forks) </p> basically i'm proposing comment 27 for the field structure note that i didn't list all os's, the list would be *much* bigger, but rarely shown in its entirely and rarely shown flat for queries, use the ui from comment 11 the list was *never* complete the idea was to show a wide variety the complete list at the time was probably 7 times longer but i wanted a nice even table and i didn't want to type the full list :) of course, there's /one/ minor problem w/ comment 11 i think i have to list osx twice :) once under Unix and once under macos :) to be honest, i really don't mind that there's no rule that says something can't appear more than once :) <p class="note"> looks like i messed up the indentation for "macos", oh well :) </p> note that practically speaking, we want free text os searching if we use a multiselect tree, then people can select Linux .. and stop before osx if we use a magical list, we can have clicking Unix select all its children, and if someone wants, they can ctrl-click macosx to remove it (and its children?!) </blockquote> <blockquote src="irc:max@irc.mozilla.org"> because searching for 'mac' should yield everything related to 'mac'. i doubt anyone searches for unix bugs thinking they're 'mac' too == err... missed a sentence == [ed. note: I never could figure out this line!] == and searching for 'unix' doesn't imply that mac bugs will exist there even if os x is a unix variety but for the products that are created by m.o, i don't think it's relevant it'd be true for other projects, but as a whole, isn't true for m.o fair enough i'd almost say that there be two unixes one with, one without i'm not sure what the wording would be... that's the thing <blockquote src="irc:timeless@irc.mozilla.org"> for that. click the 'x11' or 'gtk' option in toolkit if you know you want something that excludes osx you should know *why* </blockquote> there's x11 on mac too <blockquote src="irc:timeless@irc.mozilla.org"> for that. click the 'x11' or 'gtk' option in toolkit if you know you want something that excludes osx you should know *why* yeah, there is x11 for osx do you really think that a bug about x11 won't exist on the macosx impl? very few people will file a bug about it but if they do, and they filed it, shouldn't you find it? (if you want it) </blockquote> sure... </blockquote> <blockquote src="irc:timeless@irc.mozilla.org"> anyway. i think my proposal covers most if not all people yes it introduces a field normal people shouldn't use i'm actually more than happy to not have it in the top query section although i think there's a certain advantage to putting it up there </blockquote>