[PATCH] Bodhi No Frozen Rawhide & Critical Path support

[James Laska]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100107/d6300a5c/attachment.bin