On Thu, 2010-01-07 at 12:44 -0500, Luke Macken wrote:
Yesterday I made an initial attempt at adding support for the No
Frozen
Rawhide[0] and Critical Path Packages[1] policies in bodhi.
From a bodhi/releng perspective, here is what the process will look like so far:
Releng adds F13 to bodhi as a `locked` release:
>>> Release(name='F13', long_name='Fedora 13',
dist_tag='dist-f13', locked=True)
Developer pushes update to F13:
If the package is in the critical path, force it to go to testing until approved
by releng/qa
QA/Releng test F13 critical path testing updates, and promote them to stable.
Just to properly set expectations, I'd like to point out that while I
agree that critical path package updates should meet a higher degree of
quality, we've not yet collectively determined what "testing updates"
means. QA is working on the infrastructure to support test automation
and bouncing around ideas as to what a quality package update might look
like. Until then, the same procedures in place for updates-testing now
will be used for critical path packages [1].
Releng kicks off a push of all updates:
If an update is for a pending release, and headed to stable, only move it's
tags:
dist-f13-updates-candidate => dist-f13
If an update is for a pending release, and headed to testing, do things as
normal:
dist-f13-updates-candidate => dist-f13-updates-testing
Release unlocks F13 release in bodhi upon RC, and everything returns to normal:
>>> Release.byName('F13').locked = False
Assuming I've understood everything correctly, here are the actions that I took
to implement this, and the test cases that I've written to validate the policy:
[X] 100% Bodhi No Frozen Rawhide & Critical Path support
[X] Ability to flag a release as 'pending'
[X] Disable the ability to push critpath updates directly to stable for pending
releases
[X] If a package is critical path, force it to go to testing
[X] Push testing updates to pending releases normally
[X] Only allow it to go to stable if approved by releng/qa
[X] Strongly discourage developers from pushing critpath packages directly to
stable, for all releases
[X] Strongly discourage pushing non-critpath updates directly to stable for
pending releases
[X] Tag stable updates to pending releases with Release.dist_tag
[X] Don't mash stable updates for pending releases, only move their tags
[_] 85% Test cases
[X] Create a pending release
[X] Submit an update for this pending release, as normal
[X] Ensure we can't push directly to stable
[X] Ensure it has a testing request
[X] Try pushing it to stable
[X] Ensure we can't as a normal developer
[X] Ensure we can as a member of the proper groups (releng/qa)
[X] Ensure devs cannot push critpath updates in testing to stable
[X] Ensure releng/qa can push critpath updates in testing to stable
[X] Ensure noncritpath updates in testing can be pushed to stable
[_] Try pushing updates (currently not possible via unit tests)
[_] Ensure the stable updates only get tagged
[_] Ensure the testing update gets pushed normally
Attached is the initial bodhi patch. Thanks to some clever re-use of an
existing DB column, I was able to implement this without making any schema
modifications, so deployment should be trivial. I've also hardcoded the
critical path package list in bodhi's config file until we can query the pkgdb
for it.
Please let me know if I'm misunderstanding any parts of this proposal,
if I am missing something, or if you find any bugs in my patch. I'll
try and get this into staging ASAP so we can test the masher portion of
this.