Features get marked "enhancement" and forgotten.

I think some better feedback mechanism is in order.

Take my example. I want exactly ONE change in the .config script in the default kernel build to turn on Mac partition support (so I can plug in my Mac format iPod - I can do the hfsplus.ko, but the actual partition support requires reflashing).

This is fairly innocuous and only adds a few bytes for the code to the kernel image.

Right now, it seems to be a matter of getting some totally unknown number of people to vote for it, but it may still never make it for other reasons (like Ogg support). Then they may or may not consider it for the next release.

Is there a technical argument? Is there someone at Nokia I can ask about this? Is there a way of getting a firm yes or no with a reason for the yes or no?

I can come up with reasons which might be discussed - right now there aren't even guidelines. At best it is the whim of Nokia.

It might bloat the code? How many bytes is "bloating"?
It might destabilize things? Where in the partition detection could it fail for a user?
We hate iPods? I prefer my tablet to the iPod, so it would be nice to suck the music out of it and onto the tablet.

Right now it seems to be:

1. Post it in bugzilla (ending up as an "enhancement").
2. Be ignored for months
3. When pressed, get a "we're looking at it", "No one has voted for it" or some other reply unrelated to any technical, business, or marketing merit.
4. Watch the next release go out without the enhancement.
Go back to step 2 and repeat.

I have a list of things, but most are owned by Nokia. For example, wlanconfd and bluetooth which use dbus interfaces can't do some things the command line tools do (and might need root were I to write them in C). Could they be enhanced to completely replace the CLI tools (e.g. a clone could be written of the CLI toolset using only calls to the dbus)? Will they? Probably never, though enough noise might make a few one-off updates or examples. Does Nokia want me to install the CLI tools for users? No.

Example - since I have GPS, I could also record access point information such as signal strength, channel, etc. A simplified Kismet without the packet monitoring. But the dbus "iwlist scan" equivalent API is NOT documented nor is there a working stand-alone example, e.g. a simple Python program (The only one I can find is broken).

I'm stuck between, No, you shouldn't have to install the SDK tools, and No, we won't extend the infrastructure to negate the need.

In some cases I would develop patches to improve existing programs, but would they be accepted and distributed (in the next update much less release)?

Also, lets say I have an improvement complete with tested patch for an existing application like the application manager that fixes something important and everyone would agree that it is an improvement. Where do I send it? Will there only be the possibility of "fixed-app-man" forever in Extras which is merely the patched version because it isn't "Nokia supported"?

Basically I would like a process that if I follow it, I would get a modification into the mainline software tree, or at least a specific and good reason for rejecting it. Even if the reason is a "business decision", it is a reason and a response. Not this perpetual consideration without resolution. And if the reason for the rejection can be addressed a way of resubmitting the improved request/patch.

Consider Extras as it is now (which is actually quite good). I have to have an account, prepare a real package with source and make sure everything including dependencies are correct, and then I can just upload it and send it to the autobuilder. Removing the GPG signature requirement helped, but I would be willing to do that. Then IF IT BUILDS, I can "promote" it to Extras. But it enforces some quality control and source requirement.

Since there is kernel flashing from installs (is this and the initrd documented?), maybe I could put a kernel identical except for Mac partition support in Extras, but it seems a lot of effort to have to reflash for one feature.