Hello, in the last few weeks I have been working on defining use-cases which will lead the improvement of the Roundup tracker. As this is very important, I would like your valuable input in form of comments, criticism and advices. Use-cases in-lined: ============== Daniel is a great hacker, but the only time he has time to hack is when his child is asleep. And his child wakes up every now and then, pretty often actually. So when it starts crying, Daniel commits fix to that silly bug that has been hunting us for ages, but forgets to close down the bug so it stays open. Looking over bug tracker, Jane finds the same bug and starts working on the same bug. Wasted time. Daniel should be able to format commit message in such a way that would automatically close the bug. Maria is a student, and got involved in FOSS recently. With all the studies she has to do, she would prefer not to spend her time changing bug status. She should be able to format commit message in such a way that would change bug status to something other then the current status. Technical talk: USE CASE A: Integrate issue property editing with Mercurial, including: * USE CASE A1: Allow users to close issues via tokens embedded into commit messages. * USE CASE A2: Allow users to change issue status via tokens embedded into commit messages. Ronny is about to fix a torny bug, so he has a public branch for that. He is making great progress, but the issue that tracks the bug only contains a very out-of-date patch, prompting other developers to try to fix the same bug. Ronny should be able to tell Roundup about where his code lives, so users can get up-to-date patches/diffs automatically. This also allows other users to know all the code that changed to fix a given bug. Technical talk: Integrate branch and rich patch handling into Roundup * USE CASE B: Track all changesets that relate to a given issue: o USE CASE B1: Using tokens embedded into commit messages. (Post commit) o USE CASE B2: Using named branches, bookmarks. (Pre or post commit) o USE CASE B3: Using patchsets, bundles or whatchacallit for fat Mercurial patches. (Pre or post commit) Brett wants to fix a couple of related issues and has a local Mercurial branch for that. He would like his commit messages to include useful information for when his patch/branch lands in the Python repository. Besides the Mercurial->Roundup integration, a Roundup->Mercurial one that would allow one to fetch issue details and existing patches/branches with metadata would make Brett's work more valuable. Technical talk: USE CASE C: Add a CLI interface for Roundup so VCSs can query the tracker. * USE CASE C1: Automatically fetch issue data. * USE CASE C2: Pre-format output for greater usefulness in commit messages: o USE CASE C2.1: Setting issue properties. o USE CASE C2.2: Grouping changesets. * USE CASE C3: Fetch branch information for local cloning. * USE CASE C4: Add a Mercurial extension to exercize the CLI client. USE CASE D: Antoine is merging lots of branches and applying lots of patches to his local branch of the Python repository. He goes to each issue with a patch/branch and tells people whether their patches apply cleanly, just to avoid merge issues in the main branch. While he could use Mercurial Patch Queues (mq), Roundup would need to learn to both listen to and to submit patches to mq in order to completely replace Antoine's work with automated tools. Having a quick 'check if this patch applies cleanly' button would make triaging issues much easier. USE CASE E: David is checking the python-commits list for avoiding bad code from landing and nesting in the Python code base. He only sees the patches: while informative, it requires a bit of mental gymanstics to see how it would merge with the surrounding code. Whenever he thinks some code has tabs and spaces or lines that are too long, he runs pylint and reindent.py locally. He can only raise concerns about the code after it lands on the main repository. It should be easier to see the code changes in context. Having a way to check the code for mistakes in the tracker would make David's life a lot easier. USE CASE F: Van Lindberg is concerned about code submissions from non-core developers: how can the PSF re-license this code in the future without talking to each contributor, whether the PSF is safe from litigation based on copyrights of these contributions and related questions are always bugging him. While the PSF has Contributor Agreements exactly for these cases, it would be great to have the issue tracker and the VCS talk to each other, so they could ask contributors to sign (or declare to have already signed) the CAs when necessary. USE CASE G: Use Transplant/Patch Branch to generate patches from branches linked from Roundup. USE CASE J: Integrate the code/commits navigation interface with Roundup, so changesets, branches, etc., can be easily linked/browsed (starting) from the Roundup UI and issues can be created/linked to commits (starting) from the navigation tool UI. USE CASE K: For a given issue, add per patched file links for RSS logs (see http://selenic.com/hg/rss-log/tip/mercurial/hgweb/hgweb_mod.py). USE CASE M: Besides links to files, allow adding links to files at given versions/tags/branchs, links to tarballs and easy to clone links to branches and repositories. USE CASE V: Handle small branches (and maybe suggest using them for small patches?) generated using the convert extension with --filemap. ============== Improvements to the use cases will follow on the wiki page: http://www.roundup-tracker.org/cgi-bin/moin.cgi/GSoC09 Thanks for your attention and time. Respectfully, Mario