Buildbot offers "bounties" for specific projects. This program is intended to support work on projects of particular interest to the project and its users which might not otherwise get done.

Collecting a Bounty

If you're interested in working on a bounty bug, the process is below. The intent of this process is to make sure that we have agreed on the expectations up-front, and that two people aren't unknowingly working on the same bounty at the same time.

  • Select the project below, and add a comment to the bug indicating your interest. If someone else has already expressed interest, that's fine -- just be aware that you've got competition!
  • Email an application to botherders@….
    • Your name and country of residence (to ensure we can legally pay you!)
    • The ticket # of the bounty ticket
    • Some background about yourself demonstrating that you can finish the task (links to Github repos, etc.)
    • The list of specific, objective things you will deliver at completion. These should be easy to unambiguously check off so there is no did-you/didn't-you disagreement at the end -- disagreement makes people grumpy and we don't want that.
    • A fairly detailed timeline, including intermediate milestones. If your application is accepted, we will use this to check that you're on schedule (or close) and to know if the project has fallen through, in case another bounty-hunter is waiting for a chance. Part-time work is fine, but you should have some work to show on a weekly basis -- "when I get a chance" is not good.
    • OPTIONAL: If the project breaks down nicely into parts that are individually useful to the project, you may propose sub-bounties for those parts that sum to the total bounty. For example, a $1000 bounty that involves features A, B, and C could be broken down into a $400, $300, and $300 sub-bounty. If you then complete A and B but not C, we will pay out $700 and re-list C as a $300 bounty.
  • The botherders will consider your application and respond appropriately: either accepting, rejecting with suggestions, or informing you that the bounty is currently in progress. The consideration will include:
    • Completeness of the application
    • List of deliverables satisfies the project (that is, if all of the deliverables are fulfilled, then the project is complete)
    • Timeline is realistic but not excessively long for the project

Once an application is accepted, we will sign a contract (see attachment) with you for work on the project. You be assigned a "mentor" who is your point of contact and is responsible for monitoring progress. You and the mentor will set up some kind of weekly communication (email, irc, etc.) to share progress against the timeline. If the timeline needs to be extended (e.g., something turned out to be more complicated than expected), the mentor can consult with the botherders to approve the extension. The mentor and the botherders will determine when the project is complete, based on the deliverables. If there is no progress or no communication for one month, the mentor will consult with the botherders to terminate the contract.

Botherders themselves may apply to work on a bounty, but then may not participate in the consideration of their application or any other application for the same bounty.

All submissions fall under the usual guidelines for contributing to Buildbot: LicensingYourContribution and SubmittingPatches.

Sponsoring a Bounty

Do you have a ticket or set of tickets you'd like to sponsor with a bounty? Get in touch at botherders@….

We're still new to this, so we'll work things out as we go. We have a few known constraints:

  • We (specifically, Conservancy) cannot handle payments for a bounty less than US$1000. If you want to sponsor a bounty for less than that, you'll need to handle any contracts and payments with the person working on the bounty. We are still happy to help with the evaluation of applications, mentorship, and so on.
  • If we do handle payments, we will need to have the funds in our account before we can sign a contract for work on the bounty. This is to avoid finding ourselves unable to pay out a bounty once the work is done.


Here are the available bounties:

Ticket Summary Owner
#3392 [MOSS Project] Better handling of EC2 to avoid cost overruns

This involves shutting down the instances, particularly when the master is stopped and/or crashes. This will help users keep their EC2 costs contained.

Users should be able to rely on Buildbot to only spend the necesary amount on EC2 instances, without any surprises at the end of the month. Successful completion of this project will address the known bugs below, but also provide some failsafe or monitoring mechanisms that an OSS project could use to head off any overbilling.

project scope

Completing this project will involve:

  • Establishing and documenting a recommended way to run Buildbot in EC2, encompassing worker configuration and startup
  • Providing support for shutting down an instance when it cannot connect to the master for a prolonged period (#3393)
  • Correcting spot-instance handling so that instances are not "lost" by the buildbot master (#2935)
  • Providing a failsafe method of managing EC2 instances that will reliably prevent over-provisioning and lost EC2 instances. Proposals should outline one or more specific approaches to this problem.


Bounty: US$5,000 - see BountyProgram

#2340 [MOSS Project] Please Change 'Slave' terminology rutsky

I am a manager at Cray Supercomputers, where we have recently started using Buildbot. Some of our employees have found the Master/Slave? terminology offensive. Please consider changing this terminology to Master/Worker?.

Some notes on how we communicate on this bug may be salient:

  • Buildbot does have a code of conduct - please be mindful of it when posting
  • By proposing this as part of the project's MOSS application, which has been funded, we have committed to making this change. As such, arguments that Buildbot should not make this change are not particularly relevant.


BOUNTY: US$10,000 -- see BountyProgram

My application for this bug:

Remaining tasks with this issue (rutsky's TODO list):

  • [x] remove worker (deprecated) property (it was deprecated even when it was slave (deprecated)) - don't forget update relnotes about this!
  • [x] move changes that done without fallback (i.e. introduced in nine branch) from worker_transition.rst into release notes of the next beta.
  • [x] copy/rename buildbot-slave to buildbot-worker.
  • [x] remove upgrade-slave command.
  • [x] update Trac wiki (add info about buildbot-worker, fix links on docs, update "slave" in text) - done, except historical/deprecated pages
  • [ ] Update master/contrib/ scripts (mostly done).

Simple cases done: . Hard cases probably should be removed, see issue #3658 .

  • [ ] setup redirection for renamed pages: #3530
  • [ ] take a look how to push new buildbot-worker to different distributions (e.g. how to get buildbot-worker into Debian and other distros).

Optional items:

  • [ ] Rework tests (make they names to be more uniform).
  • [ ] Check and rename left sb (slave builder), s (slave), sbd (slave build dir), sl, slv, sbdir, '/sl' variables.
  • [ ] rework warnings helper to use them as UnitTest?-derived class mixin.
  • [ ] replace inlined class name in WorkerForBuilderBase with __class__.__name__.


Last modified 12 months ago Last modified on Jan 30, 2016, 9:50:13 PM

Attachments (1)

Download all attachments as: .zip