From Fedora Project Wiki
(for starters)
 
mNo edit summary
Line 21: Line 21:
* what projects do '''''you''''' have that you'd like to test and make more deployable?
* what projects do '''''you''''' have that you'd like to test and make more deployable?
* evaluate on the power of remixing, of different targets
* evaluate on the power of remixing, of different targets
* skills I had to learn in order to get this to happen (and how to learn them)
* skills I had to learn in order to get this to happen (and '''''how''''' to learn them)
** packaging
** packaging
** build system
** build system

Revision as of 17:48, 4 January 2010

Fedora Sugar Session

General point to make

This is the power of community and The Open Source Way. How much time/effort/resources would it have taken to get to this level of deployability for a radical software experiment under *your* (big company's) current IT paradigm?

Outline

  • history: Greg DeK started the effort to get Sugar into Fedora (ref: OLPC relationship)
    • Sugar got into Fedora, became accessible for people not having XOs
  • about a year ago, I started maintaining Sugar on a Stick, based on Fedora
    • started talking to folks at conference, got involved quickly
  • {work description goes here}
  • Sugar became actually deployable
    • successful v1 launch in June {press coverages go here}
    • same for v2 launch in December
    • more examples; successful deployments (Berlin & Boston)
  • is now even available on RHEL, the enterprise solution
    • you can have Sugar on your rock-solid systems
  • all of this happened in one year, pushed by an 18 year old high school student who was 16 at that time
  • what projects do you have that you'd like to test and make more deployable?
  • evaluate on the power of remixing, of different targets
  • skills I had to learn in order to get this to happen (and how to learn them)
    • packaging
    • build system
    • spins process
    • feature process (roadmaps & stuff)
    • how to engage with the community (culture of asking for feedback, accepting patches, etc)
    • bug reporting and issue tracking
    • version control
    • wiki
    • documentation
    • IRC