nodejs.org #350
Comments
|
I'll have to take some time to checkout the nodejs.org build, but from my current knowledge I believe ours is more extensible. As such, something similar to those steps sounds good. |
|
Also, I don't know what the best plan of attack is for this in terms of using a new branch or a new repo or whatever, I'll leave that up to the website WG and build to figure out. |
|
Oh, and if there is anything you need from the foundation side let me know ASAP so that I can make sure it happens. We have a bank account we can use to actually buy things now ;) |
|
It's mostly just people's time we are dealing with right now. :) cc @iojs/website though. |
|
pulling in @robertkowalski as well. |
|
If someone lays out a proper plan for repo vs. branch I can do the initial checkin of all the static assets and get the ball rolling. |
|
My thoughts:
I prefer a separate repo so we don't have massive commit histories of deprecated content to deal with. We learned a lot in the building of iojs/website, and I think we can do better moving forward with a fresh slate. Just my 2 cents, but that's what seems logical to me moving forward to keep things organized and clean. |
|
@therebelrobot +1 sounds like a good plan. There will be quite some changes to the content and structure of the website, as well as how it will be built. This also will have a major influence on all translated content (which can become a hindrance when building the initial version of the new site). So starting with a clean slate sounds good, afterwards we can migrate/update all the translated content. This also gives us the opportunity to go through all existing issues/ideas/feature requests to see if they are still relevant for the new website (and maybe we can address some of them directly as we build it). I also like the staging idea very much. We could add some basic e2e tests there to make sure nothing breaks on the live website (e.g. do the language redirects work, do the download links match files on dist.nodejs.org, does the current version of the docs reflect the current release version, is the css properly generated – you name it). |
|
Please add @robertkowalski and myself to the working group as we have been responsible for the node website lately. A new repo makes sense. I am in support of using ansible for doing the deploys, as this is what the build group uses. Although, it may be overkill for the site. @mikeal should we reach out to an agency for a fresh look or do we want to keep the existing design of either of the node/io sites? |
|
I should have mentioned this earlier but I should be more explicit: the iojs.org website must stay up and work as it does now for io.js releases. We don't know how long the convergence will take and we can't not release stuff. |
|
@therebelrobot I like your plan for the most part but I'm a little concerned that 3 is going to take too long and 2 won't be sufficient in the interim. We could have a converged release read in a couple weeks if things go well and so I'd like to get minimal tooling in to the current nodejs.org site that can integrate with our release tooling so that we can make minor tweaks to the current site and continue releasing while we build a much improved site :) |
|
@robertkowalski @geek I've added you to the website team in GitHub, got ahead and send a PR to the readme to get yourselves on the list there :) |
I'll make sure that the foundation knows we want to have some professional help on the design side and to factor it in to the budget. |
|
+1 on that Trent On Thu, May 14, 2015 at 8:08 PM, Trent Oswald [email protected]
|
|
Who from the working group needs access to push to the nodejs.org site? Does everyone have push access or only a couple of people? |
|
@geek you mean the existing site or the site once it moves over to the foundation org? We're going to need to move over the hosting to something we're running as well, and the domain name ownership is passing to the foundation who can point it at the new hosting once we have it setup here. |
|
Ya, I was thinking about the existing nodejs.org site. Wondered if we should add keys for members of the io working group to be able to ssh to it. |
|
In terms of timeline, we'll need to have the hosting moved over before the first converged release and the foundation will have control of the domain name prior to that as well, so I think we're probably fine without any additional access to the current site. |
|
+1 on the separate repos, naming can be discussed. (It might be better to mirror the primary hostnames a bit.) The individual i18n groups have varying degrees of mirroring and branch integrations as well which we will need to consider -- mostly so they have some sense of our plan to help them move forward in whatever way they chose. Since the (code) merge project timelines are hard to predict (and there is some desire to possibly have "io.js" mean/be something moving forward) it makes sense to maintain individual PRs, history, deploy processes, etc. The current (io.js site) was a good experiment in terms of tooling and i18n processes and we can do a lot going in to the merged site to leverage what worked. We've put off a WG meeting for quite some time now given most of us have been short on time, but we should probably set one up soon for the merged team to meet-and-greet and to work through these questions. (I can set up a thread for this.) |
|
I've setup a placeholder meeting at #352 -- the proposed time may be too short of notice, but it gives us a place to start. I also forgot on the last post to mention we are also using ansible on the current iojs.org website to automatically build and publish changes once they land in the website repo. Because some publishing hooks tie in nicely with those used by the build team (ie. automatic triggers for content updates upon a new version release), I'd suggest we assume a similar approach moving forward -- but we can discuss that more in the meeting. |
|
+1 new repo, building off of the build system that exists here. The hosting itself uses ansible a bit, but I forget for what. Maybe @kenperkins would know? |
|
fwiw - one thing @iojs/build would like to achieve is a properly HA hosting solution that doesn't rely on the particular servers serving the content, particularly for download files, we'd like to put stuff into S3 or similar and just use the servers as a way to orchestrate and/or proxy content but at the moment we're relying on a particular machine containing the content we need and this is suboptimal. I've just learnt that nodejs.org is in exactly the same position so a converged project should try and achieve a more ideal state given that we're given the chance to do something new. @kenperkins has done more thinking about the architectural details than I at this stage. |
|
There's really two major components: the website itself (static assets, markup, css, etc) and the build artifacts. I would hope that the website continues to be built and deployed via our CI/CD process with ansible provisioning/configuring the machines. The build artifacts should be stored in cloud storage, and then served out via cdn. |
|
Closing this, we're already working on this over at nodejs/new.nodejs.org. |
So, the vote to merge went through and soon this Working Group will end up being responsible for nodejs.org as well as iojs.org.
I'd like to outline a solid plan for taking on that website and make sure that we bring over the node.js contributors who have been working on the website in to this WG to make a smooth transition.
These seem like the most sensible steps.
The text was updated successfully, but these errors were encountered: