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.
On Fri, Aug 11, 2017 at 9:37 AM, Paul W. Frields stickster@gmail.com wrote:
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.
I'd recommend having one or two people on "blocker bug pager duty" on IRC, and then have the QA people ping them when discussion on Workstation related bugs begins. The blocker bug meeting is ridiculously long and there is no way to ever know exactly when discussion of a certain bug will start. Some simple contact points known before the meeting should make it more tolerable for everyone.
josh
On Fri, Aug 11, 2017 at 09:59:51AM -0400, Josh Boyer wrote:
On Fri, Aug 11, 2017 at 9:37 AM, Paul W. Frields stickster@gmail.com wrote:
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.
I'd recommend having one or two people on "blocker bug pager duty" on IRC, and then have the QA people ping them when discussion on Workstation related bugs begins. The blocker bug meeting is ridiculously long and there is no way to ever know exactly when discussion of a certain bug will start. Some simple contact points known before the meeting should make it more tolerable for everyone.
Kalev and Matthias, would you guys feel OK being on this list? I don't mind being on it, but that probably means one more degree of separation between the QA team and someone who can actually fix things.
On 08/14/2017 11:44 PM, Paul W. Frields wrote:
On Fri, Aug 11, 2017 at 09:59:51AM -0400, Josh Boyer wrote:
On Fri, Aug 11, 2017 at 9:37 AM, Paul W. Frields stickster@gmail.com wrote:
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.
I'd recommend having one or two people on "blocker bug pager duty" on IRC, and then have the QA people ping them when discussion on Workstation related bugs begins. The blocker bug meeting is ridiculously long and there is no way to ever know exactly when discussion of a certain bug will start. Some simple contact points known before the meeting should make it more tolerable for everyone.
Kalev and Matthias, would you guys feel OK being on this list? I don't mind being on it, but that probably means one more degree of separation between the QA team and someone who can actually fix things.
Sure, happy to. Just added the blocker review channel to my autojoin list.
On Tue, 2017-08-15 at 09:00 +0200, Kalev Lember wrote:
On 08/14/2017 11:44 PM, Paul W. Frields wrote:
On Fri, Aug 11, 2017 at 09:59:51AM -0400, Josh Boyer wrote:
On Fri, Aug 11, 2017 at 9:37 AM, Paul W. Frields <stickster@gmail .com> wrote:
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.
I'd recommend having one or two people on "blocker bug pager duty" on IRC, and then have the QA people ping them when discussion on Workstation related bugs begins. The blocker bug meeting is ridiculously long and there is no way to ever know exactly when discussion of a certain bug will start. Some simple contact points known before the meeting should make it more tolerable for everyone.
Kalev and Matthias, would you guys feel OK being on this list? I don't mind being on it, but that probably means one more degree of separation between the QA team and someone who can actually fix things.
Sure, happy to. Just added the blocker review channel to my autojoin list.
You can ping me any time I am on irc.
On Tue, Aug 15, 2017 at 11:11:19AM -0400, Matthias Clasen wrote:
ridiculously long and there is no way to ever know exactly when discussion of a certain bug will start. Some simple contact points known before the meeting should make it more tolerable for everyone.
Kalev and Matthias, would you guys feel OK being on this list? I don't mind being on it, but that probably means one more degree of separation between the QA team and someone who can actually fix things.
Sure, happy to. Just added the blocker review channel to my autojoin list.
You can ping me any time I am on irc.
I think specifically the need is to have some people known to be pingable during the blocker bug review process.
On Fri, Aug 11, 2017 at 3:59 PM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Aug 11, 2017 at 9:37 AM, Paul W. Frields stickster@gmail.com wrote:
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.
I'd recommend having one or two people on "blocker bug pager duty" on IRC, and then have the QA people ping them when discussion on Workstation related bugs begins. The blocker bug meeting is ridiculously long and there is no way to ever know exactly when discussion of a certain bug will start. Some simple contact points known before the meeting should make it more tolerable for everyone.
Sorry to reply with such a delay. We would really like to see more people present on the meeting, not just waiting for a ping in case we need something. The current reality is that we get almost no representation from any other team than QA (with the occasional exception of Stephen Gallagher from Server WG). Yet this is supposed to be "a collaborative effort between Release Engineering, Quality Assurance, Development, and Project Management" [1].
In the old times, the release criteria were generic and applied to all compose artifacts. With the introduction of "flavors", that is no longer true. We now have specific criteria for Server [2] [3] [4], Cloud [5] and Workstation [6] (maybe I missed some). I might be wrong, but I seem to remember that part of that flavor deal was that flavor owners would be responsible for defining flavor quality (which should include deciding when the quality is not met), and testing those flavors. This is not QA trying to offload all the work to someone else. We will be always present on those meetings. But we need your representation, you voice, when deciding whether certain bugs in your flavor should or should not block the whole release. And your technical expertise regarding those particular components, of course, that as well.
The blocker review meetings *are* ridiculously long (it's not because we enjoy it), and it makes no sense for Workstation WG people to be present for all of it. But we can definitely make adjustments. If we know we get some representative from your team, we can e.g. start with all Workstation-related bugs first. Or we can say "Workstation bugs will be discussed from 17:00 UTC". Or we can even split the meeting into several smaller ones, per working group. Or, if we know e.g. Kalev is always available during the usual blocker review timeslot, we can ping him and invite him over once the Workstation section starts. All of that works. We just need the people.
What arrangement would work best for you?
[1] https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting [2] https://fedoraproject.org/wiki/Fedora_27_Alpha_Release_Criteria#Server_Flavo... [3] https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria#Domain_client... [4] https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria#Server_Produc... [5] https://fedoraproject.org/wiki/Fedora_27_Beta_Release_Criteria#Cloud_Product... [6] https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#Default_appl...
desktop@lists.fedoraproject.org
-
Josh Boyer -
Kalev Lember -
Kamil Paral -
Matthew Miller -
Matthias Clasen -
Paul W. Frields