qa-devel June 2015

qa-devel@lists.fedoraproject.org

7 participants
11 discussions

[Fedora QA] #436: SSH access to systems in Beaker lab
by fedora-badges 20 Apr '16

20 Apr '16

#436: SSH access to systems in Beaker lab --------------------------------------+--------------------- Reporter: atodorov | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+--------------------- = bug description = Currently systems in Beaker lab can be accessed only through bastion.fp.o which is not as convenient as direct SSH into the system. There's also the question whether or not to open the systems directly to the Internet. This needs to be discussed with infra. Filing here so it doesn't get lost. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/436> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

Git Repsitory Hosting
by Tim Flink 13 Jul '15

13 Jul '15

One of the things on my longer-term todo list has been to get our canonical git repos out of bitbucket and on to something running free software (preferably something that we or infra controls). Now that we're getting closer to migrating off of our current phabricator instance, I think it's time to consider making this move for at least the repos that are currently hosted on bitbucket. As I see it, we have two obvious choices: using phabricator or using pagure [1]. They both have advantages and disadvantages (that I've listed at the end of this email) but both are 100% open source and hosted by Fedora infra. Thoughts? Tim [1] https://pagure.io/ Hosting git repos in phabricator -------------------------------- Phabricator has been capable of hosting git repos for a while now, the holdup has been me getting everything ready to migrate on to a new setup that's capable of doing it * we have more control over the repo hosting * we have more responsibility for making sure things stay up, are recovered in the event of a system failure etc. * would likely be easier to use some of phab's automation features if it controls the repos * ACLs for repos would be controlled in one place * would require users to upload ssh keys - I don't think we can (not even sure about should, if it's possible) get ssh pubkey data from fas @ account creation time * any extra load from clients cloning task repos would be on our infra and not causing issues for others A note that could be worth making is the permissions/policy structure on phabricator. It can be configured to allow users to create repos but in order to make that work well enough to justify doing, we'd need to allow all users to edit all repos as well - I don't see a more granular way of making this happen ATM. It's not something that isn't fixable long term if we're not happy with the "request repo for XXX from admins" process but figured I would mention it. pagure ------ pagure is a project started in infra. pingou is the main dev and it's gained quite a few new features lately. Despite the non-fp.o domain, it is infra hosted. * We don't have to worry about hosting our own repos * doing similar things to other groups - I don't think there's any interest by any other fedora groups in using phabricator unless something goes horribly wrong with pagure (I also suspect the odds of that happening are pretty low). * would require users to upload ssh keys but that's once for all the things that are (and eventually will be) hosted in pagure * we'd have to figure out how to handle the eventual pull requests that are out of process for us - the same thing kinda exists with bitbucket but I suspect it'll get more common as things progress.

3 3

2015-06-29 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink 29 Jun '15

29 Jun '15

# Fedora QA Devel Meeting # Date: 2015-06-29 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net We'll be holding a QA devel meeting on Monday. Last week's meeting was short-ish so we'll likely do more planning stuff this week. If you have any topics to add, respond to this email or bring them up during open floor. Tim Proposed agenda =============== Status Updates -------------- - Please have #info statements ready so we can get through this as quickly as possible Possible Topics To Cover ------------------------ - git repo hosting - fedora packaging These are optional and may be covered - group discretion after status updates. Open Floor ---------- - TBD

1 1

2015-06-22 Fedora QA Devel Meeting Minutes
by Tim Flink 22 Jun '15

22 Jun '15

========================= #fedora-meeting-1 Meeting ========================= Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-22/fedoraqa-devel… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-22/fedoraqa-devel… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-22/fedoraqa-devel… Meeting summary --------------- * roll call (tflink, 14:02:54) * mkrizek status report (mkrizek, 14:05:36) * sent a new proposal for logging rework (mkrizek, 14:05:48) * LINK: https://phab.qadevel.cloud.fedoraproject.org/D382 (mkrizek, 14:05:48) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T495 (mkrizek, 14:05:48) * investigation on branch detection for distgit directive (mkrizek, 14:05:48) * LINK: https://lists.fedoraproject.org/pipermail/packaging/2015-June/010693.html (mkrizek, 14:05:48) * LINK: https://phab.qadevel.cloud.fedoraproject.org/D383 (mkrizek, 14:05:51) * now working towards finishing D382 and D383 (mkrizek, 14:05:53) * tflink status report (tflink, 14:09:56) * helped get testCloud 0.1.0 release out the door (tflink, 14:10:05) * trying to fix mariadb setup issues with qadevel.stg (tflink, 14:10:05) * kparal status report (kparal, 14:17:10) * many reviews done (kparal, 14:17:14) * still waiting for more feedback for cli/conf/formula changes for disposable clients (kparal, 14:17:19) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T408 (kparal, 14:17:19) * together with jskladan found out that execdb was missing db indices once again (kparal, 14:18:43) * discussing distgit directive and its implementation on the packaging mailing list (kparal, 14:18:52) * LINK: https://lists.fedoraproject.org/pipermail/packaging/2015-June/010693.html (kparal, 14:18:52) * learned from lmacken that there should be an efficient way to query Bodhi for multiple build->update associations in a single request, need to look at it soon (kparal, 14:19:08) * taskotron build/deployment status (tflink, 14:24:39) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T505 (tflink, 14:24:44) * open floor (tflink, 14:31:53) Meeting ended at 14:32:53 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * tflink (64) * kparal (43) * mkrizek (19) * zodbot (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

Coding Style
by Tim Flink 18 Jun '15

18 Jun '15

Back to everyone's favorite topic - coding style and enforcement of that style. I'm not picking on Josef here - I'm sure I've submitted code recently with lint errors, this was just the review I was looking at which triggered the idea: https://phab.qadevel.cloud.fedoraproject.org/D389 Since the last discussion about coding style ended in a long discussion about PEP8, the bits we may not like about the standard and the exceptions that we'd want, I'm proposing that we use strict PEP8 with almost no exceptions. I'm not saying that that PEP8 is perfect or that there aren't parts of it I would like to tweak but - it's a well known standard, easy for non-regular contributors to understand and use - style checking tools tend to use PEP8 out of the box - if we don't allow exceptions, there will be less time spent on discussing details instead of being productive :) To be more specific, I am proposing the following: - all QA devel projects be have flake8 as the linter in arc config - no code be accepted with lint errors unless there is absolutely no other way to get around it - until we get our entire codebase PEP8 compliant, "if you touch a file, fix the lint errors even if those errors are not part of what you're changing" Any strong objections to starting this? Any strong objections should have an alternative proposal and a justification why that proposal is worth deviating from a well known and established standard. Tim

6 13

2015-06-15 Fedora QA Devel Meeting Minutes
by Tim Flink 15 Jun '15

15 Jun '15

================================= #fedora-meeting-1: fedora-qadevel ================================= Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-15/fedora-qadevel… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-15/fedora-qadevel… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2015-06-15/fedora-qadevel… Meeting summary --------------- * Roll Call (tflink, 14:02:55) * mkrizek status report (mkrizek, 14:04:32) * sent a patch changing log locations (mkrizek, 14:04:46) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T495 (mkrizek, 14:04:46) * LINK: https://phab.qadevel.cloud.fedoraproject.org/D382 (mkrizek, 14:04:46) * sent a patch adding distgit directive (mkrizek, 14:04:46) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T492 (mkrizek, 14:04:46) * LINK: https://phab.qadevel.cloud.fedoraproject.org/D383 (mkrizek, 14:04:49) * sent a patch adding fedmenu to blockerbugs (mkrizek, 14:04:51) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T466 (mkrizek, 14:04:54) * LINK: https://phab.qadevel.cloud.fedoraproject.org/D388 (mkrizek, 14:04:56) * sent patch fixing "Provided Variables" in docs (mkrizek, 14:04:59) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T497 (mkrizek, 14:05:01) * LINK: https://phab.qadevel.cloud.fedoraproject.org/D391 (mkrizek, 14:05:04) * created a ticket for sorting artifacts date directories (mkrizek, 14:05:06) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T498 (mkrizek, 14:05:09) * still have some open reviews to be completed (mkrizek, 14:05:11) * kparal status report (kparal, 14:08:25) * lots of reviews (kparal, 14:08:32) * proposed config/cli/formula changes wrt disposable clients (kparal, 14:08:36) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T408 (kparal, 14:08:36) * investigated nested virt and whether it would work for our purposes (part of T408) (kparal, 14:08:42) * jskladan status update (jskladan, 14:10:59) * T468/D387 depcheck: create per-build and per-update artifacts (will merge today) (jskladan, 14:10:59) * T470/D389 allow checks to provide URLs for their specific per-build/update logs from artifactsdir (provided hopefuly passable version today) (jskladan, 14:10:59) * PEP8-compliant-ish libtaskotron (jskladan, 14:10:59) * LINK: https://phab.qadevel.cloud.fedoraproject.org/differential/diff/1036/ (jskladan, 14:10:59) * status report - tflink (tflink, 14:19:01) * more futzing with beaker.stg, networking issues appear to be worked out for now (tflink, 14:19:01) * slight progress on testCloud, waiting for review, should have a new release soon (tflink, 14:19:01) * a few reviews, started to do some overdue ticket cleanup (tflink, 14:19:01) * looking into running taskotron with arm clients (tflink, 14:19:01) * planning - code style (tflink, 14:30:20) * jskladan posted a first runthrough of autopep8 on the libtaskotron codebase: https://phab.qadevel.cloud.fedoraproject.org/differential/diff/1036/ (tflink, 14:30:53) * the main idea is to have a coding standard and not spend eternity debating over what set of rules is "best" (tflink, 14:32:14) * LINK: https://phab.qadevel.cloud.fedoraproject.org/file/data/yar3gaju7rtjcsn33bjk… (kparal, 14:52:33) * farther discussion on qadevel@, hopefully not a debate until the end of known time :) (tflink, 14:57:06) * planning - tasks (tflink, 14:58:13) * pester tflink if anyone runs out of tasks to do :) (tflink, 15:03:04) * open floor (tflink, 15:03:21) Meeting ended at 15:04:20 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * tflink (99) * kparal (62) * jskladan (33) * mkrizek (30) * pwhalen (9) * zodbot (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

2015-06-08 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink 08 Jun '15

08 Jun '15

# Fedora QA Devel Meeting # Date: 2015-06-08 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net We'll be holding a QA devel meeting on Monday. Last week's meeting was long so we'll try to keep this one short Tim Proposed agenda =============== Status Updates -------------- - Please have #info statements ready so we can get through this as quickly as possible Possible Topics To Cover ------------------------ - abidiff prep work - fedmsg deduplication These are optional and may be covered - group discretion after status updates. Open Floor ---------- - TBD

1 1

Fedmsg Emitting
by Martin Krizek 03 Jun '15

03 Jun '15

Before we start sending fedmsgs we need to discuss a few things. We don't have to find solutions to all these problems, just keep them in mind when designing the solution we're going to start with: 1. How often do we send fedmsg a) per-task b) per-update c) per-build a) and b): we can list affected packages in a fedmsg. I am not sure if there are any limits when it comes to fedmsg size. Whether the infra folks would be more happy with less larger or more smaller fedmsgs (or it doesn't matter). I guess c) allows to easier filtering in FMN. 2. Who do we target: users, systems or both The issue here is with tasks that repeatedly test one update. Currently we check if there's a bodhi update comment with the same result already and if so, we don't post the comment again. To do something like that with fedmsgs we'd have to have a code running somewhere that would check against its database whether an incoming result is a duplicate or not. The question is where the code would run. Bodhi comes to mind since it already has information about updates and so is good for tasks that work with bodhi updates. However, there might be tasks that work with something else, like composes. In this case we'd probably have the code on taskotron systems. So if we target systems we'd just send all results in fedmsgs and let the systems consume them and do whatever they want to do with them (e.g. bodhi can squash all the tasks relevant to specific update and notify the maintainer of the package via fedmsg about the result). If we target users, we'd have to have some logic to limit rate of fedmsgs ourselves but that would mean hiding some of the results (although duplicates) from the world. So the question here is where to put the 'deduplication logic'. Emitting all results is the simplest solution as a starting point. Thoughts? Thanks, Martin

3 6

[Fedora QA] #468: Fedora 22 Translation (L10n) Test Day
by fedora-badges 02 Jun '15

02 Jun '15

#468: Fedora 22 Translation (L10n) Test Day --------------------------------------+------------------------ Reporter: anipeter | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Fedora 22 Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+------------------------ Translation (L10n) Test Day for Fedora 22 proposed for March 17, being a date before the translation deadline. Thanks Ani Peter (ani) -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/468> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 6

2015-06-01 @ 14:00 UTC - Fedora QA Devel Meeting
by Tim Flink 02 Jun '15

02 Jun '15

# Fedora QA Devel Meeting # Date: 2015-06-01 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net We'll be holding a QA devel meeting on Monday. It's been a while since we had a full planning meeting so this will be another one Tim Proposed agenda =============== Status Updates -------------- - Please have #info statements ready so we can get through this as quickly as possible Upcoming Items -------------- - Cloud Migrations - Phabricator Hosting Open Floor ---------- - TBD

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel June 2015