Firmware governance
Contents |
Pandora Firmware Governance
The Pandora device is an open ecology -- only some of the hardware designs and occasional binary blobs like the WiFi driver are currently not open source; the rest of the firmware stack is open source (predominantly GPL with some LGPL). Not only can you rebuild your own firmware, altering it as you see fit .. you can fork it or run another firmware entirely! This is a device that was made for tinkering!
The official firmware is open source and open to patches from the public; to maintain high quality firmware releases a process needs to exist -- audit trails need to be kept to ensure licensing is clear, testing has to be ensured to keep quality high, and our standard practice for submission made clear so it is easy and swift to submit your work.
This process itself is open source -- as the ecosystem expands our model will change with it; if you are seeing problems, then contact one of the maintainers, leadership team, mailing list, or the community at large and help us sort it out :)
Communication
Mailing list
IRC and forums are fantastic of course, but can be a challenge to keep up with and locate everything going on for any one topic. For firmware development discussion without other noise, see the mailing list:
http://openpandora.org/cgi-bin/mailman/listinfo/firmware-dev
Note: This list is for on-topic discussion only; random chatter is not appreciated in this one, and will get the poster kicked.
IRC
The common IRC channel for random live chat is #openpandora on irc.freenode.org
Forums
Both the official forum http://boards.openpandora.org/ and the original home http://www.gp32x.com/board/index.php?/forum/61-pandora/ are the best places to hang out or toss ideas around.
Domain Owners
There are several main sub-domains to the firmware and each has a maintainer who has been guiding it since the project started. This is not to say this person has final word about direction or vision or submission, but is the spiritual guide behind that component who tries to ensure submissions mesh in properly, use appropriate conventions and styles. Note that these are _roles_ and not locked in stone seats; if one of the maintainers is out of commission for some time and the project needs to just keep moving forward, the role can be adopted by someone else. The mailing list will be used for discussion and should disagreements occur, be used for mediation.
The people below have commit access to the firmware source repository.
| Category | Maintainer | Notes |
|---|---|---|
| kernel | Notaz | (historically primary maintainer), backup is not yet defined |
| libpnd | Skeezix | (original author) with backups vimacs (original author of the scripts), Ivanovic (in general) and sebt3 (pnd_run.sh core component) |
| minimenu | Skeezix | (author) |
| scripts | EvilDragon | (original author) and vimacs (original author), with backup sebt3 (author and maintainer of many!) |
| firmware build (OE/Angstrom) | djwillis | (primary maintainer), backup is not yet defined |
| toolchain | djwillis | (original toolchain), Ivanovic (new official toolchain), sebt3 (new toolchain hosted in VM), cpasjuste (original toolchain) |
| release management | EvilDragon | (as Open Pandora Team software head) |
| GIT administrator | EvilDragon | (as Open Pandora Team software head) |
Submission Workflow
The general workflow for submitting a patch is something like this:
- Clone the appropriate section of the GIT repository - GIT is http://git.openpandora.org/cgi-bin/gitweb.cgi
- Apply changes and have fun
- Document and pass test cases
- Contact the maintainer of the subdomain the patch falls within - by mailing list above, or perhaps by PM in the forums, or email; for example, post first to the mailing list. In a pinch for libpnd submissions talk to skeezix, or notaz regarding kernel changes. But talk to the mailing list first, to keep discussion logged and centralized; if a backup neds to step up, the post history will already be there, right?
- If the maintainer is unavailable, contact the backups as listed above; they will know how to contact the champion, or can make the submission call themselves.
- If the maintainer and backups are not available, contact EvilDragon as release maintainer
Submission Standards
Submission are welcome! Historically the firmware has been built by a very small team, but that team size limits the number of changes that can be managed and developed simultaneously. If you've the skills and motivation to help, feel free to join the fray!
Patches have a few requirements; failing these requirements will cause your patch to be overlooked!
- Clearly documented -- what is this patch for?
- Clearly tested -- a list of test cases and test results -- the onus is on the submitter to test and prove testing; the committers have limited time and many people talking to them
- Proper format -- unix line ending, not dos line endings :)
