Intro to FOSS Project Anatomy (Activity)

(Difference between revisions)
Jump to: navigation, search
(Browsing a Forge)
Line 124: Line 124:
  
 
Darci's Excellent Attempt
 
Darci's Excellent Attempt
Project: Sahana Eden - http://eden.sahanafoundation.org/wiki
+
* Project: Sahana Eden - http://eden.sahanafoundation.org/wiki
Tracker/Tickets: http://eden.sahanafoundation.org/report
+
* Tracker/Tickets: http://eden.sahanafoundation.org/report
Major Players: http://eden.sahanafoundation.org/wiki/WikiStart#WanttoContributetoSahanaEden
+
* Major Players: http://eden.sahanafoundation.org/wiki/WikiStart#WanttoContributetoSahanaEden
Forge/Repository:  https://github.com/flavour/eden/fork_select
+
* Forge/Repository:  https://github.com/flavour/eden/fork_select
Release cycle / version numbers:  
+
* Release cycle / version numbers:  
  
  

Revision as of 22:27, 6 March 2013

Contents

Preparation:

Description Introduce participant to common tools and processes 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  ?
Rights  ?

Background:

BLAH BLAH

Directions:

BLAH BLAH

Working Material

6. Anatomy of a FOSS Project [formerly known as: "Intro to FOSS Projects and Dynamics"] - 60 minutes

Stoney Peter Darci

Learning Goal: Understand basic terminology used in open-source development


       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


The idea here is to provide an introduction to the "landscape of a FOSS project". Introduce "major players" (well-known opensource projects?) and define major players (86?) Firefox - Mozilla GNOME Apache

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 key terms such as (use major players as examples to introduce these terms) 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: e.g. http://nvie.com/posts/a-successful-git-branching-model/ 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 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 Possible links: 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

Stoney's Ludicrous Attempt

Project: Sugar Labs Project: http://sugarlabs.org/ Tracker/Tickets: http://bugs.sugarlabs.org/ Major Players: http://git.sugarlabs.org/teams http://www.sugarlabs.org/index.php?template=page&page=contributors_teams Forge/Repository: http://git.sugarlabs.org/sugar-base Release cycle / version numbers Upstream/Downstream: diagram with explenation Communication: IRC: http://meeting.sugarlabs.org/ & http://chat.sugarlabs.org/ Mailing lists: http://lists.sugarlabs.org/ Blog: http://planet.sugarlabs.org/ Wiki: http://wiki.sugarlabs.org/go/Welcome_to_the_Sugar_Labs_wiki Roadmap: ??? Repository strategy: https://wiki.ushahidi.com/display/WIKI/Our+Git+Repository

Darci's Excellent Attempt

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox