Review Request 8: Add Fedora 19 Milestones

[Martin Krizek]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/8/
-----------------------------------------------------------

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

[Martin Krizek]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard-tflink.rhcloud.com/r/8/#review10
-----------------------------------------------------------


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.

- Tim Flink


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
>  
>

[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. 
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.


- Martin


-----------------------------------------------------------
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
>  
>