SWT/Committer Handbook

This page is useful for new committers who are not necessarily familiar with what such a role entails.

Prerequisites

A prerequisite is the SWT beginner guide, please read it if you have not already done so.

Introduction

In an ideal world, a committer is not only a steward of good code, but also the community of the project. With that in mind, a committer should be mindful of the following areas:

• Bugs: spend some time to review incoming bugs, talk to end users, triage old bugs, etc. Issue trackers are often one of the first points of contact for new contributors, so keeping a neat and organized issue tracker is important.
• Patches: review patches, from new contributors or existing committers. Allowing patches to go stale turns users away from a project and creates an unwelcoming atmosphere.
• Mailing lists: spend a bit of time to read mailing lists, and/or answer questions. Such effort is low cost and keeps the community alive.

The above topics will be explained in detail (and how they pertain to SWT) in the following sections.

The SWT Release Process

SWT is a platform level project, meaning it belongs to the Eclipse Platform. Eclipse releases every 3 months. Within that period, there are 3 milestones, and two release candidates (RCs).

Milestones

Technically there are three milestones, but the Eclipse Platform only observes M1 (the first milestone) and M3 (the last milestone). For any release, the milestone dates are posted at the start of that development phase.

Platform milestones are declared on a Friday. The week leading up that Friday is called "milestone week". This means development is frozen during that week (no new contributions accepted), and testing should be done. The deadline for contributions before a milestone are the Monday of the milestone week, before 18:00 EST.

An example milestone week:

• Monday: contributions until 18:00 EST, master frozen after that point
• Tuesday/Wednesday: testing and bug verification
• Thursday: nothing exciting, master still frozen
• Friday: milestone declared, master branch opened for contributions (unless it's an RC phase, in which case special rules apply).

Release Candidates (RC)

After M3, there are two release candidates: RC1 and RC2. Usually the only code that can be contributed here are regression fixes from the milestones, or urgent bug fixes. Special rules apply to approving submissions during this time, and of course after a certain day during RC week, no code can be submitted. Check the platform-dev@eclipse.org mailing list for rules of engagement.

Bugzilla

New and incoming bugs

Monitoring and responding to incoming bugs is a vital task and should be done whenever possible. Bugzilla makes this easy -- simply follow the SWT inbox in Bugzilla. You'll be sent an email any time a new bug is filed, or when activity on a bug happens.

• Log into Bugzilla
• Go to Preferences -> Email Preferences
• Under "User Watching" add the Platform SWT inbox user: platform-swt-inbox@eclipse.org

When responding to a new bug, look for relevant information provided. Examples of such include:

• OS/platform
• Architecture (if applicable)
• Build ID the bug reproduces with
• Steps to reproduce the bug (a pure SWT snippet is even better)
• Any other relevant information: themes, browser versions, etc.

If any of the above is missing, ask the user for it. Then attempt to reproduce the bug, and write a comment in the ticket if you can/cannot reproduce it.

Triaging older tickets

If areas of a project become inactive, then it's very possible that bugs will have piled up and gone unanswered. Any effort to sort through these bugs is valuable as it keeps the SWT Bugzilla tidy. This process is called triaging.

To start, create a search for all the bugs pertaining to the platform you're interested in. Here are ones for Linux, Mac, and Windows. Note that you can save these searches to your Bugzilla account.

Once these searches are created, sort by date and look at some of the older ones. Once you've chosen a ticket to triage and have it open, go through the following steps.

• Look for a snippet or steps to reproduce
  • If there is a snippet, run it in your workspace against SWT from master to see if it still reproduces. Be sure to check against all the current platform details.
  • If there are steps to reproduce, try and follow them as best as possible.
  • If neither a snippet, nor steps to reproduce are present, then ask the OP if the bug is still reproducible on a currently supported platform with a current version of SWT.
• If the issue is reproducible, write a comment stating as such and provide details of what OS/platform/SWT version/etc. you used to test. This is useful for other developers who may want to work on the bug.
• If the issue doesn't occur, write a comment stating as such and provide details of what OS/platform/SWT version/etc.
  • If no one responds to the ticket after a month's time, and it cannot be reproduced, then the ticket should be closed as CLOSED:WORKSFORME.

SWT-GTK had over 2000 open tickets starting in May 2015. Over 4 years that number has been reduced to ~275 as of May 2019.

Fixing bugs

Consider the scenario where: you've chosen a bug to work on, fixed it, and you (or someone else) has merged your Gerrit change. There are a few bureaucratic steps required in Bugzilla to finish the fix:

• Assign the bug to yourself
• Set the milestone to the appropriate one
  • For example: if you fixed a bug after M1 but before M3, the milestone field should be set to <RELEASE_VERSION> M3
• Write a comment quoting the Eclipse Genie merge comment, stating that the bug is in master now
• Mark the bug as RESOLVED:FIXED.

Note that you can make multiple changes to a bug in Bugzilla without pressing "Save changes" each time -- do them all and only hit "Save changes" once.
If you are merging a Gerrit patch from a non-committer, please be sure to follow the above steps (assign the bug to the contributor, not yourself). Additionally, add yourself as the QA contact for the ticket.