Okay this might sound like a bit of obvious topic title, with as answer here. However we also have the 'issues' option these days where we can report issues of libraries, and it was enabled for mbed libraries. However I wonder if they are actually monitored?

For example quite some time I had suggestion for vastly improved InterruptIn speed: http://mbed.org/users/mbed_official/code/mbed/issues/4, and no reaction on it. (I don't expect it to be immediatly included, but some reaction is nice). Especially since the latest mbed release added some more overhead to interruptIn a vast improvement in handling speed seems handy to me. Also I think for example the KL25 can also use the same method.

Okay that is just a suggestion and not a bug. However also we have USBDevice with some fairly significant memory leaks: http://mbed.org/users/mbed_official/code/USBDevice/issues/1. Okay it is made a bit more recent, but there have been meanwhile other bug fixes on the usbdevice library, and it makes me simply wonder if those 'issues' pages are actually seen by mbed staff.

Then the other things, first more like an observation: look for example at http://mbed.org/handbook/Ticker. I understand the new option to chain functions can make some things neater (btw will there be something like a blog about those new options?). However assume you are pretty new to C++/programming, and you end up with that class reference when you want to use a ticker. Then I think all those options with cryptic names are really confusing, such as:

template<typename T >  
 pFunctionPointer_t      attach_us  (T *tptr, void(T::*mptr)(void), unsigned int t)  

I don't see a simple solution for that, but imo it is something to take into account.

Lastly a suggestion. On the platforms tab we can now add a load of different devices, which is very nice. But maybe also add the option to remove devices again from your account. For example when you don't use a device anymore. Or when you just randomly clicked on it to see what it would do :P

Hello Erik,

I had the same similar questions today on my mind which I was going to ask in the mbed devel group. While I was checking Ticker's code, I understood why it was easy to mix those 2 parameters there.

Here's my input:

First of all, I wonder how issues/bugs can be improved here on mbed. There does not exist any issue tracker, which would simplify tracking and even fixing bugs. Also when I eventually fix something, I have to come up with a commit name and also a branch name. Any proposals to this topic?

Bugs are monitored, at least I have that impression. Even though lately it has been "quiet" time here, a few bugs were resolved, but not advertised online. I completely missed that vastly improved InterruptLn topic which I would like to check out!

I personally consider as an improvement if bugs are gather at the one place something like bug tracking system. You can check who reported bug, who solved it and when (which revision contains its implementation). We can elevate this to devel group.

Regards,
0xc0170

I agree a proper bug/issue tracker where the status can be set, solution posted, closes when it is fixed with link to commit, etc would be a huge help. What would then also help is an option to list all bugs/issues for a user, grouped per library. Of course useful just for regular users, but especially for mbed_official, so both users and staff can see known issues/bugs and their status.

Currently it is imo definately an issue that bugs are spread out. You can never completely prevent bugs being reported in questions, but this forum has a huge overlap with the issues page of libraries.

From a users perspective I think it would mainly help alot if mbed staff actively mentions the status. By far the best solution for that is as you mentioned a proper bug/issue tracker. But also with the current situation it would help if someone just checks posts a little message to acknowledge the issue, and if possible mentions the priority. (For example the ticker_us issue it could be mentioned that it will definately be fixed asap, while others that it will be looked at, or that it is low priority). Assuming it isn't directly fixed, an update when it is being worked on, and later when it is fixed a short message it is fixed and which revision has the fix.

Random other example, this one: http://mbed.org/forum/bugs-suggestions/topic/4362/ (Don't worry, I got more of them :P). A bug that has been fixed, but would be nice if a reply is added it is fixed. Of course possible it was fixed without that post being seen, but for that an issue tracker would be alot better.

I think in general the communication from staff to users could be better. Of course I understand staff also has enough 'real' work to do, but still.

Hi,

I completely missed two points to this topic, issues are published on github: https://github.com/mbedmicro/mbed/issues?page=1&state=open

The revisions of mbed source started to be labeled in git. This helps to track changes/bugs between the git repository and the mbed online repository.

If stuff is busy, we are here to help the community! Any of us can track revisions, history of commits and start responding to bug reports here.

Regards,
0xc0170

While the issues on github have an advantage, I think it is a quite reasonable issue tracker, it also has a big disadvantage: It makes my question even more relevant, where should I put bug reports/suggestions? On these forums, as issue report on the library, or should i make a github account and report them there? It does seem to me to be definately alot more active than bugs reported on the issue pages. So where should we report them? Should I duplicate bug reports I have here to github?

I agree it is nice if staff responds to bug reports here, but it doesn't appear to happen. (Especially on issues on libraries, these forums are better).

Hi Erik, thank you for the issues you reported.

You reported them in the right place: opening an issue on the correspondent library.

In the past month, we have mainly been focused on:

1. Adding new target microcontrollers to the mbed library.
2. Refactoring the firmware of the mbed interface chip (for future developments we will announce in the next couple of months).

Because this type of development happen mainly offline, we missed few notifications.

I agree that having a page summarizing this information would help. (ie: collating all the open issues reported on repositories where you are one of the developers). I will pass this feature request to the web team.

That said, in following days, we will report back on some of the issues that you mentioned.

Cheers, Emilio

Any updates?

Hi Erik,

Sorry for the delay. I'm looking at the issues that you raised right now and I'll come back to you soon.

Thanks, Bogdan