POSSE California CS 2010 Thursday

From Teaching Open Source

Jump to: navigation, search

Day 4 session for POSSE. Theme for the day: Development

Contents

[edit] Status Check

  • Brief quiz/review of previous day.
  • Discussion of Overnight Deliverables -- status, problem encountered, concepts learned.
  • Rose/Thorn/Bud update from each participant
    • Rose: something learned
    • Thorn: problem encountered
    • Bud: something anticipated in the future
  • Physical wiki update.
  • Open source news -- current developments.

[edit] Running your Firefox Build using VNC

  • On the VM server:
    • Install vncserver: yum install -y tigervnc-server
    • Run: vncserver
  • On the client (your laptop/desktop):
    • Use vncviewer with ssh and compression: vncviewer -via user@posseX.fedoraproject.org localhost:1
    • Start a terminal (Applications>System Tools>Terminal) and start your firefox build (cd /usr/share/mozilla/mozilla-central/objdir*/dist/bin; ./firefox)

[edit] Using Bugzilla

Morning A Session

  • Introduction to Bugzilla
    • Bug/Issue tracking system, developed by Mozilla, used by a large number of Open Source projectsj
    • Other bug trackers include: Trac's ticketing system, others...
  • What is a bug (what isn't?!)
    • A bug (software problem)
    • An RFE (request for enhancement)
    • A design idea
    • A request for an administrative action (e.g., creating an account, revoking privileges, ...)
    • A review request for code or a package
  • Bugzilla basics (Note: each project's bugzilla instance can have different possible field values)
    • Each bug has its own number
    • Each bug has a single "owner" (Assigned-to), but multiple people can be subscribed to it to receive updates
    • Each bug is attached to a particular "product" and "component"
    • Each bug can be either "Open" or "Closed"
      • Open: has a "Status" (more information needed, unconfirmed, confirmed, ...)
      • Closed: has a "Resolution" (which may not mean that it was fixed/adopted/approved -- it may mean that that the owner decided against it, e.g, NOTABUG and WONTFIX resolutions)
    • Comments (and optional file attachments) can be added to the bug, forming an unthreaded discussion.
  • Searching
    • Duplicate bugs are a big problem -- searching before filing is critical
    • How to search effectively
  • Writing a good bug
    • Reduced test case
    • Sufficient information for repeatability
  • Writing a good comment
    • Don't comment unless it adds
  • Linking between bugs
    • Duplicate -- later bug is closed as a duplicate of the earlier bug, and cross-linked
    • Blocking and Depends -- indicates closure dependency
      • Tracker bugs
  • Flags
    • Four states:
      1. Blank - flag is not applicable
      2. "?" - Flag is requested (e.g., review requested, test suite requested)
      3. "+" - Flag request has been approved
      4. "-" - Flag request has been denied (may usually be reset to "?" after a fix)
    • Examples of flags:
      • Mozilla: blocking‑thunderbird3, wanted‑thunderbird3, blocking1.8.1.next, review, superreview, in‑testsuite
      • Fedora: fedora-review, fedora_requires_releasenote, needinfo, fedora-cvs
  • Review
    • Provides quality assurance
    • Applies to patches, documentation, packages
    • Often a back-and-forth process.
    • Examples...
  • Bugmail
    • Provides a way to stay informed of new bugs and changes to existing bugs
    • Customizable
    • High-volume: active devs usually have a separate account
    • Following an existing user
      • All bugmail sent to one user also gets sent to anyone following that user ("looking over their shoulder")
      • Useful for learning, vacations, disappearing community members

ToDo:

  1. Start following an active user on the Mozilla bugzilla. Blog about the experience tonight.
  2. Open review bugs for your package(s) on the Fedora bugzilla. Remember to mark them as blocking FE-NEEDSPONSOR. See Join the Fedora Package Maintainers.

Links

[edit] Developing in Community

Morning B Session

  • Many Open Source codebases are large, dense, multi-platform, and multi-language.
    • They are often too large to load into mental memory in their entirety.
    • To work effectively, you must be "productively lost".
      • Rely on your tools.
      • Rely on the community.
  • Navigating/searching
    • In most cases, it's necessary to follow a trail to find the code responsible for a particular feature or operation.
      • E.g.: User-visible messages - L10N files - internal message names - code - method or function - callers of that function - target code.
    • Basic tools
      • 'grep', 'find'
    • Advanced tools
      • LXR/MXR/DXR
      • IDE features
  • Changing
    • Make minimal change to the source
    • Use make to do smallest possible rebuild that will incorporate your change
    • Once the code has been found and confirmed to be the right code, add feature or fix bug incrementally
    • Do basic regression testing (more on Thurs)
  • Creating patches
    • Definition of a patch
    • Creating patches using diff
    • Creating patches using VCS tools
    • Applying a patch
    • Backing-out a patch

[edit] UI Bug

Afternoon Session

Lab: Fixing a Firefox Front-End bug

In this lab participants are exposed to another sort of bug: a so called "Request for Enhancement" (RFE) for a front-end change to the browser. This bug relates to how Firefox creates new tabs (i.e., the position) and will change it such that new tabs are added beside the current tab vs. at the end of the tab container.

In the course of the lab, participants will have a chance to work with the following:

  • JavaScript
  • The Mozilla Cross-Reference (MXR)
  • The Mozilla Build System
  • Mercurial, Diff, Patch

Objective

Currently, when you create a new tab in Firefox, it is appended to the end of the list of currently opened tabs. However, often one opens a tab in order to work on something associated with the current tab, that is, if I'm working in tab 6, I'd like the new tab to be placed at position 7 and not 21 (assuming there are 20 tabs open).

Here are the steps to reproduce this (commonly shortened to STR, especially in bugzilla):

  1. Start Firefox and open a series of tabs (i.e., CTRL+T)
  2. Move to the first tab
  3. Open another new tab and notice its placement in the list (i.e., it should be last)

You are asked to modify Firefox to alter this behaviour. You can choose to work without any aid and irc, or to follow a complete walkthrough of the lab. Work in whatever way is best for you.

Deliverable

When you have been successful, do the following:

  1. Use Mercurial to create a diff (a.k.a., a patch) of your changes.
  2. Create an account on Mozilla's test bugzilla server: http://landfill.mozilla.org/bugzilla-tip-pg/
  3. Create a bug for your work, describing the problem above
  4. Attach your patch to the bug
  5. Request that one of your colleagues review the bug. Ask them for the email address they used to create their landfill account, and then set the r? flag to that address

[edit] Overnight deliverable

  1. Review your colleagues' review request from the UI Lab and respond to others' comments on your own review request.
  2. Login to bugzilla and go to Preferences > Email Preferences. Add one of the following developers to your Watchlist (which means you'll get all of the bugmail that they get).
  3. Finish your RPM package, and then get it into the Fedora package review process. (See links above).

...and of course...

  • Blog, blog, blog
Retrieved from "http://teachingopensource.org/index.php?title=POSSE_California_CS_2010_Thursday&oldid=4139"