> Also, search works fine if you choose all Top-level categories in "Return bugs 
> for these packages" while it's basically the same as selecting all the items.

Yeah, except that's a big pain in the a** having to select all of them one by one manually. It's ridiculous.


> The bug is still there but It doesn't seem to  bother anyone.

On what do you base that? On the number of complaints you [don't] receive?

Who definitely seem to not be bothered is the developers/maintainers of the website.

Come on, this is ridiculous. Switching to a POST form would be trivial!

Firstly, I suggest not to talk to spammers, which
"nataliepeyton332" appears to be. Can somebody with sufficient
rights please delete that comment.

Secondly, there is no need to select any package, if you want to
search for all packages.

Thirdly, feel free to submit a patch or pull request to solve the
issue.

> Secondly, there is no need to select any package, if you want to
> search for all packages.

Oh, wow. Unfortunately, some category have a grey background, which makes them look like almost exactly as if they were selected by default (which in reality they aren't, they are just styled with a grey background). 

That's very confusing, making the user think that without selecting anything, those particular categories will be searched only.

Also, by selecting all top-level categories it gives LESS results than not selecting anything, which means that selecting top-level categories it does not include the subcategories automatically, so god knows what selecting top-level categories actually does (can bugs be filed within a top-level category alone without specifying any subcategory)?

The whole thing is a mess.

IMHO there are 4 steps required to solve this:

1) No second "NOT" package select.
   Reduces max GET query length from 24KB to 12KB.

2) Use p[] instead of package_name[] parameter name.
   Reduces max GET query length from 12KB to 8KB.

3) Use package_id instead of package_name for the values of the p[] select.
   Reduces max GET query length from 8K to 4 KB.
   Might also improve SQL performance for the search query if applied correctly.

4) Use a JS based auto toggling if user selects more than half of packages in the p[] select.
   Reduces max GET query length from 4KB to 2KB.


A 2KB GET query should be handled fine by browser, Apache web server, PHP and the SQL query without fiddling with web server config.


I see I joined the game of improving bugs.php.net too late as decision to shift all to github was made 5 months ago. Still resolving this with these 4 steps would improve a future readonly bugs.php.net too.