June 2014 - qa-devel - Fedora mailing-lists

[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

[Fedora QA] #443: Better format for test compose (TC) and release candidate (RC) requests
by fedora-badges 29 Jan '15

29 Jan '15

#443: Better format for test compose (TC) and release candidate (RC) requests ----------------------------------------+------------------------ Reporter: jreznik | Owner: Type: enhancement | Status: new Priority: major | Milestone: Fedora 21 Component: Blocker/NTH review process | Version: Keywords: | Blocked By: Blocking: | ----------------------------------------+------------------------ = problem = With Dennis (in CC), we discussed how to make release process, with Fedora.next in mind, more transparent and bullet proof. One issue is that releng request can become pretty messy, with full text included and sometimes it leads to errors (omission of packages in compose etc). = enhancement recommendation = One possibility is to visibly separate full text description (with bug numbers, reasons - it's good to have history) and the list of exact nvrs (maybe in code block?), try to avoid "qt bundle" etc. so it's easier to pick up the right list (for blockers, FEs + exceptional tools requests). Another thing is better coordination between requester/releng - to mark when/which list was picked up etc, in similar way how Go/No-Go decision is stated in the ticket. Now I'll let more space to Dennis, maybe example of how the request should look like to make it easy to parse would help. Long term (and preferred) solution would be to have automation in place, Blocker app talking to releng interface, compose database, web dashboard etc... -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/443> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 3

[Fedora QA] #437: Need to import daily Fedora snapshots into Beaker
by fedora-badges 29 Jan '15

29 Jan '15

#437: Need to import daily Fedora snapshots into Beaker --------------------------------------+--------------------- Reporter: atodorov | Owner: tflink Type: task | Status: new Priority: major | Milestone: Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+--------------------- = bug description = In order to perform any meaningfull testing Beaker needs to import more recent Fedora trees. It could be daily(nightly) snapshots or less often depending on available resources. The tree directory structure needs to be a copy/snapshot of the current state at the time of import. The reason is b/c devel trees utilize one URL but the contents under this URL are updated in a rolling fashion. We need tree URLs where content is not changing in order to produce consistent test results. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/437> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 1

[Fedora QA] #433: blocker proposal form forgets everything after login timeout
by fedora-badges 20 Jan '15

20 Jan '15

#433: blocker proposal form forgets everything after login timeout --------------------------------------+--------------------- Reporter: kvolny | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+--------------------- = bug description = I was trying to propose a F20 blocker. I needed to gather information from multiple bugs, so it took me longer to write the justification. After finishing and submitting that, I was presented with a login screen. After logging in again, I was redirected to the proposal form again, but it was completely empty, all the text that took me so long to write was gone. (Okay, I'm a smart guy and I had it in clipboard for such case, but if I had forgotten ... booh.) = bug analysis = Seems the login code doesn't care about other variables in the http request ... = fix recommendation = 1) If there is such a short login timeout, the user should be warned about it (e.g. countdown timer on the page) and the page should allow refresh without submitting the data. 2) Once the login expires, the submitted data should be caried over all the redirects back to the submission form. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/433> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 2

2014-06-30 @ 14:00 UTC Fedora QA Devel Meeting
by Tim Flink 30 Jun '14

30 Jun '14

# Fedora QA Devel Meeting # Date: 2014-06-30 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net https://apps.fedoraproject.org/calendar/meeting/394/ There is going to be a qa devel meeting on Monday for the beginning of iteration 5. I'm still working out the agenda details but wanted to get the meeting announcement out now before folks started going offline for the weekend. I'll reply to this thread with a proposed agenda later today. Tim

1 2

[Fedocal] Reminder meeting : Fedora QA Devel Meeting
by Kamil Páral 29 Jun '14

29 Jun '14

Dear all, You are kindly invited to the meeting: Fedora QA Devel Meeting on 2014-06-30 from 10:00:00 to 11:00:00 America/New_York At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Biweekly meeting to go over QA development related topics (Taskotron, BlockerBugs, and other tools). Specific agendas are sent out on [test][1] and [qa-devel][2] lists. **Join us at #fedora-meeting-1 on irc.freenode.net** (For help with IRC, please read [IRC help page][3]). Meeting logs can be read in the [meetbot archive][4]. [1]: https://lists.fedoraproject.org/mailman/listinfo/test-announce [2]: https://lists.fedoraproject.org/mailman/listinfo/qa-devel [3]: https://fedoraproject.org/wiki/How_to_use_IRC [4]: http://meetbot.fedoraproject.org/teams/fedora-qa-devel/ Source: https://apps.fedoraproject.org/calendar//meeting/394/

1 0

Taskotron Iteration 4 (ends 2014-06-27)
by Tim Flink 22 Jun '14

22 Jun '14

The Fedora 21 branch date is coming up fast - iteration 4 will be the last complete iteration before our planned production deployment date and we have plenty things to do before then. Iteration progress is being tracked in: https://phab.qadevel.cloud.fedoraproject.org/T219 I think we're a bit farther along than it looks by just watching the number of completed tickets - several of those are almost completed or waiting to be pushed before tickets are closed. Just to make sure we're all on the same page, I've made a list of the critical things which need to be done before we can deploy to production and turn off AutoQA. I want to do a test build on Wednesday (about 20:00 UTC) to get some testing time so that we can release on Friday. If one of your tasks isn't likely to be done by Wednesday, please let me know as soon as you can so we can deal with it before release time. If you think that something doesn't belong on this list or that I've missed something, let me know or reply to this thread. Tim depcheck - Josef is hard at work getting this to run in Taskotron * https://phab.qadevel.cloud.fedoraproject.org/T187 logging - Log appropriate information into taskotron.log * https://phab.qadevel.cloud.fedoraproject.org/T119 General Taskotron: - We're still using '$CHECKNAME' in our tap output. While this isn't read by any code that I know of, it looks bad and I want it to be fixed (at least temporarially) before we deploy to production * https://phab.qadevel.cloud.fedoraproject.org/T143 - make all output available alongside the main stdout from task execution * https://phab.qadevel.cloud.fedoraproject.org/T230 bodhi comments - As far as I know, this is mostly working but it's one of those things that will need close manual inspection to make sure there are no corner cases that we've forgotten about * part of https://phab.qadevel.cloud.fedoraproject.org/T222 Ceployment - Port ansible playbooks to infra's repo https://phab.qadevel.cloud.fedoraproject.org/T234 - Get new stg setup ready and running - Get production machines setup and running Things that I really want to have but we could technically go to production without: directive documentation - Progress is being made here, will hopefully have output later this week. * https://phab.qadevel.cloud.fedoraproject.org/T142

1 0

Taskotron 0.3 Released
by Tim Flink 16 Jun '14

16 Jun '14

The Fedora QA devel team is proud to announce the release of Taskotron 0.3! This is another incremental improvement and a continuation of our new-ish timed release process. The new release is running in our staging instance: https://taskotron-stg.fedoraproject.org/ The major changes have been: - Change in variable syntax (${variable} instead of {{ variable }}) - Support for more data types in variables - Reduced log message duplication - CLI output is more readable and predictable - New directives: * mash - use mash for local repodata creation * yumrepoinfo - get repo urls applicible to a given koji tag - Improved libtaskotron documentation - Clarified license situation to all GPL2+, updated file headers - Corrected links to logs in bodhi comments - Support for JSONP in resultsdb - Triggered jobs are logged at submission time - Support for triggering koji_tag based tasks with bodhi update change messages Thanks to everyone who participated in the release. We're getting close to a production deployment and retiring AutoQA! Tim

1 0

2014-06-16 @ 14:00 UTC Fedora QA Devel Meeting
by Tim Flink 16 Jun '14

16 Jun '14

# Fedora QA Devel Meeting # Date: 2014-06-16 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net https://apps.fedoraproject.org/calendar/meeting/394/ Apologies on the last minute announce but I think most folks knew this was coming so I doubt that I'm catching anyone by surprise :) This will be the last complete Taskotron iteration before Rawhide is branched to form the beginnings of Fedora 21. Our current target is to have Taskotron running in production for branch and there are still several things which need to get done before that time. Tim Proposed Agenda =============== Release Name Format Change? - stop bumping minor version @ every iteration - start calling it "Iteration 4" or something similar? Directive Documentation - Remaining issues before starting to write actual docs Production System - Still working with infra, hoping to have production up and running in time but things have gotten a bit more complicated than expected Taskotron 0.4 Planning * https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-0.4/

1 1

[Fedocal] Reminder meeting : Fedora QA Devel Meeting
by Kamil Paral 16 Jun '14

16 Jun '14

Dear all, You are kindly invited to the meeting: Fedora QA Devel Meeting on 2014-06-16 from 10:00:00 to 11:00:00 America/New_York At fedora-meeting-1(a)irc.freenode.net The meeting will be about: Biweekly meeting to go over QA development related topics (Taskotron, BlockerBugs, and other tools). Specific agendas are sent out on [test][1] and [qa-devel][2] lists. **Join us at #fedora-meeting-1 on irc.freenode.net** (For help with IRC, please read [IRC help page][3]). Meeting logs can be read in the [meetbot archive][4]. [1]: https://lists.fedoraproject.org/mailman/listinfo/test-announce [2]: https://lists.fedoraproject.org/mailman/listinfo/qa-devel [3]: https://fedoraproject.org/wiki/How_to_use_IRC [4]: http://meetbot.fedoraproject.org/teams/fedora-qa-devel/ Source: https://apps.fedoraproject.org/calendar//meeting/394/

1 0

libtaskotron: upgrade pytap13
by Lukas Brabec 12 Jun '14

12 Jun '14

New version of pytap13 is needed since commit [ea1e2f7]. Test introduced in this commit will fail (error DID NOT RAISE) if old pytap13 is kept. Please, upgrade your pytap13 to version 0.1.0, run: $ pip install pytap13 --upgrade or upgrade all requirements: $ pip install -r requirements.txt --upgrade LB [ea1e2f7] https://bitbucket.org/fedoraqa/libtaskotron/commits/ea1e2f78647101450ad1944…

2 1

Coding Style
by Tim Flink 04 Jun '14

04 Jun '14

Since we're likely to be doing some license header changes in the near future, I'm thinking that it might be a good time to start discussing code style for our projects. I'd like to be pretty much pep8 unless there are good reasons to deviate from that standard. PEP8 is well known and tools to check against it are widely available. Outside any header requirements or directive documentation requirements, are there any changes to PEP8 that folks want to make? If so, please list the exceptions and why you think they should be adopted. Tim

4 11

Depcheck conflicts should be ignored, but are not
by Ville Skyttä 04 Jun '14

04 Jun '14

Hello, This update: https://admin.fedoraproject.org/updates/tomcat-native-1.1.30-1.fc20 ...has some expected conflicts which are flagged by depcheck: http://autoqa.fedoraproject.org/results/813107-autotest/virt04.qa/depcheck/… Now, according to https://fedoraproject.org/wiki/AutoQA_tests/Depcheck#Conflicts, "Errors caused by packages conflicting each other should be ignored at the moment" but clearly they are not ignored, because based on this "failure", bodhi did this: "Automatic push to stable based on karma has been disabled for this update due to failure of an AutoQA test". What's the place to fix this, AutoQA or Bodhi, or the Wiki Depcheck doc?

2 1

Proposal: Use and Require CLA for QA Devel Project Contributions
by Tim Flink 02 Jun '14

02 Jun '14

As this has a decent possibility of being misunderstood, I want to be completely clear on what I'm proposing, what I'm _not_ proposing and why I'm proposing the use of a CLA. I'd want to run anything we decide past legal (enforce-ability, details of IP law and licensing in various jurisdictions etc.) before actually moving forward but that's after we discuss the idea of even using a CLA :) What I'm Proposing ------------------ - Start requiring a CLA for all contributions to qa devel projects, including libtaskotron, resultsdb, blockerbugs, core checks, etc. - The CLA would not change ownership of copyright but allow a bit broader license than just gpl2+ or gpl3 - The CLA would allow for re-licensing contributions under any of the licenses specified in the CLA (this list is up for discussion) * GPL2, LGPL2, LGPL2.1, AGPL2 * GPL3, LGPL3, AGPL3 * other (possibly future) fsf-recommended licenses (GPL4, etc.) * Maybe APL2? Not sure on that one since it's not copyleft and we'd have to rewrite bits to make that happen. What I'm NOT Proposing ---------------------- - Requiring contributors to give up ownership - Something sneaky. * Seriously, if it seems like I'm proposing something sneaky/evil, I want to get that clarified now. Why Propose Using a CLA? ------------------------ I have three reasons for wanting to start using a CLA for qa devel contributions: 1. With the gpl2+ vs gpl3 licensing question, I would like to enable license switches in the future that are in the best interests of the project, whether that means some gpl4 in the future or backing up to gpl2. I think of this as attempting to future-proof some potential licensing concerns. 2. I want to avoid confusion on how contributions are licensed, especially if we go forward with the "project is gpl3, most code is gpl2+" route. A properly worded CLA removes any confusion around how a contribution is or is not licensed. 3. Suggested best practices for open source projects [1]. I think it's highly unlikely that we'll ever need proof of IP provenance but it's infinitely easier to start gathering that proof now instead of later when email addresses may be dead, people difficult to reach etc. [1] http://jacobian.org/writing/contributor-license-agreements/ Any thoughts on whether this is a good idea or a bad idea? Any changes to the concept before I look for some specific verbiage and talk to legal about it? Tim

3 5

2014-06-02 @ 14:00 UTC Fedora QA Devel Meeting (note change in time and IRC channel)
by Tim Flink 02 Jun '14

02 Jun '14

# Fedora QA Devel Meeting # Date: 2014-05-19 # Time: 14:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting-1 on irc.freenode.net Note the change in time and IRC channel! https://apps.fedoraproject.org/calendar/meeting/394/ The next Taskotron iteration starts Monday and we need to figure out what all we're going to be working on. If you have any additional topics to propose, please let me know or respond to this email. Tim Proposed Agenda =============== Iterative Process * Thoughts so far? License Boogaloo * Summary of what has been found, proposal for how to wrap this up so it's done and we don't have to worry about it for a while Taskotron 0.3 Planning * https://phab.qadevel.cloud.fedoraproject.org/w/taskotron-0.3/

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel June 2014