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.
> Thanks,
> luke
>
> [0]: https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
> [1]: https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
