Closed Bug 12309 Opened 21 years ago Closed 14 years ago

Need to be able to choose all versions of an OS


(Bugzilla :: Bugzilla-General, enhancement, P4)




Bugzilla 2.20


(Reporter: roland.mainz, Assigned: mkanat)



(Whiteboard: [metadata:os] schema)

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 " ist not an uniqure shared
library name - name it ebtter"-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]
Priority: P3 → P4
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 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. is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news:// .)
Assignee: terry → tara
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.
Assignee: tara → cyeh
adding whiteboard word 'schema' so i can keep track of schema enhancements
Whiteboard: schema
*** 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
No longer blocks: 14934
Summary: Missing "Unix"-platform... → need "Platform: UNIX" and maybe also "OS: All UNIX"
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
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.
Summary: need "Platform: UNIX" and maybe also "OS: All UNIX" → want "Software Platform:" posix, unix, win32, macos, x11, gtk, qt
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.
Summary: want "Software Platform:" posix, unix, win32, macos, x11, gtk, qt → Missing "Unix"-platform
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty
see also bug 63872 (Same request for Win32)
Severity: normal → enhancement
Taking all of cyeh's Bugzilla bugs.
Assignee: Chris.Yeh → justdave
Target Milestone: --- → Future
Whiteboard: schema → [metadata:os] schema
Moving to new Bugzilla product ...
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
Summary: Missing "Unix"-platform → Need to be able to choose all versions of an OS
*** 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:

 9X, ME

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 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)

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

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

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
> 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
Blocks: bz-zippy
Target Milestone: Future → Bugzilla 2.18
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

Why not some form of checkbox grid, like e.g. ?
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. the thing you're complaining about is entirely unrelated and
entirely gerv's idea. complain to him somewhere else. if you are on OS/2, the guided list should contain OS/2. If
it does not, file a bug.

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)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
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.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: Bugzilla 2.22 → ---
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.
Closed: 14 years ago
Resolution: --- → WORKSFORME
> 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.
Depends on: 9468
Resolution: WORKSFORME → ---
(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.
Closed: 14 years ago14 years ago
Resolution: --- → WORKSFORME
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 (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).
No longer depends on: 9468
Resolution: WORKSFORME → ---
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Per my comment 54, this is now doable since 2.20.
Target Milestone: --- → Bugzilla 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.
Target Milestone: Bugzilla 2.20 → ---
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!
Target Milestone: --- → Bugzilla 2.20
Bug 281876 was the one fixing this.
Assignee: general → mkanat
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="">
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 src="">
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)

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 :)

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 src="">
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="">
for that. click the 'x11' or 'gtk' option in toolkit
if you know you want something that excludes osx you should know *why*

there's x11 on mac too

<blockquote src="">
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 src="">
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
You need to log in before you can comment on or make changes to this bug.