Revision as of 21:02, 11 May 2011

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
• tarball not changed within same package version
• executing spectacle doesn't change anything if .yaml present
• content of source tar ball should not change without its changing.
• last changelog version matches spec file version

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.