make the features vertical tab the default

Yes, apparently some people have created upwards of 30+ features and need to categorize them. These tabs are actually the same as the Drupal module .info file package key, and we currently set the first tab to be active.

my b, I thought the package links were being sorted alphabetically but they actually were not. Should be fixed with: http://drupal.org/cvs?commit=325336

I'm still experiencing this issue in features 6.x-1.0-beta6.

Each load of /admin/build/features enables the testing tab by default, the provided module in features for testing is disabled (wish that could just go away really)
This appears to happen also in the dev version still.

Hi there, I am experiencing the same problem. The "Testing" feature category tab being the default active tab is a nuisance and I'm constantly having to click on another tab to get to features I need. Also, when I first started using features module I didn't even notice that there were other tabs for features I had installed... I only saw the "Features Tests" and I was scratching my head for a little while wondering where all my features were.

@yahn: thank you for that commit (comment #3) to fix the issue. The problem is that ksort($package_links); makes sure only the package "links" are sorted alphabetically, but not the actual package containers (.features-form-package) which are still not sorted properly.

I found where you are building the form in the features_admin_form function and I almost got into "fixing this" (by doing a simple usort($features)) and submitting a patch, but I feel that's just a bandaid solution and falls short of what joachim and I are actually hoping for, which is probably something like a flat list/table of all features with optional filtering/grouping such as what we see at /admin/build/views. Or possibly having an "All features" tab that is always the default tab would do the trick and be a big improvement on features UI.

One more thought....

Here in this patch is an extremely simple and temporary solution that may alleviate the PITA caused by this issue. The patch should be run inside the features module dir > tests

All I did was changed the "Features Tests" feature package from Testing to Features. This makes more sense since "Features" is the default package name given when you create a new feature. So, this basically puts all my features into one package/group/tab ("Features") until and unless I start using features with other package names:

package = "Testing"
to
package = "Features"

in features/tests/features_tests.info

The fix at #3 sorted the packages, but after "testing" was already given the class "features-package-active".
This patch moves the ksort() above the foreach, so that they're sorted before it determines which package should be active.
It's against dev, but it'll work against beta8 with some offset.
Unless reordering $vars['form'] is a bad idea, it's RTBC.

Thanks, committed here: http://drupal.org/cvs?commit=395774

Reordering $vars['form'] isn't necessarily bad but it's a little weird : ) I rearranged things so that we're not altering the form array directly.