Intro to FOSS Project Anatomy (Activity)
Contents |
Preparation:
| Description | Introduce participant to structure, processes and development tools used in FOSS projects. |
| Source | |
| Prerequisite Knowledge | None |
| Estimated Time to Completion | 60 minutes |
| Learning Objectives | |
| Materials/Environment | Access to Internet/Web and web browser. |
| Additional Information | Producing Open Source Software] by Karl Fogel |
| Rights | ? |
Background:
FOSS projects have a distinct culture and set of tools that support project development. The form of the culture and the specific tools vary somewhat across projects, but there is significant commonality such that many FOSS developers migrate easily among FOSS projects.
Now that you have an understanding of the communication tools used in FOSS environments, this activity will provide a high-level understanding of some of the culture and development tools that you will use when participating in a FOSS project. The goal of this activity is not to provide depth in any one tool or aspect of culture, but to provide a high-level view of what a typical FOSS project looks like.
Directions:
BLAH BLAH
Working Material
- Stoney
- Peter
- Darci
- TO THE ACTIVITY DEVELOPER
- A directed walkthrough into a specific project. Participants answer questions engaging with terminology.
- TO-DO LIST
- Pick project: Peter
- Gather links
- Draft walkthrough
- Candidate Projects
- OpenMRS
- Ushahidi
- Sahana
- Mifos
- Sugar (one-laptop-per-child)
- HFOSS Project list: http://xcitegroup.org/softhum/doku.php?id=g:hfoss_and_oss_projects
- https://developer.mozilla.org/en-US/docs/Introduction
- https://developer.mozilla.org/en-US/docs/Developer_Guide
- Topics
- What is a forge?
- Not all open source projects exist in a forge.
- The status of a project may be anywhere in the planning to mature stages.
- Regarding community - What major roles/teams exist within the project?
- releases: find version number system for project.
- code repository policies:
- packaging
- upstream (no artifact)
- downstream (no artifact)
- trackers: find the tracker
- tickets: look at some tickets
- roadmap, etc.: find the roadmap. How are releases managed? How
- Reference materials
- First couple of chapters in "Productively Lost" ? http://teachingopensource.org/index.php/Textbook_Release_0.8
- Mel has a good overview of some parts in "Roadmap Merge" activity here:http://mchua.fedorapeople.org/posse/POSSE-booklet.pdf
- http://en.wikibooks.org/wiki/Open_Source
Peter's Silly Attempt
- Pick a project: Lighttpd. http://www.lighttpd.net/
- Why? Small enough to get a handle on rather quickly (especially since they have a semi-documented plugin system **http://redmine.lighttpd.net/projects/lighttpd/wiki/HowToWriteALighttpdPlugin so you can build a small piece before building a big piece), important enough since used on popular websites.
- Tracker/Tickets: http://redmine.lighttpd.net/projects/lighttpd/issues
- tracks both bugs and features
- ticket status from new to feedback to actual patches
- locates most issues in modules of architecture
- Roadmap: http://redmine.lighttpd.net/projects/lighttpd/roadmap
- outlines which issues are going to be fixed in which release of the project
- stratifies issues into what's going into the next release and what's going to be addressed (a lot) later
- release numbering is 1.4.concrete for next release, 1.4.x for issues that's not too far off and may lead to smaller architectural changes (but might never get fixed if things go badly), 1.5.x for their next architectural vision which will overhaul the entire project
- Upstream/Downstream: ?
- uses svn/bzr?
- general definition: upstream is where THE source for the project lives, what will get released; downstream is where YOU work and try to fix things; patches go from downstream to upstream, not sure how in lighty yet
- Releases: http://blog.lighttpd.net/ and http://redmine.lighttpd.net/projects/lighttpd/wiki/Releases
- announcements are here but where the plan is I don't know
- two tracks: release candidates vs. stable releases; candidates are testing fixed issues among a wider group of people, not recommended for stable deployments
- Code? http://redmine.lighttpd.net/projects/lighttpd/repository
- IRC: irc://irc.freenode.net/lighttpd
- Community: http://redmine.lighttpd.net/projects/lighttpd/boards
- prefers IRC and forums
- has mailing lists as well http://redmine.lighttpd.net/projects/lighttpd/wiki/MailingLists
The Sugar Labs Project (http://sugarlabs.org/)
Read the information found here to get an overview of the goals of the project and the expectations of contributors.
Community -- In the first paragraph, they indicate the the community is organized into teams. Follow this link to the teams page. You will note that there are a wide variety of teams, each with a distinct responsibility. Follow the 'Contacts' link (found in the green option bar) for each of the following teams and summarize the information you find there on your faculty wiki page. For example, are there any commonalities? Is there something distinct for each type of team?
- Activity Team
- Development Team
- Documentation Team
Tracker/Tickets -- The Sugar Labs bug tracker can be found here. On your wiki page indicate the types/categories of tickets listed on this page.
Forge/Repository -- http://git.sugarlabs.org/sugar-base
- Release cycle / version numbers
- Upstream/Downstream: diagram with explenation
- Communication:
- Roadmap: ???
- Repository strategy: https://wiki.ushahidi.com/display/WIKI/Our+Git+Repository
Darci's Excellent Attempt
- Project: Sahana Eden - http://eden.sahanafoundation.org/wiki
- Tracker/Tickets: http://eden.sahanafoundation.org/report
- Major Players: http://eden.sahanafoundation.org/wiki/WikiStart#WanttoContributetoSahanaEden
- Forge/Repository: https://github.com/flavour/eden/fork_select
- Release cycle / version numbers:
- Communication: #sahana-eden Main Sahana Eden Channel;
