qa-devel March 2013

qa-devel@lists.fedoraproject.org

5 participants
42 discussions

[Fedora QA] #362: Test day Request for 6/6/13
by fedora-badges 09 Mar '13

09 Mar '13

#362: Test day Request for 6/6/13 --------------------------------------+--------------------- Reporter: dpal | Owner: tflink Type: defect | Status: new Priority: major | Milestone: Component: Blocker bug tracker page | Version: Keywords: | Blocked By: Blocking: | --------------------------------------+--------------------- We would like to request a test day on 6/6/13 for the following feature: FreeIPA Two Factor Authentication https://fedoraproject.org/wiki/Features/FreeIPA_Two_Factor_Authentication -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/362> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 2

Re: [Fedora QA] #334: Implement Blocker/FE Proposal Page
by fedora-badges 05 Mar '13

05 Mar '13

#334: Implement Blocker/FE Proposal Page ---------------------------------------+----------------------- Reporter: tflink | Owner: tflink Type: enhancement | Status: closed Priority: major | Milestone: Fedora 19 Component: Blocker bug tracker page | Version: Resolution: fixed | Keywords: Blocked By: | Blocking: ---------------------------------------+----------------------- Changes (by tflink): * cc: qa-devel@… (added) * status: new => closed * resolution: => fixed Comment: Code reviewed and merged with develop: 506139dca38ae931e34be9f17cb2f4605d61293f -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/334#comment:1> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 0

Re: Review Request 2: Initial Blocker Review Code
by Martin Krizek 05 Mar '13

05 Mar '13

----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/2/ ----------------------------------------------------------- (Updated March 1, 2013, 6:10 a.m.) Review request for blockerbugs. Changes ------- I've updated the diff with the current changes to the blocker proposal code. There are still some minor issues (mostly with the delay when submitting a blocker and the lack of user integration with bugzilla) but it does work. The diff is slightly broken (see post to qa-devel@ as to why) but the major parts seem to be working. You can see the broken parts of the diff if you download the file or look @ git. Bugs: 334 https://fedorahosted.org/fedora-qa/ticket/334 Repository: blockerbugs Description ------- Initial code for blocker submission page Diffs (updated) ----- testing/test_bugchange.py PRE-CREATION sync_db.py 590d80adbf86bc9f7c27a4a8a0d46f5570c303f1 setup.py 32cf5b26caac1aced1dde2f0bf29d94bc2bebe83 initialize.py a6cd0a2766aaf88e8d87a4f72d6721075f6a219d init_f18db.sh c20df66c4b4a8f38ab79a1b61043d26de112f71c conf/blockerbugs.wsgi dcd819f4c4080546c84bd48f604ae6469d70d98a blockerbugs/util/bz_interface.py 2bae79db2d3a1206b7de1cee5f005f137ba2d6f3 blockerbugs/util/bug_sync.py 110fbe983a5cf177c35a9966162d0de23cf98d18 blockerbugs/templates/thanks.html PRE-CREATION blockerbugs/templates/propose_bug.html PRE-CREATION blockerbugs/templates/base_nav.html f3a89798a9dadf297e722c067ad3795a72ebbf74 blockerbugs/controllers/main.py 21bf27ce593a1398b1a08a6a4bcfc1d34146c027 blockerbugs/controllers/forms.py caae0e5b201fc6d85930246c31159ebbbe4f9ab7 blockerbugs/controllers/admin.py 01196b3d9b7284ebcab8bf1db061ad69f2d5f250 blockerbugs/config.py 75cf777d31e7fc3bfe3256704cd349e3ca88c866 blockerbugs/__init__.py cae54ab562f8a17a4473aa0bc58a73dacf5225f9 Diff: http://reviewboard-tflink.rhcloud.com/r/2/diff/ Testing (updated) ------- I've done quite a bit of local testing and there is a staging instance available: https://209.132.184.132/blockerbugs Thanks, Tim Flink

1 6

Problems with code reviews on reviewboard
by Tim Flink 05 Mar '13

05 Mar '13

Recently, we've been having some issues with code reviews on the reviewboard instance I set up. Petr was not able to create a review for a fedora-build-service patch and a review I set up is showing diff errors. I started digging into this yesterday, and it turns out to be a problem with the fedorahosted cgit instance that reviewboard uses to get files to generate the diffs - it's not returning the right file contents. In some cases, it returns blank files. In other cases, it returns 404 errors (what petr was hitting) or HEAD from MASTER instead of the file requested (what I was hitting). After talking with nirik in #fedora-admin, it looks like this might be an issue with the fedorahosted.org setup of cgit because while I can reproduce the issue on freedesktop.org's cgit instance (which is probably using the same redirects), I can't reproduce the problem on the upstream cgit instance [1]. [1] http://git.zx2c4.com/cgit/ I've filed an issue with infra [2] and will update this thread when we know more. However, until this is resolved - code reviews on reviewboard aren't likely to work 100%. [2] https://fedorahosted.org/fedora-infrastructure/ticket/3687 Tim

1 1

Re: [Fedora QA] #318: track blockers closed as duplicates to non-blockers
by fedora-badges 05 Mar '13

05 Mar '13

#318: track blockers closed as duplicates to non-blockers ---------------------------------------+--------------------------------- Reporter: kparal | Owner: tflink Type: enhancement | Status: new Priority: major | Milestone: Undetermined Future Component: Blocker bug tracker page | Version: Resolution: | Keywords: Blocked By: | Blocking: ---------------------------------------+--------------------------------- Changes (by tflink): * milestone: => Undetermined Future * cc: qa-devel@… (added) -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/318#comment:1> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 0

Re: [Fedora QA] #323: Add API support to the blocker tracking app
by fedora-badges 05 Mar '13

05 Mar '13

#323: Add API support to the blocker tracking app ---------------------------------------+--------------------------------- Reporter: tflink | Owner: tflink Type: enhancement | Status: new Priority: minor | Milestone: Undetermined Future Component: Blocker bug tracker page | Version: Resolution: | Keywords: Blocked By: | Blocking: ---------------------------------------+--------------------------------- Changes (by tflink): * cc: qa-devel@… (added) * milestone: => Undetermined Future -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/323#comment:1> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 0

Re: [Fedora QA] #356: Blocker Proposal is Slow
by fedora-badges 05 Mar '13

05 Mar '13

#356: Blocker Proposal is Slow ---------------------------------------+--------------------------------- Reporter: tflink | Owner: tflink Type: enhancement | Status: new Priority: major | Milestone: Undetermined Future Component: Blocker bug tracker page | Version: Resolution: | Keywords: Blocked By: | Blocking: ---------------------------------------+--------------------------------- Changes (by tflink): * milestone: Fedora 19 => Undetermined Future * cc: qa-devel@… (added) Comment: I did some digging into this and I don't think it's practical to plan on this for Fedora 19. It would be great but the blocker tracking app wouldn't be the only Fedora-related app that has some slow postings and I think our resources could be better spent elsewhere for now. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/356#comment:1> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 0

Re: [fedora-build-service] #10: image_builder doesn't clean up after itself
by fedora-badges 01 Mar '13

01 Mar '13

#10: image_builder doesn't clean up after itself -----------------------------+-------------------------------- Reporter: tflink | Owner: pschindl Type: defect | Status: accepted Priority: major | Milestone: Initial Deployment Component: Image Building | Version: Resolution: | Keywords: -----------------------------+-------------------------------- Changes (by pschindl): * status: new => accepted * owner: somebody => pschindl -- Ticket URL: <https://fedorahosted.org/fedora-build-service/ticket/10#comment:1> fedora-build-service <https://fedorahosted.org/fedora-build-service> A service to build fedora images with a somewhat arbitrary package set from the standard fedora repos or builds from koji.

1 0

Re: Review Request 8: Add Fedora 19 Milestones
by Martin Krizek 01 Mar '13

01 Mar '13

1 0

Re: Review Request 8: Add Fedora 19 Milestones
by Martin Krizek 01 Mar '13

01 Mar '13

> On Feb. 26, 2013, 7:15 p.m., Tim Flink wrote: > > Code looks good to me for the most part. I realize that we've talked about g versus session for storing this data before but I'm hitting some minor issues regarding the ability of the menu bars to update. > > > > When I start adding/removing milestones, the only way that the menu bar is updated is if I start a new browser session - this means quitting the browser and re-starting _without_ restoring the previous session. There might be a better way to force a refresh but either way, I'm not so sure about putting the refresh burden on users instead of handling it in the app. > > > > Unfortunately, I can't think of many good ways to make this work well that don't involve an extra database query per request. One way would be to have a statically defined expiration in the session (like 1 day after initial load) and force refresh after that expiration. However, that has its own pitfalls and adds complexity - I'm not convinced this is a good idea. > > > > I'm wondering if it wouldn't be better to go back to what you had initially and use g. It would involve extra database queries but if that becomes a problem, caching would work well to reduce server load - most of the content is relatively static (in the timeframe of sync operations, 30 minutes right now) and caching could be a good way to work around this. > > Martin Krizek wrote: > In general, I agree. However, and please correct me if I am wrong, our use case is to put milestones into db before the testing starts (before the app is actually used by anyone). Then there is a testing period and then there is a testing break during which the session expires. And after the break we put the new milestones into db again. In this scenario I don't see the problem with refreshing the milestones. Or do we add/delete/change milestones during the testing period? Or are we planning to do that? If so, we should use the g object, otherwise, I think we're better off with session. True, the risk of having problems during the testing of a release are relatively small but I'd still rather not have to tell people to quit their browser or delete a cookie when new milestones aren't showing up in their browser. One possible solution would be to hack at permanent sessions so that the lifetime is something like 1 day (http://stackoverflow.com/questions/11783025/is-there-an-easy-way-to-make-se…) but honestly, I'm thinking that the use of g would be a better solution right now - postgres is supposed to be good at caching query results and this one shouldn't change all that often - if we end up with performance problems, we can always revisit. The change from g to session isn't much code. - Tim ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/8/#review10 ----------------------------------------------------------- On Feb. 26, 2013, 9:28 a.m., Martin Krizek wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard-tflink.rhcloud.com/r/8/ > ----------------------------------------------------------- > > (Updated Feb. 26, 2013, 9:28 a.m.) > > > Review request for blockerbugs. > > > Bugs: 332 > https://fedorahosted.org/fedora-qa/ticket/332 > > > Repository: blockerbugs > > > Description > ------- > > Make navigation bar content loaded dynamically > > > Diffs > ----- > > blockerbugs/templates/index.html 17b98b686664754de74158afb4c793e245660690 > blockerbugs/templates/base_nav.html f3a89798a9dadf297e722c067ad3795a72ebbf74 > blockerbugs/controllers/main.py e7525f8433d74802f7c0cb2d719f0abdc13431c4 > > Diff: http://reviewboard-tflink.rhcloud.com/r/8/diff/ > > > Testing > ------- > > > Thanks, > > Martin Krizek > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

qa-devel March 2013