Contents 1 Automating DE processes 1.1 BOSS Checks 1.2 Process Testing 1.2.1 DE_Trunk_SRs 2 Wish List 3 Bug Lifecycle

Automating DE processes

The DE workflow is (roughly) :

1. Developer branches package from P:DE:Trunk
2. Developer submits package to P:DE:Trunk:Testing
3. Boss runs checks on package
4. Boss creates branch of P:DE:Trunk
5. Boss submits package(s) to new branch

Later:

1. Boss rejects package

or

1. Boss notifies maintainers that checks passed

Then:

1. Package is accepted to P:DE:Trunk by a maintainer
2. bz is updated

BOSS Checks

BOSS runs the following checks (and stops as soon as one fails)

• check_submitter_is_maintainer
• check_package_built_at_source
• check_package_is_complete
• check_spec

To be done:

• changelog in proper format (present, syntactically correct)
• changelog has entry for this commit
• last changelog version matches spec file version
• tarball not changed within same package version
• executing spectacle doesn't change anything if .yaml present
• yaml must be present if spec is based on .yaml
• content of source tar ball should not change without its changing.
• check that old tarball has been removed if new one is introduced
• SR not empty (define empty?)
  • No changes at all. At times people are trying rebuild packages by submitting empty change. (Sage)

Process Testing

The Project:DE:BOSS:Trunk and Project:DE:BOSS:Trunk:Testing areas are used to test the processes.

The processes to be tested are deployed to /srv/BOSS/processes/Project/DE/BOSS/Trunk/

DE_Trunk_SRs

To deploy:

• set irc_channel and final_project
• Copy to Project:DE:Trunk
• symlink: SRCSRV_REQUEST_CREATE and SRCSRV_REQUEST_STATECHANGE in Trunk and Trunk:Testing

  cd Trunk
  ln -s DE_Trunk_SRs SRCSRV_REQUEST_CREATE SRCSRV_REQUEST_STATECHANGE
  cd Testing
  ln -s ../DE_Trunk_SRs SRCSRV_REQUEST_CREATE SRCSRV_REQUEST_STATECHANGE

Wish List

1. e-mail notice of SR's especially when SR is rejected
2. Check if package upstream has changed and do a report of the packages that needs to be rebased on top of the new upstream. Currently this check is done manually with https://gitorious.org/meego-developer-edition-for-n900/upstreamchecker/ script by N900 RE. (Sage)
3. In case package fails to connection failure start rebuild automatically after time X. (Sage)
4. Add architecture and repository to build error message. (Sage)
   • 14:06.33 < boss> Build failure in Project:DE:Trunk:Testing: meegotouch-theme More details soon
5. Update patterns based on package-groups package. (Sage)
   • We should have package-group package in the Project:DE:Trunk[:Testing] project that contains the CE package groups. This information should be when ever repository is published pushed to the repository with osc meta pattern or similar command.

Bug Lifecycle

The DE bug lifecycle is (roughly):

• 'open' -> FIXED -> RELEASED -> VERIFIED

1. Developer starts working on the bug/feature and sets to ASSIGNED
2. Developer submits package to P:DE:Trunk:Testing and documents changelog and/or commit properly (fixes bmc #1234;) - if changelog doesn't have a valid bug/feature reference the request MUST fail but we do not document the failure in the bug report
3. Bugzilla records the commit message with link to the repo and timestamp
4. Package is accepted to P:DE:Trunk (manual for now....)
5. Bugzilla records acceptance with comment and bug status is automatically changed to FIXED if bug is still in OPEN status (New, assigned, needinfo, reopened, waiting)
6. If bug is already in FIXED resolution, only acceptance comment is written in the bug report
7. If bug is not in OPEN status (New, assigned, needinfo, reopened, waiting) or resolved FIXED (eg. duplicate, wontfix, etc... or verified or closed) the request MUST fail but we do not document the failure in the bug report

Later:

1. Release is triggered
2. Bug status is automatically changed to RELEASED, a comment with a link to the image is created and the Target Build value is set to match appropriate release

Later still:

1. QA review the release and for each bug marked RELEASED, either change to VERIFIED or re-open

Note that eventually, both FIXED and RELEASED statuses would require specific credentials to be modified.