Open GoogleCodeExporter opened 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
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
Original comment by jblockso...@gmail.com
on 5 Jun 2009 at 2:54
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
Making critical to insure I get this done before we release
Original comment by jblockso...@gmail.com
on 11 Jun 2009 at 8:14
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
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
Original comment by adam.sah
on 15 Jun 2009 at 8:26
Original comment by adam.sah
on 15 Jun 2009 at 8:27
I'm okay pushing this to 2.X given the circumstances.
Original comment by jblockso...@gmail.com
on 16 Jun 2009 at 6:15
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
adding mark to featreqs
Original comment by adam.sah
on 23 Jun 2009 at 7:10
Original comment by adam.sah
on 28 Jun 2009 at 4:25
Original issue reported on code.google.com by
jblockso...@gmail.com
on 5 Jun 2009 at 2:10