There is no way to specify, in the drop downs, more than one version that may be affected...  

Currently one is limited to reporting against 3.4, 3.5, 3.6. 4.0 (among others).

A given bug may easily affect more than one version, and may affect 'all' versions.

One thing is need/required (minimum, and 2nd thing would be 'a good idea' (IMO).
 The minimum:
1) (multi-version selection) : Allow Version field to have more than one item selected.  Currently it's set for exclusive-or selection, and it needs to be set for 'inclusive-or'... i.e. some drop downs allow selecting multiple fields by holding down control or shift (for a range).  This needs to be changed in the interface.


Recommended:
2). Define parent-source categories for various 'meaningful' groupings, at least:
   a) source3/3.x -- seems to all come from 'source3' tree (thought it might
have been called differently before the presence of the source4 tree).
   b) ?? (I'm not sufficiently familiar with the internal sources and their derivations to speak authoritatively beyond this, however, possibilities would
include) 
     i) source4? (seemingly obvious place for 4.x bugs - but probably NOT needed until there are multiple samba-4.x bug-targets (4.1, 4.2...)
     ii) Core? or Base? -- this would apply depending on how much code
overlap there was between source3 and source4 -- it would be a pure guess on my part, but it seems likely that source4 initially started from a copy of source3, then it was modified to support / become 4.0.  It really depends on how much overlap there is between the two bases -- probably anything more than
~33% share code would warrant such a category for things that affect both 
(thinking of problems on how samba handles user names, for example, or 'group', or machine, or domain....  That is probably based on code that is similar or near same across versions.


Impact of addressing this issue:

Multiple bugs need to be duplicated to each branch affected by a problem, which, in my mind, doesn' seem "useful" -- THOUGH, if it really is the case
that nothing could be fixed in some parent tree (i.e. fixed in one place), then maybe the filing of multiple bugs is what is needed (though I would hope that such a broken approach wouldn't needed, since with many bugs you may not have them to test with, OR know previous versions had a similar design -- .. like all default to reading smb.conf -- which I've always seen in /etc/samba/smb.conf...  IF there was a bug in the reading / processing of that file, it might easily be in all versions.

If it's the case that one can't fix multi-version bugs in one place, it would still be better to have solution 1, proposed for this bug, BUT, there needs to be (and probably should anyway) separate 'fixed' checkboxes for any active versions (ones that will still be getting updates and could have fixes)

If it's thought to be better than one bug should be filed/version, then I'd
like the adding of "bug # dependencies":t hings that need to happen before a given bug can be considered fixed.  This would allow a bug to be split
into multiple dependencies or allow the the reverse, grouping.   That way the same bug filed against different versions could be grouped under 1 bug that wouldn't be marked fix until all the sub-bugs were fixed.  

The idea being to properly get an idea of 'how many problems' there are.. vs. 
how many branches or pieces of code need to be changed.


---------------------------------------


Why did I file this?

2 reasons -- (one) -- was bout to file a bug that occurs in more than 1 3.x version. -- which reminded me of (two), a meta bug (https://bugzilla.samba.org/show_bug.cgi?id=8380), I'd filed the other day that had been closed out -- not because it was invalid or not a real problem, but because it was such a wide ranging bug that affected multiple areas, that the bug was thought pointless -- thus closed with a request for the submitter to file bugs against each encountered problem, separately -- which I wouldn't disagree with needing to be done, 
   HOWEVER, ding so wouldn't mean that _original problem_ was _fixed_.  It would mean only that items the submitter "ran into" were fixed.  I.e. if they don't use LDAP, ADS, etc.,  then the same problem in those areas could easily remain unfixed.  

    IMO, that would be "bad" (for some value of badness)...  I.e. I wouldn't think it would be something a responsible person or group would want to happen.
Of course I've seen more than one group or project that has been less than responsible, some more so than others.