On Wed, Feb 18, 2015 at 9:46 AM, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Tue, 2015-02-17 at 11:14 -0500, Paul W. Frields wrote:
> Next meeting is Wednesday, 2015-Feb-18 at 1600 UTC/11:00am US-EST.
> Please feel free to suggest additional issues for the agenda if
> needed, and I'll add them.
> * Alpha freeze approaches! 2015-Feb-24
> - By this point features should be in a testable state.
> - https://fedoraproject.org/wiki/Changes/GNOME3.16
> - https://fedoraproject.org/wiki/Changes/LibinputForXorg
> - https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland
> - https://fedoraproject.org/wiki/Changes/Nautilus_Improvements
> * Test Days -- do we want test days for any of these features, or
> other release criteria?
> - Current schedule (nothing for desktop yet?):
> - Are we blocked at all on Spot talking with ABRT folks about data
> they are storing?
> - mattdm's request for uuid + Fedora version + Fedora edition/spin,
> is there an appropriate place for this in our purview?
A topic I would like to start discussing is Workstation vs Atomic. It
may be too early to put on the agenda yet. I haven't talked to Colin
about it and don't have a very concrete proposal, but I think we
should have it on our long-term roadmap that we'll end up with a 3
layer architecture of host (ideally an atomically updated image),
runtime and applications (see alex' work on concrete thoughts about
the runtime+app layers).
(I think you meant Workstation + Atomic, not vs. ;) )
I can see that being an option as well, but we really need to figure
out the "user wants to locally modify the image" problem. Having to
rebuild an entire new Atomic image for Workstation just to install
e.g. vim-enhanced system-wide seems excessive. It would also then
deviate from the official Workstation Atomic image.
People are used to yum/dnf install working. I think it needs to
continue to work in some fashion before we can really look at adopting
Atomic. It is an intriguing idea though, and I can see how it would
help both QA and the "too many updates" problem.