Good questions! What about RPMs that are in the image but not used? Can we filter those out? What about a distinction between the primary application for that image vs. other rpms used in its construction?

Also, do we want these to track the latest Fedora release, or should we have separate ones for F19, F20, F21, rawhide....?

And if so, do they have different policies? Maybe rawhide rebuilds on any change, current release rebuilds on security updates + any update to the primary application, previous release rebuilds on security updates only?

Will take first crack at this, then send to the list for revisions.

Some thoughts on this ticket:

• An option as well is for Fedora to run a registry. There are several advantages to this, some disadvantages.

• We need to decide if we acutally build all of these - some of them are what I'd call examples, not something you'd expect to run directly

First draft sent to list today, draft on wiki here:

https://fedoraproject.org/wiki/Cloud/Cloud_RFC_Docker_Trusted_Images_Rebuild_Policy

Leaving this open, but setting the milestone to beta and removing the meeting tag. Going to consider this mostly solved since the feedback I've gotten has been pretty much positive. Have a few questions to address, but I think this is mostly done.

Closing this ticket as part of trac clean up process. If you want to reopen, please reopen it after we move to pagure.io as atomic-wg.