Difference between revisions of "Fall 2012 DPI908/SBR600 Weekly Schedule"
(→Session 4) |
(→Session 4) |
||
Line 264: | Line 264: | ||
=== Session 4 === | === Session 4 === | ||
− | |||
− | |||
− | + | '''Project''': | |
− | + | ||
+ | ''School Server Packaging'' | ||
+ | |||
+ | '''Name''': | ||
+ | |||
+ | *''Alexander Davis'' | ||
+ | *''Kalpaniya Parmar'' | ||
=== Session 5 === | === Session 5 === |
Revision as of 19:57, 4 November 2012
This is the Fall 2012 weekly schedule for the DPI908 and SBR600 courses.
Previous semester: Winter 2012 SBR600 Weekly Schedule
Contents
Week 1 - Introduction
Wednesday (September 5)
Welcome
- About this course
- Introductions
Intro to DPI908/SBR600 - Software Build & Release
- Brief overview of the Build & Release process
- Introduction to the Fedora Project
- Fedora Project
- Fedora ARM Secondary Architecture project at Seneca and at the Fedora Project
- Course Layout
- Project-based course
- Working with Open Source
- Working with the Fedora Project
- Course Outline
- Course Outline
- How this Course Works
- DPI908/SBR600 Communication Tools
- How coursework is submitted
- Differences between DPI908 and SBR600
- Future
- Winter 2013 Semester
- Project continuation course
- Upcoming Events
- Winter 2013 Semester
To Do
By Monday, September 10:
Week 2 - Building from Source & RPM Packaging
Monday (September 10)
Using make
Building from Source
- Obtaining source code
- Configuring the build
- Performing the build
- Testing the build
- Installing the built software
RPM Packages
- Differences between managing RPMS and Installing from Source
- RPMS provide a database of installed software
- Let you determine what's installed
- Automatic management of dependencies
- Identify the origin of files
- Permit easy update or removal
- Enable you to verify installation (useful for spotting file corruption and intrusions)
- RPMS provide a database of installed software
- Contents of an RPM Package
The RPM Database
Using SSH
- Using SSH - a Review
- Using public/private keypairs
- Passphrase protection
- Keyrings
Resources
- Two simple makefile examples
- Fedora Package Maintainers page
- Fedora Linux chapter 5 (see Seneca Library website > eBooks > View All > Safari > Fedora Linux).
- rpmlint
To Do
By Wednesday, September 12:
- Build-from-Source Lab
- Send your SSH public key to your professors so they can create accounts for you on the CDOT Development Systems.
Wednesday (September 12)
Creating an RPM Package
To Do
By Monday, September 17:
Week 3 - Mock and Koji, Signing and Repos
Monday (September 17)
Mock
Mock is a tool which builds a package using rpmbuild in a 'cleanroom' environment. This has several advantages:
- it tests the completeness of the BuildRequires in the spec file
- it avoids the installation of a lot of tools (BuildRequires) on the main host system
- it permits different tools and tool versions to be used for the build than are installed on the host (e.g., building for F18 on an F16 system)
Background information on using Mock:
Using Koji to Test on Multiple Architectures
To Do
By Wednesday, September 19:
Wednesday (September 19)
Signing and Creating a Repository for RPM Packages
To Do
By Wednesday, September 26:
Week 4
Monday (September 24) and Wednesday (September 26)
Project Selection
This is a project-based course. These projects involve participation in an open-source community.
- Projects are listed on the SBR600 Potential Projects page.
- Select two or three projects that are of interest to you.
- Do some initial research into what the project involves.
- Find out who to talk to in the community (start with the initial contacts listed on the project description)
- See what work has already been done related to that project. Check the Seneca wiki for work by previous SBR600 semesters, the upstream project's wiki and mailing list archives for information about the current state of the project, and the web for related information (similar projects being done by other groups).
- Join the mailing lists and IRC channels of the upstream community.
- Update the Winter 2012 SBR600 Participants table with your project information, according to the instructions at the top of that page.
- Do some initial research into what the project involves.
- On Thursday we'll sort out project conflicts.
- Your professor will approve your project selection via the participants page.
- Link your project title on the participants page to a page of the same name to create a project page. Copy the contents of the Sample Project page to your project page and fill in the details.
This week, finalize your project plans and get started on your project:
- The project page must be filled in, including your 0.1, 0.2, and 0.3 targets. Ensure that you have a link from the Projects column of the Fall 2012 DPI908/SBR600 Participants table to a page for your project; use the Sample Project template for your project page, and fill in as much detail as possible.
- Release 0.1: Proof of concept (e.g., a first draft of a package, a basic script, infrastructure set up on a test system) - Note that this must include the release of something, not just research, and must be done in consultation with the community.
- Release 0.2: Initial working state - Whatever you are working on -- package, script, infrastructure configuration -- should be working, although it may not be feature-complete, fully deployed, or fully documented. Feedback from the community should be solicited. If there is a review process required to submit upstream, it should be started.
- Release 0.3: Completed working state - The work is complete and documented. Any upstream review, whether formal or informal, has been completed, feedback has been incorporated into the project, and the work has been committed to the appropriate repositories (or released in an appropriate manner).
- You must have a strategy in place for reaching your targets.
Be prepared to give a professional, detailed, but very brief (2- to 4-minute) presentation on your project plan. Include:
- Your approach to the problem.
- Contacts and resources you've identified.
- Your plans for each release. Note that at each release you will be expected to actually release something -- an RPM, a script, test results -- as appropriate to your project. Identify what you are intending to release at each stage:
- 0.1 Release - proof of concept
- 0.2 Release - initial functionality
- 0.3 Release - tested and usable
- Challenges and potential pitfalls that you have identified, and your approach to mitigating those challenges so that you can complete your project on time regardless of things beyond your control.
- Time for a brief Q&A/Feedback session at the end.
- During your presentation, you'll
To Do
- Prepare your project page and project plan presentation.
Week 5
Week 6
Note: Monday is the Thanksgiving Day Holiday.
Week 7
Monday (October 15)
Using GIT
Resources:
Wednesday (October 17)
Python Primer
Study Week and FSOSS
- Please don't leave your 0.1 milestone work until the last minute!
- FSOSS 2012
Week 9-13
- Project work
- Schedule:
- 0.1 Milestone: TBA
- 0.2 Milestone: TBA
- 0.3 Milestone: TBA
Week 9 - O.1 Release Presentation
- Please book your time slot on a first come first server basis.
- Each presentation should take no more than 10 minutes.
Monday, Nov 5th, 2012
Session 1
- Name: Max and Andrew OW
- Project: ARMv8 Support Analysis
Session 2
Session 3
Session 4
Session 5
Session 6
- Name: Zhiping Yu
- Project: School Server Packaging
Wednesday, Nov 7th, 2012
Session 1
name: Ahmad Taychouri project: Limax Driver for Mali
Session 2
Name: Andrei Martinenco / Ryan Lawrence Project: OpenMax fedora
Session 3
Name: Jiecheng Qiu / Luis Fuentes
Project: Programming GPIO on Fedora
Session 4
Project:
School Server Packaging
Name:
- Alexander Davis
- Kalpaniya Parmar
Session 5
Name: Alon Yufidin / Daniel Delidjakov
Project: Packaging the Android Extensions for Eclipse
Session 6
Name: Gloria IP / Ruowen Tang Project: Andora Project Release