search

asah / footprint2009dev

original dev repo for AllForGood.org
http://AllForGood.org/
0 stars 1 forks source link

Better place to serve static files from than SVN trunk #328

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
As I understand it we currently read content for the static files (eg the about 
page) from the SVN 
trunk at http://footprint2009dev.googlecode.com/svn/trunk/frontend/html/. 
Grabbing something 
from the SVN trunk is going to cause problems when we move to a longer release 
cycle -- we need 
to move this to link to something more appropriate.

As I see it we have two options:
1) Update the STATIC_CONTENT_LOCATION when we branch, adding a step to the 
release process
2) Create a tag for the current release and link to that, which requires us to 
maintain a current 
release tag (not a bad idea IMHO)

I tend to prefer the second but am open to the first and any other ideas. Any 
comments?

Original issue reported on code.google.com by jblockso...@gmail.com on 5 Jun 2009 at 2:10

GoogleCodeExporter commented 9 years ago 
this doesn't strike me as high priority-- if we do nothing, then static file 
updates
just get submitted to both branches (dev & release).  Not a big deal, since 
static
file maintainers already know svn.  Am I missing something?
(changing priority so we don't forget to... feel free to change back...)

Original comment by adam.sah on 5 Jun 2009 at 2:38

GoogleCodeExporter commented 9 years ago 
The main problem I see is that we can't check static files into the trunk 
without them showing up on the site. Any 
static text change becomes live the moment we check it in, instead of going 
through a release process -- not a 
big deal with where we are now, but eventually it'll cause a problem. None of 
the text could refer to an 
unreleased feature or link, for example.

Original comment by jblockso...@gmail.com on 5 Jun 2009 at 2:53

GoogleCodeExporter commented 9 years ago

Original comment by jblockso...@gmail.com on 5 Jun 2009 at 2:54

GoogleCodeExporter commented 9 years ago 
ah I get it... but why not just move this to serving from the release branch?

(true, it means updating the origin-URL with every release... but I think we
can get appengine to provide the current-version-name which we intentionally
sync to the SVN branch name, i.e. can generate the correct URL)

anyway, I now agree with you that this is worth addressing.

Original comment by adam.sah on 5 Jun 2009 at 4:01

GoogleCodeExporter commented 9 years ago 
Making critical to insure I get this done before we release

Original comment by jblockso...@gmail.com on 11 Jun 2009 at 8:14

GoogleCodeExporter commented 9 years ago 
hmmm... not to derail you, but are you sure there's nothing more urgent to work 
on?
We've got a slew of live problems with various data feeds that actually impact 
users.
e.g. issues 3, 203, 206, 221, 323  (all look pretty straightforward)

Original comment by adam.sah on 11 Jun 2009 at 9:36

GoogleCodeExporter commented 9 years ago 
I agree not critical.  Note that it is possible to check in a new static HTML 
file 
that is not visibly exposed: by only adding the file to urls.py but not to 
templates/static_content.html or to the footer, there won't be any clickable 
links to 
the new page.

Definitely worth addressing eventually, but for now Karen and Ginny are working 
well 
by only checking in html changes (to visible files) right at the time they need 
the 
changes to be live.  Marking down to Medium, since this is a process 
improvement 
that's not yet a problem.

Original comment by paul.rademacher on 15 Jun 2009 at 5:34

GoogleCodeExporter commented 9 years ago

Original comment by adam.sah on 15 Jun 2009 at 8:26

GoogleCodeExporter commented 9 years ago

Original comment by adam.sah on 15 Jun 2009 at 8:27

GoogleCodeExporter commented 9 years ago 
I'm okay pushing this to 2.X given the circumstances.

Original comment by jblockso...@gmail.com on 16 Jun 2009 at 6:15

GoogleCodeExporter commented 9 years ago 
Just an example of why I think we should change this - I just committed the new 
apps
page, which involves new images and modifications to main.css. I pushed the new
version to footprint2009dev (http://footprint2009dev.appspot.com/apps) and it 
works
properly.  I didn't do anything to the qa site though, and when you go to that 
page
(http://footprint2009qa.appspot.com/apps), the text changes from the new html 
file I
committed are there (since they're pulled right from svn), while the images and 
CSS
don't work.

Not a huge issue here since the apps page isn't linked on the current 
production site
yet, but if it were, it'd be screwed up there too.

Original comment by ehysen on 17 Jun 2009 at 7:48

GoogleCodeExporter commented 9 years ago 
adding mark to featreqs

Original comment by adam.sah on 23 Jun 2009 at 7:10

GoogleCodeExporter commented 9 years ago

Original comment by adam.sah on 28 Jun 2009 at 4:25