Re: basic plan for two-week atomic images

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx>
> Fedora Project Leader
> _______________________________________________
> cloud mailing list
> cloud@xxxxxxxxxxxxxxxxxxxxxxx
> 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.
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux