Wiki > Main > DevCon2007 (compare)
Difference: DevCon2007 (r31 vs. r30)
When: May 19-20 2007 Where: Stockholm Sweden
We invite you to participate in the Rockbox International Developers Conference 2007, to be held in Stockholm Sweden during the weekend May 19-20 2007.
We thought we'd get together for a two-day Rockbox hacking session, and that it would be cool if there were some other Rockbox devs who would drop by and share the fun.
If you consider or actually intend to come, please drop us a note about it (devcon2007@haxxBLAH_BLAH.se).
The agenda for this two-day Rockbox mania will of course be discussed so that we'll make something really good and worthwhile out of this unique opportunity.
Welcome! (Main Webpage: http://www.rockbox.org/devcon2007)
We have decided to sponsor the travel expenses for any developers who decide to go to Stockholm, with 100EUR from the Rockbox fund. This offer is valid for core developers only, i.e those with SVN commit access. Email us for questions regarding this.
Here's a list of persons who are planning to show up
Since we can code and IRC at home, too, we should focus on helpful group activities.
Bring your own laptop and DAP devices of choice. We'd need enough power outlets for wall-wart chargers. A USB hub might be helpful. A webcam for friends who can't attend physically will be used.
For the activities that require computers, we'll gather in the office of Contactor Data AB which is the company Linus, Björn and Daniel are employed by. We'll have access to computers, LAN/internet, WLAN, fast network to rockbox.org, white boards and similar stuff. We'd also get coffee going. And close proximity to Burger King and Mc Donalds!
Contactor's office is located a bit north of Stockholm, so it is close to the Arlanda Airport. Just 20-30 minutes by car/bus. It is also a 5 minutes walk away from the subway station that takes rougly 20 minutes to the city.
Regarding exact instructions on how to get from the airport to where we'll meet up, I will provide that too in time. Just let us know when you arrive and at which airport - some low fair airlines fly to the southern airport Skavsta, while all the big airlines fly to Arlanda. We'll gather at the office.
From Arlanda, try to take the airport bus to "Brommaplan" and exit at "Oddegatan/IBM" (1st stop, 23 minutes) or "Kista centrum" (2nd stop, 25 minutes). It is leaving infrequently: http://www.flygbussarna.se/tidtabeller/arlanda_s.pdf An alternative is to take the bus to "Cityterminalen" (2nd page in the PDF) and exit at "Järva krog" (1st stop, 27 minutes) or "Frösunda" (2nd stop, 30 minutes), which are slightly further away. That bus leaves every 10 minutes.
From Skavsta/Nyköping, take the airport bus to Stockholm city (80-90 minutes bus trip). From Stockholm City, go by subway to Akalla (25 minutes). Then there's a short walk, just about impossible to find for any newcomer who hasn't done this before! Call us and we'll guide you or meet up.
We pay everything in SEK (Swedish "kronor") here and the rate is roughly 1 Euro = 9.3 SEK. You might be able to trick some stores into accepting Euros (at a terrible exchange rate), but don't count on it. Credit cards are widely accepted and you can find ATM's all over that'll allow you to withdraw cash with credit cards.
You'll find that many people will speak at least some English and quite a lot of info will be available in English as well as Swedish.
If you want to extend your visit, or just prefer staying at a Hotel or Hostel (no, we will not feel offended if you do this!), we can of course assist you to find and reserve rooms. Expect to pay from 200 SEK for the cheapest Hostels (dorm beds style) to at least 600 SEK for two-star hotel rooms.
A hotel located very close to the DevCon location is Ibis Hotel Kista, Finlandsgatan 7, (www.ibishotel.com, hotel code 3121 - they do not want to be linked directly ). Distance about 600 meters from Contactor.
Peter brings some Belgian beers along: tripel karmeliet, duvel, westmalle tripel, 3 chimay's (red/white/blue) and kasteelbier
The culture within the project is that those who wish to contribute are willing to put their real names to their work. While this may mean that we are unable to accept the odd contribution, this is not a sufficent reason to change this policy which is line in line with many other open source projects.
We should credit other open source projects from which we have taken code. It would be impractical to keep a record of individual contributors from each project, but a list of projects from which Rockox uses code will be added to the end of the CREDITS file.
It has been noted that Rockbox is now so big that ROMbox no longer builds. While ROMbox is useful, there is no realistic prospect of bringing the firmware back down to a size where it can run uncompressed from flash on these targets. Since ROMbox is a refinement and Rockbox runs on all of these platforms without it, it has been decided to end official support for ROMbox.
We will continue to support older architectures until the support burden increases to a great degree. This may not be the case even if Rockbox becomes too large for the older target, since it may be possible to #ifdef out less essential features such as cuesheet and database support. A referendum of developers will occur before support is dropped for any platform.
The difficulties with the 80GB hard drive occur as a result of the drive not implementing a mode of access recommended but not required by the current ATA specification. At the present time it's not clear whether or not other future devices will adopt this approach. As a result it has been decided that we will fix support by something of a hack involving re-aligning the disk accesses in the ATA driver. This approach has some inherent inefficiencies and may be revisited if more drives have this "feature".
It is also desirable to increase the size of the FAT cache on platforms with more memory, since this will result in a large improvement in performance, particularly when doing a directory sweep when updating the database.
We discussed the "correct" way of supporting both 32/64 MB Ipod Videos and how to autodetect them, but we also decided that until that works we will change the build system to allow building for Ipod Video 64MB. To find out whether the Ipod 5.5G 30GB has 32 or 64MB memory, we suggest attempting to run a 64MB build on one.
In the long term, the way to fix this is to re-arrange the Rockbox memory map so that the plugins and codecs are located below the Rockbox code, with the main buffer at the end of the map. In this way memory can be autodetected and the only thing that will be affected will be the size of the main buffer.
While it is regrettable that there hasn't been a Rockbox release for over 2 years, the fact remains that the addition of software codecs has considerably complicated the code, and it's still not finished yet. We remain unwilling to put our names to a release that still has some issues, even though we are now a lot nearer to a fully function software playback system than we were last year. Also the issues with battery life on the PortalPlayer targets remain a concern.
We still plan to release a 3.0 version of Rockbox, but not until we are happy that the code works. The possibility of monthly snapshots was discussed, but the extra administrative effort that this would generate, combined with the difficulty of ensuring that such builds were any more stable than the daily builds is such that it would not make sense to do so.
The age of the last Rockbox release is such that we now recommend installing a current daily build ahead of the release version. The download pages on rockbox.org will be changed to reflect this. The 2.5 release page is to be made less prominent.
The bug tracker, patch database and documentation are all areas which give cause for concern. The number of out of date bugs and patches we will not be accepting is making it hard to see the wood for the trees. In lieu of releases we propose to announce weeks where we will focus on a particular activity, such as applying patches, fixing open bugs, or updating the documentation. We plan to co-ordinate our efforts via the #rockbox IRC channel at these times and hope that as many developers as possible will join in. The first of these will be focused on cleaning up the patch database and getting as many appropriate patches as possible into SVN. This will happen at the beginning of July, details to be announced at a later date.
Somewhat related to the above topic, we create a file for known issues that are likely to remain for a while and then close them in the tracker to prevent them from just sitting there and making it hard for us to see the bug reports to focus on.
We will try to create an interface between the build system and the documentation in the manual so that when new options are added to the Rockbox menus, sections relating to them are automatically created in the manuals as a place holder to give some indication that there is missing documentation. We also need to make sure that the manual is updated to reflect the new main menu structure.
The core team is happy to see the popularity of "unofficial" builds of software, although we still lack the resources to be able to offer support to end users for these builds. Where appropriate, we would like to see more code from these builds making its way back into the core code, and will make an effort to help developers of such builds to do so by offering support to them via the IRC channel.
Appearance is probably the most often criticized aspect of Rockbox. Recent changes such as the introduction of custom icons in the file browser have done a lot to improve the situation. Other developments we would like to see in this area include skinable status bar and scrollbars and the long anticipated introduction of viewports.
The adoption of a graphical theme as a default is long overdue and generally felt to be a good thing, but there is no current candidate that is fully cross platform, clean and unobjectionable. We need to find a solution to this problem as a matter of priority, but creating themes that work across all platforms remains a significant amount of work. Since ideas of impressiveness vary so widely, the focus of a default theme should be a clean, consistent and modern look rather than a focus on "eye candy".
There should be more badgers in Rockbox. We do, however, have exactly the right number of Bagders.
The fact that we now have so many US developers is very encouraging, and the fact that they've been unable to attend Devcon for reasons of cost is a shame. We will be offering financial support to Devcon West for this year. We feel that Rockbox Devcon will be at its most useful if we can gather as many developers from all over the world in the same place, so In future years we will focus on increasing the level of donations to Rockbox so that we can offer better subsidies for developers attending Devcon, and enable developers to come from further afield.
If we succeed in raising a greater amount of funding for Devcon then it becomes more important that the Rockbox project exist as a legal entity. Some concern was expressed as to whether going down this path might mean that we become a bigger target for litigious people, but Rockbox has a strong culture of rigorous commitment to its legal obligations. Further more, as things stand at the moment, those who provide resources to the project are not protected from agressive legal action. We do not want to have to deal with the administrivia of running an NPO, however, so will explore the possibility of finding an umbrella organisation to act as a legal and financial entity for the Rockbox project. Naturally any such organisation would need to be one that allowed Rockbox to continue to operate autonomously and to maintain control over way that the donations are used.
There is a strong need for a simplified end user experience when installing and uninstalling Rockbox. Rbutil is now finally at a stage where it is nearing release status, and we hope to make a release in the next couple of months. A release rbutil should be capable of performing all installation and uninstallation tasks. For future releases we may look at other housekeeping tasks such as voice file installation, config file editing, and database generation, but these are not the focus of an initial release, which we hope will make the end user experience a more positive one and reduce the support burden somewhat. As a policy, we wish to keep Rockbox Utility as lightweight as is reasonable, and provide links to external content where appropriate.
There's a popular patch that assigns a user defined function to this button, which is not currently used by Rockbox. There seems to be consensus that this would be a useful feature, and that we could make the default no action for a short press and enter the record screen for a long press. The other options should probably be any selection from the main menu, but in principle we would like to see this patch adopted.
We feel that it is counter-intuitive for left to cancel changes within the menus. This functionality is available via the Stop button, so we will change this behaviour. Leaving a menu by pressing the left button will no longer cancel changes.
r32 - 17 May 2008 - 09:19:19 - DominikRiebelingRevision r31 - 13 May 2008 - 17:44 - MarcGuay
Revision r30 - 20 May 2007 - 13:55 - PeterDHoye
Copyright © by the contributing authors.