qa-devel June 2014

qa-devel@lists.fedoraproject.org

7 participants
15 discussions

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