Project

General

Profile

Actions
Copy link

coordination #42191

closed

coordination #40475: [functional][y][saga] Establish YaST team split

[functional][y][epic] Have separate job group for YaST subteam

Added by riafarov over 5 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
riafarov
Category:
Enhancement to existing tests
Target version:
SUSE QA - Milestone 25
Start date:
2018-10-09
Due date:
2019-03-26
% Done:

100%

Estimated time:
(Total: 16.00 h)
Difficulty:

Description

Motivation

  • reduce scope for the reviewer (better focus), hence better understanding of the tests
  • will be easier to involve YaST team and collaborate with them
  • not much benefits for U-subteam, but definitely no harm
  • potentially will affect collaboration between subteams, learn HPC/HA experience

This is a prerequisite for the team split to declare responsibility of the team.

Acceptance criteria

  1. YaST sub-team has separate job group
  2. All stakeholders are accepting solution

Subtasks 6 (0 open — 6 closed)

action #42227: [functional][y] Move relevant scenarios to YaST job group on OSDResolvedriafarov2018-10-092018-12-04

Actions
action #42236: [functional][y] Identify all scenarios to be split into two parts, to have one part in YaST job groupResolvedriafarov2018-10-092018-10-23

Actions
action #42503: [functional][y] Define test matrix for the YaST job groupResolvedriafarov2018-10-152019-03-26

Actions
action #42578: [functional][y][spike] Rethink what is the purpose of create_hdd* scenariosResolvedJERiveraMoya2018-10-162019-02-12

Actions
action #42914: [functional][y][u] Update review workflow for split domainsResolvedoorlov2018-10-252019-01-15

Actions
action #43796: [functional][y] Implement ext4 specific test for autoyast installationResolvedJERiveraMoya2018-11-142018-12-04

Actions
Actions
Copy link
 #1

Updated by riafarov over 5 years ago

  • Due date set to 2018-10-23
  • Start date changed from 2018-08-31 to 2018-10-09

due to changes in a related task

Actions
Copy link
 #2

Updated by riafarov over 5 years ago

  • Assignee set to riafarov
Actions
Copy link
 #3

Updated by okurz over 5 years ago

  • Category set to Enhancement to existing tests
  • Target version set to Milestone 21

As I understood from the personal discussions we have the plan also only relates to osd and not o3. However, still I have talked to the openSUSE RMs what they think about multiple subgroups -> main question by dimstar was: what is the benefit for RMs when they mainly review and can we find a view to show the results from multiple job groups. I guess what we can think about is slightly changing the behaviour of "parent job groups" on the index page of openQA to provide a link to a test overview page which shows multiple job groups at the same time as referencing multiple job groups in the openQA test overview page already is supported.

Actions
Copy link
 #4

Updated by riafarov over 5 years ago

Some feedback regarding changes to o3:
riafarov: the main concerns are around ttm, which does not (yet) cope with it as well as having to check multiple groups to find out why a snapshot can't be published - from that PoV, the split is a 'bad thing(tm)'
riafarov, while I don't object, I would be nervous about the impact this split will have on the broader audience of visitors to openqa.opensuse.org - will the job groups be split and named appropriately that they'll make sense to joe on the street? How will they know which jobgroups are relevant to the release process, and which ones aren't?
riafarov, right now it's relatively easy.. only the openSUSE Tumbleweed job group is relevant to the release of openSUSE Tumbleweed, for example. Kernel, aarch64, power, are not
riafarov, I think it would be a prerequisite for any split that the openqa.opensuse.org webui can make it very apparent which are relevant to the release of which product
riafarov, also from a Kubic perspective, I'd be very , very, very, interested in how you'd split that. It is absolutely imperative, as part of the very existence of the Kubic project, that it's testing is integrated as part of the TW release process. and I do not want to have to check two places for it's status

Actions
Copy link
 #5

Updated by riafarov over 5 years ago

  • Due date changed from 2018-10-23 to 2018-11-06

due to changes in a related task

Actions
Copy link
 #6

Updated by riafarov over 5 years ago

  • Due date changed from 2018-11-06 to 2018-11-20

due to changes in a related task

Actions
Copy link
 #7

Updated by okurz over 5 years ago

  • Due date changed from 2018-12-04 to 2018-12-18

due to changes in a related task

Actions
Copy link
 #8

Updated by riafarov over 5 years ago

  • Due date changed from 2018-12-18 to 2019-01-15

due to changes in a related task

Actions
Copy link
 #9

Updated by okurz over 5 years ago

  • Target version changed from Milestone 21 to Milestone 22
Actions
Copy link
 #10

Updated by okurz over 5 years ago

  • Due date changed from 2019-01-15 to 2019-02-12

due to changes in a related task

Actions
Copy link
 #11

Updated by okurz about 5 years ago

  • Status changed from Workable to Blocked
  • Target version changed from Milestone 22 to Milestone 23

"Blocked" by subtasks?

@riafarov do you agree that we should be able to finish this epic within M23?

Actions
Copy link
 #12

Updated by okurz about 5 years ago

  • Due date changed from 2019-02-26 to 2019-03-26

due to changes in a related task

Actions
Copy link
 #13

Updated by okurz about 5 years ago

  • Target version changed from Milestone 23 to Milestone 25

-> #48173

Actions
Copy link
 #14

Updated by riafarov almost 5 years ago

  • Status changed from Blocked to Resolved

I believe we have established separate job group. Follow up tasks are visible in the saga, this is ongoing.

Actions
Copy link
 #15

Updated by szarate over 3 years ago

  • Tracker changed from action to coordination
Actions
Copy link

Also available in: Atom PDF