is the developer of the company.
cares of the support calls.
watch over the quality of the product.
is the manager.

Support call arrives

Bob, receive a phone call from an polite customer not happy about the greenish colour of the main button, and asks if it could be red.

Bob tries to reproduce the issue, realizes that the red button would better fit in the design of the product, and opens issue256 in the company’s ticketing system, which cares of triggering Alice.

Issue get worked at

Alice receive a mail notifying her about issue256, reads it carrefully, and begins coding.

Once done, Alice indicates to Mercurial that the commit just done belongs to issue256:

$ hg commit -m "Make the button red"
$ hg link tip issue256
Associating 42685d8fcc0f with issue256

Alice checks the local associations out of curiosity:

$ hg links

That done, Alice push her modification to the server:

$ hg push https://hg.company.com/
pushing to https://hg.company.com/
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
Remote accepted 1 links.
Those will be removed from the local storage

Issue get tested

Alice then release a test build for Carol, and set the status of issue256 to test.

Carol get notified from the ticketing system that issue256 waits for her approval and test it, satisfied from the red button, she set the issue status to resolved, and notifies Dave that a new issue has been solved, and that it might be time to cut a new release.

New release is made

Carol and Dave together anayse the list of solved issue since the last release by requesting it to the local web server:

Graph of issues solved since the last release

In this case, Carol knows well this issue has been solved, but she can check it again with the ticketing system, and then Dave can make the decision to release a new version.

Table Of Contents

Previous topic

Welcome to BugLink’s documentation!

Next topic


This Page