1,885
edits
Changes
no edit summary
<!-- ---------------------------------------------------------------------------------------------- Week 1 ------------ -->
= Week 1 (September 3) - Introduction === Wednesday (September 5) ==
=== Welcome ===
* About this course
<!-- ---------------------------------------------------------------------------------------------- Week 2 ------------ -->
= Week 2 (September 10) - Building from Source, & RPM Packaging =
== Monday (September 10) ==
=== Using ''make'' ===
# Send your [[SSH]] public key to your professors so they can create accounts for you on the [[CDOT Development Systems]].
==== Creating an RPM Package ====
=== To Do ===
By '''TuesdayMonday, January 24September 17''':
* [[DPI908/SBR600 RPM-Writing Lab|RPM-Writing Lab]]
<!-- ---------------------------------------------------------------------------------------------- Week 3 ------------ -->
= Week 3 (Jan 24) - The Fedora Build System =# [[SBR600 Mock and Koji Lab]]=
== Tuesday Monday (September 17) ==
=== Guest Lecturer: Dennis Gilmore, Fedora Release Engineer, Red Hat, Inc. Using Mock to Test Package Builds ===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.
== Thursday = To Do ===
== Tuesday/Thursday = Using Koji to Test on Multiple Architectures ===
<!-- ---------------------------------------------------------------------------------------------- Week 5 4 ------------ -->= Week 5 (Feb 7) 4 =
== Tuesday Monday (September 24) ==
=== Signing RPM packages ===
# 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>
=== To Do ===
By '''Wednesday, September 26''':
# [[DPI908/SBR600 RPM Signing Lab]]
== Wednesday (September 26) ==
=== Creating a YUM repository ===
# 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.
# Confirm that you cannot install from that repository using yum, since the gpgkey is unavailable to yum/rpm.
# 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).
=== ToDo ===
By '''Wednesday, September 26''':
# [[DPI908/SBR600 RPM Signing Lab]]
{{Admon/note|Edited to this point|}}
Lab
# Test it.
# Blog about this lab, and include a link to your repository-release package and the repository URL.
<!-- ---------------------------------------------------------------------------------------------- Week 5 ------------ -->
= Week 5 (Feb 7) =
= Week 4 (Jan 31) =
== Tuesday/Thursday ==
=== 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.
* [[User:Chris Tyler|Your professor]] will approve your project selection via the [[Winter 2012 SBR600 Participants|participants page]].
* 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:
* The project page must be filled in, including your 0.1, 0.2, and 0.3 targets.
** 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 been
* 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'''.
== Thursday ==