Page MenuHomeClusterLabs Projects

Patch Review
Updated 4 Days AgoPublic

PR Labels

github labels can be used to group PRs and tag them with useful information. This can be used to convey more information than you can fit in the subject, and without having to clog up the description. It also allows us to see everything at a glance on the main pulls page. Some projects go overboard with labels, but I want to keep their use fairly minimal.

Current labels are as follows:

  • branch: 2.1 - This should be applied to any PRs that are a backport to the 2.1 release branch.
  • branch: 3.0 - This should be applied to any PRs that are a backport to the 3.0 release branch.
  • review: in progress - This should be applied to any PRs that someone has started to review.
  • status: in progress - This should be applied to any PRs that aren't ready to be fully reviewed and merged. Typically, this will just be for drafts or PRs sent out as a proof of concept.
  • needs attention - This should be applied to any PRs that have been sitting around for a while and haven't gotten attention recently. Typically, this would be stuff that comes from an outside contributor where there's a little more back and forth, or from a contributor that's no longer active in the project. This should not be applied to PRs that just need someone to review them.

Suggested Reviewers

Different developers have different strengths and areas of focus. Use the following table to decide who might be the best person to review your patch. You can then add them under the Reviewers section on the right hand side in github.

AreaReviewer
Attributesclumens
Documentationanyone
C refactoringanyone
CTSlabclumens
Command line toolsanyone
Fencingwenningerk
IPC
Other daemonsnarwahl
Packaging
Pythonclumens
Regression tests
Schedulernarwahl
Unit testsanyone
XML
Last Author
wenningerk
Last Edited
Fri, Jan 31, 9:59 AM

Event Timeline

nrwahl2 edited the content of this document. (Show Details)
nrwahl2 added a subscriber: nrwahl2.

There's a LOT that I still don't understand about the scheduler (especially with regard to colocation), but I've probably reviewed or modified more of that code than anyone who's still on the team.

Let's be especially cautious with non-trivial changes for a while.