Re: [Fedora QA] #334: Implement Blocker/FE Proposal Page
by fedora-badges
#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
11 years, 1 month
Re: Review Request 2: Initial Blocker Review Code
by Martin Krizek
-----------------------------------------------------------
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
11 years, 1 month
Problems with code reviews on reviewboard
by Tim Flink
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
11 years, 1 month
Re: [Fedora QA] #356: Blocker Proposal is Slow
by fedora-badges
#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
11 years, 1 month
Re: Review Request 8: Add Fedora 19 Milestones
by Martin Krizek
> 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-...) 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
>
>
11 years, 1 month
