Re: Bugzilla or else to handle feature requests?
 

The best incentive IMHO would be Nokia demonstrating that votes are actually heard and acted on. I couldn't care less about karma personally.

Re: Bugzilla or else to handle feature requests?
 

Hasn't exactly this been happening in the last weeks?

Re: Bugzilla or else to handle feature requests?
 

This is what it is being done now, as Andre pouints out.

Please vote on your preferred bugs and enhancement requests. Help spreading the message. Votes are useful!

Re: Bugzilla or else to handle feature requests?
 

Bugzilla is not an appropriate place for feature requests. They quickly get lost in the biglist and make the overall product bug tracking more laborious.

Re: Bugzilla or else to handle feature requests?
 

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.

Re: Bugzilla or else to handle feature requests?
 

My thoughts on this topic are quite mixed.

Bugzilla is no place for casual enhancement requests. It looks too complicated to non-technical users and it would really need some tweaking to be userfriendly. And then I don't think bugzilla isn't the right place for non specific requests.

I really like the simplicity of brainstorm. It seems to have a low barrier for non-technical users. But this is also it's main problem. The sheer amount of duplicate and thus useless requests will be overwhelming pretty soon. There would need to be a lot of triaging.

With my webmaster hat on:
The nightmare of yet another system with it's own accounts is something I will loose sleep over ;)

Re: Bugzilla or else to handle feature requests?
 

Why do you think I'm asking here and there. :)

I think (except Andre ;) ) everybody agrees that Bugzilla is not an exciting tool for non-technical people. And non-technical people can have of course good ideas and features to suggest.

You could argue that non-technical people could find and report bugs too, true. But while a bug resolution most of the time goes down to technical aspects quite fast, an idea or a feature might have a long way of discussion and planning before the technicalities take over. In other words: a techie context is probably good for bug tracking but this is not necessarely true for a brainstom tool.


The good thing is that such triaging has also a low entry barrier: you don't need to be Multimedia developer to volunteer triaging Multimedia ideas. As long as you follow that category you are more or less capable to do the job. In fact Ubuntu's brainstorm has a visible "Report duplicate" feature.

Ah, yes. That's my main reason to still wonder.
I just noted that Ubuntu's Brainstorm has spinned off a project with more stakeholders: http://www.ideatorrent.org/ This means that basic maintenance and updates are held by a project we could contribute to as users.

This sounds like a much simpler and feasible scenario than trying to develop that functionality on top of Midgard or Bugzilla and maintain it ourselves.

Re: Bugzilla or else to handle feature requests?
 

But it also means that we have to create some kind of user synchronization, manage another vhost, manage a complete drupal setup(including security updates), manage an extra database, create a drupal maemo.org theme etc etc.

I'm not saying that this isn't doable, but it is easier said than done :D

Re: Bugzilla or else to handle feature requests?
 

No, I agree with you here, too. ;-)

Re: Bugzilla or else to handle feature requests?
 

I honestly couldn't say - I've been way too busy lately to look closely :-(

Having said that, most bugzilla email that landed in my inbox has been WONTFIX (or "fixed in Fremantle" which amounts to the same thing really). I haven't correlated these with number of votes, but a quick look at the current bugjar's top 10s by votes doesn't show much progress. Then you have things like #2504 (easyfix, patch provided, patch accepted by maintainer => sitting around for nearly a year => WONTFIX) which is simply inexcusable.

(This is not aimed at you btw. I think you're doing a fantastic job against impossible expectations, but Nokia still has a long way to go IMHO)

Re: Bugzilla or else to handle feature requests?
 

Poll closed and discussion made - including internal chat with some Maemo SW product managers.

My humble recommendation to the maemo.org team will be to implement http://www.ideatorrent.org/ - which is the spin-off of the Ubuntu Brainstorm. It would handle the feature requests with a low entry barrier for contributions. bugs.maemo.org would be left for pure bug reporting.

It would be good to have it running with som inertia by the Maemo 5 launch so the new generation of Maemo users would find it ready to get involved. This could mean have it before as alpha/beta, following more or less the same path than the Fremantle release itself.

About the tough bone of the user integration, it should be either a not very complicated hack or something solved (later?) through the single sign-on. I see no problem starting with new users if needed. The Wikipedia project didn't wait for user integration to start creating subprojects and become world most famous collaborative environment...

Re: Bugzilla or else to handle feature requests?
 

Saw on Planet KDE today that Suse launched OpenFate: https://features.opensuse.org/ and
http://en.opensuse.org/Proposals/openFate

Found this in http://aseigo.blogspot.com/2009/01/d...e-in-fate.html

Might be also worth to take a look at.

Re: Bugzilla or else to handle feature requests?
 

I really wish we setup something in maemo.org ...

The Fremantle beta period would be the perfect timing.

Re: Bugzilla or else to handle feature requests?
 

Gosh, it's been a long time since someone replied to this. What has happened to stop the brainstorm thing being implemented?

Re: Bugzilla or else to handle feature requests?
 

Nothing. The software has been written and put in place. Folks are working out workflow details and who will moderate.

Re: Bugzilla or else to handle feature requests?
 

So hopefully this could solve the problem of what to do about making suggestions and bug reports easier to make?

Re: Bugzilla or else to handle feature requests?
 

This thread has a long history. Let's continue in Task: Maemo Brainstorm