Ubuntu Wiki

Frequently Asked Questions

Q: Should new scripts go into the arsenal 1.x or 2.x branch?

A: New scripts should go into the arsenal 2.x branch.

Q: How strict is the development branch requirement to follow the current architecture?

A: At this early stage of development we're not holding things to be strict on that count. Mainly we're looking for commitment that the scripts can be altered to fit the 2.x architecture eventually.

Q: How do I get my reports running automatically on reports.qa.ubuntu.com?

A: TBD

How to contribute

Contributing to arsenal

Contributions are welcome to Arsenal! Here's a step-by-step guide:

1. bzr branch lp:arsenal
2. Make your changes

3. bzr push lp:~<your-username>/arsenal/my-arsenal-branch

4. Create a unit test that covers your changes. Be sure to add your name to the AUTHORS file.

5. Verify your changes don't break run-tests

6. In Launchpad, click on "Propose for merging".
7. Bryce or another maintainer will review the merge proposals and indicate further changes required, or merge if the change is ready to go

If your change is a fix to an important bug that would apply to the stable branch (arsenal-1.x), please consider proposing it for that branch as well. The process is the same.

How to contribute to lpltk

For the development branch, lpltk-2.x, the process is essentially the same as contributing to Arsenal. The one difference is that since lpltk is packaged for Ubuntu, you should also add mention of any non-trivial changes in the debian/changelog file.

Stable fixes to lpltk-1.x are a bit different. The stable branch tracks the lpltk package in Ubuntu Precise, so all changes to lpltk need to go through the SRU process. So, first follow the above process to get the change accepted, then also follow the SRU process to get the change integrated into Ubuntu precise-proposed.

Becoming an Arsenal Reviewer

Once you've had a bunch of merges accepted into Arsenal you may request mentorship towards becoming a Reviewer. This duty comes with several responsibilities:

• Review merge proposals from other Arsenal contributors. Comment on problems that need fixing, or merge the branch if it looks ok.
• Subscribe to the arsenal-cron@ list and help follow up on and cron script errors that pop up
• Follow up on bug reports in the bug tracker
• Periodically review generated reports and run tests to check for breakages, and follow up on getting them fixed
• Help expand the test suite, fill in the documentation, improve coding style, and clean up the codebase

As a Reviewer, you will be granted permission to upload directly to trunk. Use this power wisely!

Becoming an Arsenal Maintainer

Reviewers who have obtained a deep understanding of how Arsenal works, and wish to fully participate may apply to become maintainers. This comes with the following duties over and above that of a Reviewer:

• Help define overall direction of architecture and development priorities
• Responsible for management of the Arsenal project in Launchpad
• Package releases of Arsenal and lpltk for Ubuntu

Open Tasks

• Add to wiki.ubuntu.com/Arsenal
  • Write tutorial about the Arsenal 1.0 collect-bug-data script
  • Write tutorial about the Arsenal 1.0 reporter script
• Port python-launchpadlib-toolkit to python 3
  • Blocked by python-launchpadlib being ported, but that's In Progress
  • Review code and build a todo list of what will need changed
• lpltk development
  • Write code documentation for python-launchpadlib-toolkit API routines. Needed for when we generate web docs via pydoctor.
  • Eliminate the 'bug' parameter to Person(). It appears to be completely unused.
• 1.x development
  • Review all extant branches, and identify any that need merged. Mark remainder as Abandoned, Merged, or Experimental.
• 2.x development
  • - arsenal/ubuntu.py: Update with current Ubuntu details - Create script that returns the union, intersection, difference of two JSON files. - Create icons for arsenal-devel, arsenal-user, and lpltk

    - Start a tutorial for Arsenal 2.0

• lpltk tests
  • - Get the current set of tests to pass - Make current set of tests less verbose, and just indicate pass/fail - Add test cases for each class

Unit Tests

In order to gain better stability assurance for arsenal, new non-experimental code should be accompanied with corresponding tests.

Arsenal will follow lpltk testing conventions. Tests can be written in either bash or python. A run-tests script in the root directory can be used to invoke each of the tests. The tests should exit with a non-zero error code if any test case fails.

tests/test_utils_config.py can be used as an example for python tests. Please try to keep coding style consistent across all python test scripts.