qa-devel January 2014

qa-devel@lists.fedoraproject.org

12 participants
82 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

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

30 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

Review Request 37: Fix sequences in alembic
by Martin Krizek 21 Feb '14

21 Feb '14

1 4

Review Request 64: Do not display obsolete and deleted updates
by Martin Krizek 21 Feb '14

21 Feb '14

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/64/ ----------------------------------------------------------- Review request for blockerbugs. Repository: blockerbugs Description ------- This will not display updates that are obsolete or irrelevant. After fetching updates from bodhi, the clean_updates method will set status of updates that are in database and not in the fetched updates (are not relevant anymore) to 'deleted'. There seems to be no way to know whether an update in db is still present in bodhi or not. So we mark every update in db as 'deleted' that is not currently an update that fixes a blocker bug. The question is whether we want to mark these updates as 'deleted' and create status that does not exist in bodhi or mark them in other way. If a situation where a 'deleted' update is used again as a fix of a blocker bug occurs, its status is set back to 'testing' or 'stable' on the next update sync. Any suggestions about improving or changing the approach? Diffs ----- testing/testfunc_update_sync.py 48dfb500469b8f237020b5d0845ae60a4e1fb776 blockerbugs/util/update_sync.py 47dbc9fa17ed3b751417b4ab822c257fa5423f4b blockerbugs/controllers/main.py 5455e1aa2bbf6edc551223ee6fccb9c6236f0eb8 blockerbugs/__init__.py 3525501c382f21339dab0e18e973141ad29073e3 Diff: http://reviewboard-tflink.rhcloud.com/r/64/diff/ Testing ------- Unit test attached in the patch. Some testing done on my dev machine as well. Thanks, Martin Krizek

1 4

Review Request 62: Fix needinfo field length
by Martin Krizek 21 Feb '14

21 Feb '14

1 1

Review Request 61: Rename line.png to line-bottom.png
by Martin Krizek 21 Feb '14

21 Feb '14

1 1

Review Request 60: Insufficient logging for bug proposal form issues
by Martin Krizek 21 Feb '14

21 Feb '14

1 1

gitflow and branch naming conventions
by Kamil Paral 10 Feb '14

10 Feb '14

So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket repositories today, only the libtaskotron branch uses 'develop' branch, all other projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm a bit afraid it's going to be chaos - you'll need to inspect available branches every time to decide against which branch to base a patch or into which branch to commit. I wonder, could we use gitflow but drop the idea of misusing 'master' branch name for something else than usual? Because that's the main grievance I have against gitflow, otherwise it's a neat workflow. I believe gitflow should have never used master for something else, it should have used 'stable' branch instead for stable releases (i.e. 'gitflow/master' should have been 'traditional/stable' and 'gitflow/develop' should have been 'traditional/master'). All the tools (and most of the users) expect 'master' to be the main development branch. Git init creates master by default. Git clone checks out master by default. Github/Bitbucket displays master by default. Arcanist merges to master by default. Users clone and send patches against master by default. Usually you can adjust the tools, but what's the benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it under one of the most famous blogposts [3] and offering the same suggestions as I do). So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits. If you have installed the gitflow RPM package (it adds the "git flow" subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning. [1] https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

4 9

Documentation Tools
by Mike Ruckman 31 Jan '14

31 Jan '14

I've posted a comparison between Sphinx and Dexy [1] - as well as updated the phabricator ticket [2]. The tools are pretty similar in what they can produce, so it really comes down to what people are comfortable with. The learning curve for Dexy isn't steep, and I think it's just enough easier to use compared to Sphinx for our purposes. I wasn't able to find air-tight reasoning for one over the other for qa-devel work - but found dexy a bit easier to use and template. Source for both tutorials can be found on my bitbucket profile [3]. // Roshi [1] http://roshi.fedorapeople.org/comparing-dexy-and-sphinx.html [2] https://phab.qadevel.cloud.fedoraproject.org/T39 [3] https://bitbucket.org/Rorosha/doc-tools

4 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel January 2014