Given how long the Fedora 26 schedule slipped/ran over, we had a
*much* shorter F27 schedule than expected. That's had a number of ill
effects, not the least of which is extra impact on the Fedora
Engineering team. I'd like to avoid that in F28.
This isn't a discussion about general Fedora schedule strategy. F28
schedule will likely not shift based on F27 slip, as has been the case
for some years now. This discussion *is*, however, about how we can
do our best to minimize slips to F27 Beta and GA based on Workstation
related issues.
I talked to Kamil Paral in #fedora-qa today to see how people involved
in Workstation related development can best help.
As you know, there are release criteria for each release -- previously
Alpha/Beta/GA, now just Beta and GA. (The Alpha criteria still count,
because Beta has to meet them, i.e. Alpha + Beta.) Some of these
target specific activities, like login or the environment starting,
and some target classes of components, like .desktop files.
A couple things Kamil mentioned that I agree would help:
1. Regular testing of images *now*, before Beta freeze 2017-Sep-05.
Fedora QA regularly announces (on the test-announce@ list)
composes that are ready for testing. Here's the latest such
announcement: <https://tinyurl.com/y8c7zvor>
If each developer checked their particular area for release
blocking bugs early, it's more likely we can avoid late surprises
about something not working. (We have a limited number of folks
dedicated to QA, after all.)
2. Assist in creating automated tests for Workstation composes/apps.
The OpenQA system <https://openqa.fedoraproject.org/> allows graphical
testing of the desktop. Even just a few extra tests could be useful
based on what can save time in QA'ing releases. You can scroll down
to the Workstation entries here and click through to some of the tests
currently provided: <http://tinyurl.com/y9csgmmz>
Kamil also mentioned having Workstation folks available when blocker
meetings are going on, to allow for better decisions about truly
blocking bugs. While it may not be a good use of time for a lot of
people to attend the entirety of a blocker bug meeting, it *would* be
a good idea for us to be aware of the blocker meeting schedule, and to
stay tuned in #fedora-workstation and/or the meeting channel in case
of summoning.
Open to other ideas here as well.
--
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - - http://pfrields.fedorapeople.org/
The open source story continues to grow: http://opensource.com

There's a bug here but I really don't know where to file bugs for
workstation-ostree stuff, it seems plausible it could go on the GNOME
or Red Hat BZ's or where I ended up putting it:
https://pagure.io/atomic-ws/issue/7
--
Chris Murphy

Hi, to recap the ws-ostree situation, there are two repos:
https://pagure.io/workstation-ostree-confighttps://pagure.io/atomic-ws
I've updated the first to note the pretty ugly situation
that we included a "workstation ostree"
ISO with the Fedora 26 release, but due to the pungi → bodhi
switchover and bodhi not being ready to ship updates, Fedora
infra isn't currently updating the F26 workstation ostree repo.
I've hence adjusted https://pagure.io/atomic-ws to use
the ws-ostree config, but just build updates for it
in CentOS CI. Instructions are on that page if you want to
track F26 updates (I use it myself). It follows the at-most-once-a-day
bodhi stream.