Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [webdev] Generation of all.html
7 views
Skip to first unread message
Paul McLanahan
Nov 6, 2012, 8:20:12 PM11/6/12
to mozilla.org development, dev-w...@lists.mozilla.org
[added dev-mozilla-org list]
I was just talking with sgarrity in #www about this today. There apparently
is a bug to move this page to bedrock along with a new design. I don't have
the bug number, but work has started I believe. I'll find the bug tomorrow
and set 527907 to depend on it. I don't think that putting the work into
the php page would be the best use of your time since it is being ported
now. But if those builds don't make it into the initial release of the
bedrock page then adding it there definitely would be. I'm pretty sure
however, that since we're catching this very early in the page porting
process we can get both of these bugs done simultaneously.
Thanks!
Paul McLanahan
Mozilla Webdev
--pmac
I was just talking with sgarrity in #www about this today. There apparently
is a bug to move this page to bedrock along with a new design. I don't have
the bug number, but work has started I believe. I'll find the bug tomorrow
and set 527907 to depend on it. I don't think that putting the work into
the php page would be the best use of your time since it is being ported
now. But if those builds don't make it into the initial release of the
bedrock page then adding it there definitely would be. I'm pretty sure
however, that since we're catching this very early in the page porting
process we can get both of these bugs done simultaneously.
Thanks!
Paul McLanahan
Mozilla Webdev
--pmac
Benjamin Sternthal
Nov 6, 2012, 8:29:44 PM11/6/12
to Paul McLanahan, dev-w...@lists.mozilla.org, mozilla.org development
One thought about this… I am not sure if this specific page qualifies but…
If we have content that is tightly coupled to the product but does not have anything do with the marketing site I would suggest having these live separately.
For example something like firefox.mozilla.org.
Right now in legacy SVN we have a mix of marketing content and items our products like firefox require. I would like to avoid repeating this in bedrock.
---------------------------
Benjamin Sternthal
bster...@mozilla.com
Web Product Engineer
Mozilla
skype: booboobenny
(m) 503.702.0963
> _______________________________________________
> dev-webdev mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev
If we have content that is tightly coupled to the product but does not have anything do with the marketing site I would suggest having these live separately.
For example something like firefox.mozilla.org.
Right now in legacy SVN we have a mix of marketing content and items our products like firefox require. I would like to avoid repeating this in bedrock.
---------------------------
Benjamin Sternthal
bster...@mozilla.com
Web Product Engineer
Mozilla
skype: booboobenny
(m) 503.702.0963
> dev-webdev mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev
Paul McLanahan
Nov 7, 2012, 9:04:57 AM11/7/12
to Benjamin Sternthal, dev-w...@lists.mozilla.org, mozilla.org development
I see no problem with marketing and product content living in bedrock
together. The PHP site was much more loosely organized, so I can see why
there'd be pain. But with bedrock and Django we can keep things fairly
nicely separated within their own apps, or even split them into separate
repos and pull them in with git submodules. With all this I don't think
it's as useful or important to keep things like this on separate servers or
domains. If we just want these things more visually separated then that's
another thing, but technically I think we're fine.
Paul McLanahan
--pmac
together. The PHP site was much more loosely organized, so I can see why
there'd be pain. But with bedrock and Django we can keep things fairly
nicely separated within their own apps, or even split them into separate
repos and pull them in with git submodules. With all this I don't think
it's as useful or important to keep things like this on separate servers or
domains. If we just want these things more visually separated then that's
another thing, but technically I think we're fine.
Paul McLanahan
--pmac
Anthony Ricaud
Nov 7, 2012, 11:08:05 AM11/7/12
to
The frontier between marketing and product is often loose too. We have
in-product pages that contain marketing content (whatsnew, firstrun come
to mind).
Also, given our growing suite of tests, we have more confidence that
we're not breaking in-product pages. If we want to reduce the risk of
product related changes breaking the marketing site or the opposite, I
think we should automate most of the product related changes (like
release notes, redirections depending on the current Firefox release, etc).
So like pmac, I believe we're fine with the current setup.
in-product pages that contain marketing content (whatsnew, firstrun come
to mind).
Also, given our growing suite of tests, we have more confidence that
we're not breaking in-product pages. If we want to reduce the risk of
product related changes breaking the marketing site or the opposite, I
think we should automate most of the product related changes (like
release notes, redirections depending on the current Firefox release, etc).
So like pmac, I believe we're fine with the current setup.
Paul McLanahan
Nov 7, 2012, 7:59:08 PM11/7/12
to trasunto...@hotmail.com, dev-w...@lists.mozilla.org, mozilla.org development
On Wed, Nov 7, 2012 at 7:27 PM, <trasunto...@hotmail.com> wrote:
>
>
> I'll join the efforts to fix bug #808762 and collaborate in getting the 64bit builds into the page, sooner better than later, so all effort is focused on the bedrock pages.
Fantastic. Thanks for the help!
>
>
> I'll join the efforts to fix bug #808762 and collaborate in getting the 64bit builds into the page, sooner better than later, so all effort is focused on the bedrock pages.
Fantastic. Thanks for the help!
0 new messages