as discussed on the developer meetings, we're now collecting nominations for the "pull request of the month". Everone can nominate for a PR that he likes. We'll vote informally sometime soon using doodle or whatever seems fitting. The winner gets something niiiice!
I begin by proposing Ludwig's vtimer fix PR, (following Oleg's hint),
I know it's bad style to propose one's own PR, but personally I liked
my "fix race condition in hwtimer_spin" PR better...:
https://github.com/RIOT-OS/RIOT/pull/324
Apart from that I just wondered whether a PR needs to have been merged
or if I could propose for example this fantastic PR that failed to
achieve the attention it deserves:
https://github.com/RIOT-OS/RIOT/pull/396
since the release is done it's time to stop collecting nominations and start
the poll for the "pull request of the month" or this time "the pull request of
the release".
The last two nominations came from me:
#226 Posix sockets
https://github.com/RIOT-OS/RIOT/pull/226
I think this one's great PR because it enables so much new features to be
easily integrated into RIOT.
#251 Fixed doxygen comments, focused on file headers and group definitions
https://github.com/RIOT-OS/RIOT/pull/251
Not only it was Hauke's first contribution to RIOT but it was on improving one
of RIOT's weakest points: documentation!
the poll is closed and the winner of the first PR of the month (or PR of the
release) is....LUDWIG for #374 Fix the bloody longterm vtimer bug -
https://github.com/RIOT-OS/RIOT/pull/374.
Congratulations! I'll announce his prize during the developer meeting next
Tuesday.
And, as the month of January is almost over, it's already time to nominate the
next PR of the month.
I'm nominating:
https://github.com/RIOT-OS/RIOT/pull/583
because it resolves a lot issues with the signal handling. *Now* desvirt in a usable tool to work with! (Riot is not crashing...)
and:
https://github.com/RIOT-OS/RIOT/pull/457
because it resolves a lot of strange handling of vtimer_now. I probably fixed a lot of future problems, which are hard to find. (But nobody will notice this PR...because those problems are fixed now.)
The poll will be open until the end of next week.
Iâll close the poll tonight at 5pm. Last chance to vote.
the poll is closed and the winner of the first PR of the month (or PR of the
release) isâŚLUDWIG for #374 Fix the bloody longterm vtimer bug -
https://github.com/RIOT-OS/RIOT/pull/374.
Congratulations! Iâll announce his prize during the developer meeting next
Tuesday.
And, as the month of January is almost over, itâs already time to nominate the
next PR of the month.
I'd like to take this opportunity to praise the giants this PR stands on:
    The Authors of Valgrind.
The issue more or less solved itself when running in valgrind because
valgrind would say something along the lines of:
"Your code just tried to access memory location 0x0 in
vtimer_longterm, line X."
Of course there was a little brainfoog involved with the resolution,
so I'm happy the PR won this poll but the lesson learned is:
    Use valgrind regularly!
cpu/native/README contains some hints on how to do this.
as discussed earlier, I started to draw an overview on the currently
(and planned) platforms, that are supported by RIOT. For this I created
a page in the github-wiki [1].
It would be very helpful, if some of you could go through the list and
update it accordingly, as I am not fully informed in regards of the
status for some platforms and there are still some gaps in the list...
Also further suggestions and/or ports that are currently in progress and
missing in the list are welcome!
Hi,
related, but not exactly on topic is this PR https://github.com/RIOT-OS/RIOT/pull/609 which should simplify the selection of radio modules in your projects. We need to know, which board has which radio installed.
as discussed earlier, I started to draw an overview on the currently
(and planned) platforms, that are supported by RIOT. For this I created
a page in the github-wiki [1].
Thanks a lot =)
Also further suggestions and/or ports that are currently in progress and
missing in the list are welcome!
What about links to issues related to the family/MCU/board (only
families have labels at the moment)?
Is supplier related to vendor somehow? I'm wondering because of the betty.
Hi,
great! A couple of remarks: Iâm not entirely sure what to make of the âsupplierâ column, might be difficult to fill in correctlyâŚ
Added the IoT-LAB and FOX platforms, as they are already partially supported
Cheers
Emmanuel
What about links to issues related to the family/MCU/board (only
families have labels at the moment)?
Is supplier related to vendor somehow? I'm wondering because of the betty.
The idea was the following: Vendor is the company, that produces the
MCU, as this is the source for getting Programming Manuals, Datasheets
and so on needed for porting to this device.
Supplier was meant to be the source, where you can get the actual
platform -> use case is someone who wants to start using RIOT on a
target and who will need then to buy a platform, then in the supplier
section you can find out, where to get a board or who was responsible
for making it...
Most of the platforms have a radio, which is one of the key elements to the corresponding platform. But I donât see the radio information listed.
It seems to the reader that the âStatusâ column only reflects the support status of the MCU, not the entire platform. But some radio drivers looks partially supported by the source repository, thus itâs somehow confusing to new comers like me to comprehend what âfull supportâ or âpartly supportedâ actually means.
I completely agree with you here - the list with the platforms was actually just created this morning and is subject to rework/improvement. We are in the progress of creating dedicated wiki-pages for each platform which would than list all this information about on-board radios and sensors as well as the state of the corresponding drivers. So this information should be available in the wiki soon⌠But maybe it would be a good idea to already say something about the radio in the main table as this is indeed quite useful information when talking about IoT!