Difference between revisions of "Fall 2012 DPI908/SBR600 Weekly Schedule"

From CDOT Wiki
Jump to: navigation, search
(Created page with '{{Chris Tyler Draft}}Category:Winter 2012 SBR600 {{Admon/important|Tentative Schedule - Winter 2012|Please note that the schedule here is tentative. Week-by-week details will…')
 
(→‎SBR600 Only: Practical quiz)
 
(68 intermediate revisions by 13 users not shown)
Line 1: Line 1:
−
{{Chris Tyler Draft}}[[Category:Winter 2012 SBR600]]
+
[[Category:Fall 2012 SBR600]][[Category:Fall 2012 DPI908]]
−
{{Admon/important|Tentative Schedule - Winter 2012|Please note that the schedule here is tentative. Week-by-week details will be added as the course progresses.}}
+
{{Admon/important|Tentative Schedule - Fall 2012|Please note that the schedule here is tentative. Week-by-week details will be added as the course progresses.}}
  
−
Previous semester: [[Fall 2011 SBR600 Weekly Schedule]]
+
This is the Fall 2012 weekly schedule for the [[DPI908]] and [[SBR600]] courses.
  
−
= Week 1 (Jan 10) - Introduction =
+
Previous semester: [[Winter 2012 SBR600 Weekly Schedule]]
−
== Tuesday ==
+
 
 +
<!-- ---------------------------------------------------------------------------------------------- Week 1 ------------ -->
 +
= Week 1 - Introduction =
 +
== Wednesday (September 5) ==
 
===  Welcome ===
 
===  Welcome ===
 
* About this course
 
* About this course
 
* Introductions
 
* Introductions
  
−
=== Intro to SBR600 - Software Build & Release ===
+
=== Intro to DPI908/SBR600 - Software Build & Release ===
−
* [[SBR600 Overview of the Build and Release Process|Brief overview of the Build & Release process]]
+
* [[DPI908/SBR600 Overview of the Build and Release Process|Brief overview of the Build & Release process]]
 
* Introduction to the Fedora Project
 
* Introduction to the Fedora Project
 
** [[:fedora:Main Page|Fedora Project]]
 
** [[:fedora:Main Page|Fedora Project]]
Line 20: Line 23:
 
** Working with the Fedora Project
 
** Working with the Fedora Project
 
** [[SBR600|Course Outline]]
 
** [[SBR600|Course Outline]]
 +
** [[DPI908|Course Outline]]
 
* How this Course Works
 
* How this Course Works
−
** [[SBR600 Communication Tools]]
+
** [[DPI908/SBR600 Communication Tools]]
−
** How coursework is submitted in SBR600
+
** How coursework is submitted
 +
* Differences between [[DPI908]] and [[SBR600]]
 +
* Future
 +
** Winter 2013 Semester
 +
*** Project continuation course
 +
** Upcoming Events
 +
*** [http://fsoss.ca Free Software and Open Source Symposium 2012]
 +
*** [[:fedora:FUDCon:Lawrence_2013|FUDCon Lawrence 2013]]
  
 
=== To Do ===
 
=== To Do ===
−
'''By Tuesday, January 17:'''
 
−
# [[SBR600 Communication Lab|Communication Lab]]
 
−
# [[SBR600 Fedora Installation|Fedora Installation]]
 
  
−
= Week 2 (Jan 17) - RPM Packaging, Mock, and Koji =
+
'''By Monday, September 10:'''
 +
# [[DPI908/SBR600 Communication Lab|Communication Lab]]
 +
# [[DPI908/SBR600 Fedora Installation|Fedora Installation]]
 +
 
 +
{{Admon/important|CDOT Wiki Issues|There is an issue with some email sent from the CDOT Wiki system to MySeneca email accounts. This will prevent important e-mail such as initial temporary passwords, e-mail confirmations, and password resets from being received. This issue is currently being examined by Seneca ITS and we expect a resolution soon. '''The deadline for the communication lab is being extended due to this issue.'''}}
 +
 
 +
<!-- ---------------------------------------------------------------------------------------------- Week 2 ------------ -->
 +
 
 +
= Week 2 - Building from Source & RPM Packaging =
  
−
== Tuesday ==
+
== Monday (September 10) ==
  
 
=== Using ''make'' ===
 
=== Using ''make'' ===
  
−
* [[SBR600 make and Makefiles|make and Makefiles]]
+
* [[Make and Makefiles]]
  
 
=== Building from Source ===
 
=== Building from Source ===
Line 60: Line 76:
 
* [[RPM Queries|Querying the RPM database]]
 
* [[RPM Queries|Querying the RPM database]]
  
−
==== Creating an RPM Package ====
+
=== Using SSH ===
−
* [[RPM Packaging Process]]
+
 
 +
* Using [[SSH]] - a Review
 +
** Using public/private keypairs
 +
** Passphrase protection
 +
** Keyrings
  
 
==== Resources ====
 
==== Resources ====
Line 74: Line 94:
 
=== To Do ===
 
=== To Do ===
  
−
By '''Thursday, January 19''':
+
By '''Wednesday, September 12''':
−
# [[SBR600 Build-from-Source Lab|Build-from-Source Lab]]
+
# [[DPI908/SBR600 Build-from-Source Lab|Build-from-Source Lab]]
−
# [[SBR600 RPM-Writing Lab|RPM-Writing Lab]]
+
# Send your [[SSH]] public key to your professors so they can create accounts for you on the [[CDOT Development Systems]].
−
# Send your [[SSH]] public key to [[User:Chris Tyler|your professor]] so he can create accounts for you on the [[CDOT Development Systems]].
+
 
 +
== Wednesday (September 12) ==
 +
 
 +
==== Creating an RPM Package ====
 +
 
 +
* [[RPM Packaging Process]]
 +
 
 +
=== To Do ===
 +
 
 +
By '''Monday, September 17''':
 +
* [[DPI908/SBR600 RPM-Writing Lab|RPM-Writing Lab]]
 +
 
 +
<!-- ---------------------------------------------------------------------------------------------- Week 3 ------------ -->
 +
= Week 3 - Mock and Koji, Signing and Repos =
  
−
== Thursday ==
+
== Monday (September 17) ==
  
−
=== Mock: Testing BuildRequires ===
+
=== Mock ===
  
−
It's often difficult to get the BuildRequires in a spec file exactly right, because it's easy to overlook packages that are coincidentally installed on the machine. ''Mock'' is used to test that the BuildRequires for a package are complete and accurate, by creating a bare-bones [http://en.wikipedia.org/wiki/Chroot chroot] environment containing only the [[:fedora:Packaging/Guidelines#Exceptions_2|basic build packages]] plus any packages indicated by BuildRequires lines in the spec file.
+
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)
  
−
=== Koji: Testing on Multiple Architectures ===
+
Background information on using Mock:
 +
* [[:fedora:Using_Mock_to_test_package_builds|Using Mock to test package builds]]
  
−
Most developers and packagers have access to only a small number of system architectures (for example, a developer might have access to 64-bit AMD/Intel, but not have access to 32-bit AMD/Intel, s390 mainframe, PowerPC, or ARM systems). The ''Koji'' build system provides a mechanism for building a package in mock on one or more remote systems.
 
  
−
=== To Do ===
+
=== Using Koji to Test on Multiple Architectures ===
  
−
By '''Tuesday, January 24''':
+
* [[:fedora:PackageMaintainers/UsingKoji|Using Koji]]
−
# [[SBR600 Mock and Koji Lab]]
 
  
 +
=== To Do ===
  
−
= Week 3 (Jan 24) - The Fedora Build System =
+
By '''Wednesday, September 19''':
 +
# [[DPI908/SBR600 Mock Lab|Mock Lab]]
 +
# [[DPI908/SBR600 Koji Lab|Koji Lab]]
  
−
== Tuesday ==
+
== Wednesday (September 19) ==
  
−
=== Guest Lecturer: Dennis Gilmore, Fedora Release Engineer, Red Hat, Inc. ===
+
[[Signing and Creating a Repository for RPM Packages]]
−
Dennis is Fedora's release engineer. He will be visiting Seneca Centre for Development of Open Technology (CDOT) this week and has agreed to give a guest lecture on Tuesday.
 
  
−
==== The Fedora Build System ====
+
=== To Do ===
−
==== How Koji Works ====
 
  
−
== Thursday ==
+
By '''Wednesday, September 26''':
 +
# [[DPI908/SBR600 RPM Signing Lab|RPM Signing Lab]]
 +
# [[DPI908/SBR600 Repo Creation Lab|Repo Creation Lab]]
  
−
* Work on packages
+
<!-- ---------------------------------------------------------------------------------------------- Week 4 ------------ -->
  
−
= Week 4 (Jan 31) =
+
= Week 4 =
  
−
== Tuesday/Thursday ==
+
== Monday (September 24) and Wednesday (September 26) ==
  
 
=== Project Selection ===
 
=== Project Selection ===
Line 127: Line 165:
 
* Link your project title on the [[Winter 2012 SBR600 Participants|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.
 
* Link your project title on the [[Winter 2012 SBR600 Participants|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.
  
−
Over the next 2 weeks, finalize your project plans and get started on your project:
+
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.
+
* 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.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.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 been
+
** 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.
 
* You must have a strategy in place for reaching your targets.
−
You will make a brief (3-5 minute) presentation of your project plans on '''Thursday, February 9'''.
 
  
−
= Week 5 (Feb 7) =
+
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
  
−
== Tuesday ==
+
=== To Do ===
 +
 
 +
* Prepare your project page and project plan presentation.
  
−
=== Signing RPM packages ===
 
  
−
An RPM signature, like the digital signature used on many other software-signing systems, is a private key encryption of a checksum. RPM uses the GPG libraries for signing.
 
  
−
# Create a GPG key: <code>gpg --gen-key</code>
+
<!-- ---------------------------------------------------------------------------------------------- Week 5 ------------ -->
−
# Add the e-mail address associated with your gpg key to the <code>%_gpg_name</code> macro in <code>~/.rpmmacros</code> -- the line will look like this: <code>%_gpg_name "<i>e-mail-address</i>"</code>
 
−
# Find (or make) some packages to put in your repository. Make sure that the epoch-version-release is higher than that of any package with the same name in the Fedora repositories.
 
−
# Sign those packages with: <code>rpm --addsign <i>packagefile</i></code>
 
  
−
=== Creating a YUM repository ===
+
= Week 5 =
  
−
A yum repository is just a directory of packages and some metadata.
+
<!-- ---------------------------------------------------------------------------------------------- Week 6 ------------ -->
 +
= Week 6 =
  
−
To create a yum repository:
+
'''Note:''' Monday is the Thanksgiving Day Holiday.
−
# Create a directory that can be served. The protocol used to serve that directory could be http, ftp, nfs, or something else (the files can be served by putting them on a DVD too!). For http, create the directory within <code>/var/www/html</code>
 
−
# Put your signed packages in that directory.
 
−
# Create the repository metadata for that directory: <code>createrepo <i>/name/of/directory</i></code> (typically: <code>createrepo . </code>)
 
  
−
Notice that the repository metadata will be placed in a subdirectory named <code>repodata</code>
+
<!-- ---------------------------------------------------------------------------------------------- Week 7 ------------ -->
  
−
=== Testing ===
+
= Week 7 =
  
−
# Create a new repository file in <code>/etc/yum.repos.d</code> by copying and modifying an existing file in that directory. Keep <code>gpgcheck=1</code> but comment out the <code>gpgkey</code> file.
+
== Monday (October 15) ==
−
# Confirm that you cannot install from that repository using yum.
 
−
# Uncomment the <code>gpgkey</code> line, and point it to a new file within <code>/etc/pki/rpm-gpg/</code>
 
−
# Create that file by running (as your regular user): <code>gpg --export --armour <i>e-mail-address</i></code> and saving the output to the new filename (note: you'll need to be your regular user to perform the export, but the root user to install the file).
 
−
# Confirm that you can now install from your repository. You should be asked whether you wish to import the key for your repo the first time you use a package from that repo.
 
  
−
=== Creating a Repository-release RPM ===
+
=== Using GIT ===
  
−
To make it easier for users to access your repository, create a RPM containing:
+
Resources:
−
# Your repo file
+
* http://git-scm.com/
−
# Your GPG key
+
* https://github.com/
  
−
You can link to this repository-release RPM from a web page, and users can install access to your repository by simply clicking on that link. You can also include this package in a [[:fedora:Spin|Spin]] or [[:fedora:Remix|Remix]]. If you ever need to move your repository's location or make other adjustments, you can provide an updated repository-release package which will be installed when your users perform a <code>yum update</code>.
+
== Wednesday (October 17) ==
  
−
Take a look at the [http://rpmfusion.org/ RPMFusion] release RPM for an example.
+
=== Python Primer ===
  
−
=== ToDo ===
+
[[SBR600 Python Lab|Python Lab]]
  
−
Lab
+
= Study Week and FSOSS =
−
# Create a signed repository containing your RPM package.
 
−
# Create an RPM package that will install your repository configuration file and the key (repository-release package).
 
−
# Test it.
 
−
# Blog about this lab, and include a link to your repository-release package and the repository URL.
 
  
−
== Thursday ==
+
* Please don't leave your 0.1 milestone work until the last minute!
 +
* [http://fsoss.ca FSOSS 2012]
  
−
=== Project Plan Presentations (0.0) ===
+
= Week 9-13 =
 +
* Project work
 +
* Schedule:
 +
** 0.1 Milestone: TBA
 +
** 0.2 Milestone: TBA
 +
** 0.3 Milestone: TBA
  
−
* Project pages are due. Link from the ''Projects'' column of the [[Winter 2012 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.
+
= Week 9 - O.1 Release Presentation =
−
* Be prepared to give a professional, detailed, but very brief (2- to 4-minute) presentation on your project plan. Include:
+
* Please book your time slot on [[Fall 2012 DPI908/SBR600 Presentation Schedule| the presentation schedule page]] on a first come first server basis.
−
** Your approach to the problem.
+
* Each presentation should take no more than 10 minutes.
−
** 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.
 
  
−
= Week 6 (Feb 14) =
+
= Week 11 - 0.2 Release Presentation =
 +
* Please book your time slot on [[Fall 2012 DPI908/SBR600 Presentation Schedule| the presentation schedule page]] on a first come first server basis.
 +
* Each presentation should take no more than 10 minutes.
  
−
== Tuesday ==
+
= Week 12 - Practical Quiz / Research Paper Discussion =
−
=== Using GIT ===
+
== Wednesday ==
 +
=== '''SBR600 Only''': 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.
  
−
Resources:
+
Solution to the practical quiz:
−
* http://git-scm.com/
+
<center><embed src="http://www.youtube.com/v/9SK3rWAGsMQ?version=3&amp;hl=en_US" type="application/x-shockwave-flash" style="width: 400px; height: 326px;" allowscriptaccess="always" allowfullscreen="true"></embed></center>
−
* https://github.com/
 
  
−
== Thursday ==
+
=== '''DPI908 Only''': Discussion about the [[DPI908 Research Paper]] ===
 +
* Meet in the usual room
  
−
=== To Do ===
+
= Week 13 - Wrap-up =
−
GIT Lab
 
−
* Clone the repository at ssh://sbr600@scotland.proximity.on.ca/~/certs/
 
−
* Add your cert using the instructions in the readme.txt file.
 
−
* Blog about your experience.
 
  
−
= Week 7 (Feb 21) =
+
* The 0.3 Presentations are '''CANCELLED'''. Your 0.3 release is still due on '''December 8 at 11:59 pm.'''
 +
== Monday ==
  
−
== Tuesday ==
+
* Guest lecture/interview with Rob Bishop, Raspberry Pi Foundation tech evangelist.
−
* Demo of packaging some odd real-world cases for the Raspberry Pi
+
* Evening event: [[Raspberry Pi Hackspace Tour Toronto]]
  
 
== Wednesday ==
 
== Wednesday ==
−
* [[Raspberry Pi Fedora Remix]] launch event
 
−
 
−
== Thursday ==
 
−
* Python
 
−
 
−
= Break week! =
 
−
 
−
* Please don't leave your 0.1 milestone work until the last minute!
 
−
 
−
= Week 9-13 =
 
−
* Project work
 
−
* Schedule:
 
−
** 0.1 Milestone: March 9
 
−
** 0.2 Milestone: March 23
 
−
** 0.3 Milestone: April 13
 
  
 +
* Wrap-up - final opportunity to get help and feedback on your 0.3 release
  
 
<!--
 
<!--
Line 461: Line 483:
 
= Exam Week =
 
= Exam Week =
 
-->
 
-->
 +
 +
= Guest Lecture Notes =
 +
* [[DPI908/SBR600 Guest Lecture-Paul Whalen-20121119]]

Latest revision as of 18:03, 30 November 2012

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

This is the Fall 2012 weekly schedule for the DPI908 and SBR600 courses.

Previous semester: Winter 2012 SBR600 Weekly Schedule

Week 1 - Introduction

Wednesday (September 5)

Welcome

  • About this course
  • Introductions

Intro to DPI908/SBR600 - Software Build & Release

To Do

By Monday, September 10:

  1. Communication Lab
  2. Fedora Installation
Important.png
CDOT Wiki Issues
There is an issue with some email sent from the CDOT Wiki system to MySeneca email accounts. This will prevent important e-mail such as initial temporary passwords, e-mail confirmations, and password resets from being received. This issue is currently being examined by Seneca ITS and we expect a resolution soon. The deadline for the communication lab is being extended due to this issue.


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)
  • 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 Wednesday, September 12:

  1. Build-from-Source Lab
  2. 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:

  1. Mock Lab
  2. Koji Lab

Wednesday (September 19)

Signing and Creating a Repository for RPM Packages

To Do

By Wednesday, September 26:

  1. RPM Signing Lab
  2. Repo Creation Lab


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.
  • 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

Python Lab

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

Week 11 - 0.2 Release Presentation

Week 12 - Practical Quiz / Research Paper Discussion

Wednesday

SBR600 Only: 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.

Solution to the practical quiz:

<embed src="http://www.youtube.com/v/9SK3rWAGsMQ?version=3&hl=en_US" type="application/x-shockwave-flash" style="width: 400px; height: 326px;" allowscriptaccess="always" allowfullscreen="true"></embed>

DPI908 Only: Discussion about the DPI908 Research Paper

  • Meet in the usual room

Week 13 - Wrap-up

  • The 0.3 Presentations are CANCELLED. Your 0.3 release is still due on December 8 at 11:59 pm.

Monday

Wednesday

  • Wrap-up - final opportunity to get help and feedback on your 0.3 release


Guest Lecture Notes

Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=Fall_2012_DPI908/SBR600_Weekly_Schedule&oldid=91723"