basic plan for two-week atomic images

[M. Edward (Ed) Borasky]

A diagram of the artifacts (images, RPMs, issues, source repositories,
etc.) and how they interact would be very helpful to those of us who
are mostly users.

On Thu, May 21, 2015 at 1:25 PM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> This is a strawman based on my understanding of current abilities,
> available software/systems, and of what the developers want. Please
> poke holes, reorder, add and subtract, etc.
>
> Phase I
>
> 1. F22 trees built nightly (already happening)
> 2. Images built from those nightly (I think right now only rawhide?)
> 3. Images go through automated tests, automatically (tunir; not fully
>    automatic yet, right?)
> 4. Every two weeks, latest image to pass those tests gets linked
>    on atomic.fpo, again all automatically (NEEDS DESIGN AND CODE)
>     - probably need a manual override
>     - page will present these images with appropriate setting of
>       expectations ("fedora qa not to blame for anything here").
>     - need something to happen if there aren't any that pass for
>       two weeks, which should not happen I hope, but, y'know)
>         * automatic message about image being out of date
>         * next successful image automatically posted? Or do we
>           skip two weeks?
>     - also needs: commitment to follow and fix if things break
>
> Phase II
>
> 5. Ability to include packages from a side tag, repo, something.
>    All full, legit Fedora packages destined for main repo but maybe at
>    a different speed. (Implementation needs work)
>    - possibly initially just selected packages from updates-testing?
>
> Phase III
>
> 6. Something to only expose Atomic users to _update sets_ that pass the
>    tests (because, hey, we have tests!)
> 7. Presumably, there will be a switch to F23 as base at F23 release;
>    will there be overlap (beta images) to make that smooth?
> 8. What else?
>
> Phase IV
>
> 9. Expand tests beyond tunir — test installs on hardware, etc.
> 10. Maybe create a new, special Fedora repository for packages
>     with version skew mainline Fedora — e.g. newer systemd
>     or hold older Docker version for some reasons. (Up for
>     discussion — that's why this is in phase 3!)
> 11. More what else?
>
>
> Does this seem basically sane and in line with what people are
> expecting? What's missing? What's extra? What's just wrong? :)
>
>
>
> --
> Matthew Miller
> <mattdm at fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
OSJourno: Robust Power Tools for Digital Journalists
http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists

Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.