Thunderbird:PatchLove

From MozillaWiki
Jump to: navigation, search

<< Back to Thunderbird Testing

Welcome to the Thunderbird Patch Love wiki!

Help the Thunderbird Mozilla Messaging team give love to patches which have not yet checked in. Our objective is two-fold:

  • get patch to a state where it can be approved and checked in, and
  • encourage patch authors to stay involved in Thunderbird.

You will want to provide helpful and gentle advice to patch authors and others in the bug. If the patch author is not available, the get others involved who can help move the bug and patch forward. Common examples of why a patch might be stalled:

  • Patch is just a draft and no one commented on it
  • Patch author seems gone
  • Patch was not set for review
  • Reviewer hasn't done the review
  • Review has happened, but patch/bug needs revision, clarification, analysis

Giving Patch Love

Bugs with patches - queries:

I can code patches

You might start with query [3]. If you don't find anything of interest there, use queries [1] or [2] to find a patch that interests you.

I can triage bugs with patches

This is a skeleton procedure, a suggested set of steps for bugs in query [1] or [2]. A bug's circumstances may be more complex than this simple document can cover. Adjust to each bug using your best judgment and the assistance of other people involved in the bug to help move it along.

Not all bugs are waiting on something related to the patch contents - another bug blocking "this bug" is one example. If something is delaying resolution of the patch, please make appropriate comments, and add helpful keyword or status whiteboard notation like [waiting for ...] about the bug's status. For example "[blocked by bug 1234]".

1. Does the bug still exist? (perform normal triage - test, adjust summary, status, etc)

  no -> close bug
  yes -> add status whiteboard "[patchlove]" and continue

2. If appropriate, add comment to ask if the patch author is still available to help, and continue.

3. Does bug need an update/further analysis before fixing?

  yes or don't know ->
     are you able to provide advice?
        yes -> add advice, suggest next steps, etc
        no -> add keyword "qawanted"
  no -> continue

4. Are any patches still potentially valid?

  no or don't know -> comment & add keyword "helpwanted" & commit
  yes -> continue

5. Does patch have review pending? Such patches will show ...

    <requestor>: review? (<requestee>)
  yes ->
     has requestee (reviewer) commented in the bug about the patch?
        no -> email polite reminder to requestee & add whiteboard "[awaiting review]"
        yes -> suggest possible next steps to patch author, etc
  no -> add keyword "helpwanted" and comment to author that patch needs review
        - cite this review and checkin information
               http://www.mozilla.org/mailnews/review.html and
               http://www.mozilla.org/mailnews/review-mail.html
               http://developer.mozilla.org/en/Getting_your_patch_in_the_tree

6. If possible, stay engaged in the bug until it has made significant progress - because it may take some time, and more than one exchange of information, to nudge it enough that it is likely to get resolved.

References

Give us feedback

Please post a note in #bugday or #maildev about your experience: problems, questions, ideas to improve this or other documentation, and overall thoughts about Thunderbird. We really appreciate your help today and your feedback is very valuable.

Thanks!

Thanks so much for your help. Your efforts help us to improve Thunderbird. We could never do this without you and the entire volunteer community.