Open main menu

CDOT Wiki β

Fall 2013 SBR600 Weekly Schedule

Important.png
Tentative Schedule - Fall 2013
Please note that the schedule here is tentative. Week-by-week details will be adjusted as the course progresses.

This is the Fall 2013 weekly schedule for the SBR600 course.

Previous semester: Fall 2012 DPI908/SBR600 Weekly Schedule


Week 1 - Introduction

Tuesday (September 3)

Welcome

  • About this course
  • Introductions

Intro to SBR600 - Software Build & Release

Thursday (September 5)

To Do

By Tuesday, September 10:

  1. Communication Lab
  2. Fedora Installation
  3. Submit a signed copy of the Open Source Professional Option Student Agreement


Week 2 - Building from Source & RPM Packaging

Tuesday (September 10)

Using make

GNU Autotools

  • The challenge of adjusting a Makefile
  • The GNU Autotools / GNU Build System
    • GNU autoconf (Makefile.in -> Makefile via configure script)
    • GNU automake (Makefile.am -> Makefile.in)
    • GNU libtool
    • GNUlib

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)
  • Contents of an RPM Package

The RPM Database

Using SSH

  • Using SSH - a Review
    • Using public/private keypairs
    • Passphrase protection
    • Keyrings

Resources

To Do

By Thursday, September 12:

  1. Build-from-Source Lab
  2. Send your SSH public key to your professor.

Thursday (September 12)

Creating an RPM Package

To Do

By Tuesday, September 17:


Week 3 - Mock and Koji, Signing and Repos

Tuesday (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 Thursday, September 19:

  1. Mock Lab
  2. Koji Lab

Thursday (September 19)

Signing and Repository Creation

Signing and Creating a Repository for RPM Packages

To Do

By Tuesday, September 24:

  1. RPM Signing Lab
  2. Repo Creation Lab


Week 4 - Project Selection

Tuesday (September 24) and Thursday (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 Fall 2013 SBR600 Participants table with your project information, according to the instructions at the top of that page.
  • 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 2013 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: Basic Technical Work Complete - 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 - Basic Technical Work Complete
    • 0.3 Release - Completed Working State
  • 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.

To Do


Week 5 - Using GIT and Python

Tuesday (October 1)

Using GIT and FedPkg

Resources:

A lot of open source software (and some proprietary software!) is hosted at GitHub

Thursday (October 3)

Python Primer

Python Lab

Resources:


Week 6 - Presentations

Tuesday (October 8) and Thursday (October 10)

Project Plan (Release 0.0) Presentations


Week 7 - Project Work

Thanksgiving
Monday, October 14 is the Thanksgiving Holiday.

This week you'll be working on your 0.1 releases. We'll use the class time to discuss and work on issues and challenges that you're facing.


Study Week and FSOSS

  • Please don't leave your 0.1 milestone work until the last minute!
  • Your professor will be around campus most of the week, working on FSOSS. He is also available to meet regarding projects from Monday to Wednesday, by appointment.
  • FSOSS 2012 is Thursday/Friday October 24/25.


Week 8 - Project Work

No Class October 19 & 31
Our class will not be meeting this week. Your professor will be at Linaro Connect / ARM TechCon in California but will be communicating by e-mail (and possibly IRC). Please use this time to work on your 0.1 Project Milestones.


Week 9 - Project Work

No Class November 5 & 7
Our class will not be meeting this week. Your professor will be hiding in a secret location with no Internet access whatsoever.


Week 10 - Presentations

Possibly no class November 14
Class on November 14 may be cancelled.

Tuesday (November 12) and Thursday (November 14)

Release 0.1 Presentations


Week 11 - Practical Quiz & Project Work

Tuesday (November 19)

Practical Quiz

  • The quiz consists of one task: you will need to update an RPM to the latest upstream version of the software. For example, if the package is foo-2-1 and there is a new upstream version 3 of foo available, you will need to produce a foo-3-1 package. It would be worthwhile practicing this task in advance.
  • The practical quiz will be in T3076 (which not our normal room) so that lab computers will be available.
  • Make sure that you have access to your Fedora system, either on your laptop, on a removable disk pack, or through an SSH connection to one of your computers at home. Verify your arrangements! You may want to bring a Fedora Live system on USB or DVD as a backup.
  • You may use your notes and online resources during the quiz. However, you may not share information with other people during the quiz.

Thursday (November 21)

Problem Solving

  • We will brainstorm on solutions to project problems.


Week 12 - Presentations

Tuesday (November 26) and Thursday (November 28)

Release 0.2 Presentations


Week 13 - Wrap-up

Tuesday (December 3)

Problem Solving

  • We will brainstorm on solutions to project problems.

Thursday (December 5)

Wrap-Up

  • Final opportunity to get help and feedback on your project work.


Exam Week

Projects Due

Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=Fall_2013_SBR600_Weekly_Schedule&oldid=99706"