Re: [srobo] Future of the Brand and Website

[Peter Law]

Hi,

This thread migrated from srobo@ for more in-depth technical
discussion. Please follow for those aspects.

General context: Jimmy has developed a new website in jekyll [0]. This
thread aims to continue a number of the more technical aspects
separately from general discussion on the general mailing list.

Context:
>>> the new website intentionally doesn't contain a number of
>>> things currently in srweb, such as the docs & team-status pages

I wrote:
>> I'd fairly strongly argue that the docs and teams information are part
>> of what get people interested in SR. A big part of what we do is that
>> we provide a kit to the teams, and that that kit is documented in
>> detail. While the docs themselves mostly aren't useful without the
>> kit, there are some aspects which are.
>>
>> Similarly, part of the reason that we have the teams on our website is
>> that it shows who is involved as well as creating cross-linking
>> opportunities from their own blogs & websites, which in turn draw
>> attention to us. It's certainly less under our control, but it's a
>> much larger surface area than our own website has.
>>
>> If the intent is that this new website won't include the docs/etc.,
>> where will each of those be kept and served from? How will we ensure
>> that they use a consistent template/look-and-feel to the main website?

Jimmy wrote:
> As far as where they live and where they're hosted, as far as I'm aware
> it's still in srweb until someone says otherwise. The migration plan, as
> it stands, is to have some sort of reverse proxy (e.g. nginx) funnelling
> requests between where the new PR site is hosted (likely some static
> file host like S3) and the existing srweb.

This sounds incredibly complex for various contributors to setup if
they need to work on things. I would note that one of the original
intentions of the previous srweb-jekyl attempt was in *simplifying*
the setup in order to get more people involved. Moving in the opposite
direction seems a bad idea to me.

>> Separately, what's the plan for the competition pages? While part of
>> these is the /comp/* pages, the special homepage is also a big part of
>> it. These are very much more code than content (the content is
>> dynamic), so preserving their history is *very* important. Note that
>> these pages also rely on the SRComp HTTP API to function, so need to
>> be able to query that somehow.
>
> Not sure how this will work at the moment. Assuming it ends up going
> into this website (and not a separate competition app), I /guess/ XHR
> requests to the SRComp API to work since they should both be on the same
> domain, unless I'm mistaken.

Well yes, but it's the assumption you've made which I was asking about
-- at the moment the public-facing pages are a single unit and part of
srweb. Is the plan post-move that they be a separate entity (if so,
how do we get the homepage override to happen?) and when/by whom will
that be decided?

I'd be happy to have them as a separate unit (akin to how the
"screens" pages are, and possibly even part of that repo) as long as
there was a viable scenario for deployment and getting the styling to
match.

Jimmy originally wrote:
>>> we're *not* looking to integrate it back into srweb, or host it on Saffron.

I wrote:
>> Huh. There is a *lot* of valuable stuff in srweb which it would be a
>> shame to lose. The version history is fairly important, though I
>> suppose less valuable if everything's going to be rewritten; that
>> seems like a lot of effort however.
>>
>> The most obvious thing which I think needs to be kept (along with its
>> version history) are the news articles. These appear to already have a
>> place in the new website, so it would seem silly not to move them
>> over.

Jimmy wrote:
> I don't intend for the srweb repository to disappear, as a source of
> history it's invaluable.

Having considerable personal experience with cases where "the history
is kept, but in a separate repository/part of the (svn) repo", that is
frankly not a viable approach. While it saves a small amount of effort
during the conversion phase it results in a lot of extra effort being
needed whenever that history is actually needed (which almost always
turns out to be "much more than we would have thought").

> I agree that news articles should be moved over.

I see that this has been done, apparently without any attempt to keep
the history!

Jimmy originally wrote:
>>> we're *not* looking to ... host it on Saffron. This is part of a larger plan to
>>> break apart the various applications on Saffron and move them elsewhere.

I wrote:
>> Huh. Please could you expand on this? It sounds like you're suggesting
>> that we both:
>> - abandon the working server config we have
>> - separate out the many services SR has onto different hosts
>>
>> One of the really useful features that we currently have is that it's
>> fairly easy to get a working copy of all of our hosting scenarios.
>> This includes saffron, though there are a number of independent VMs
>> (mostly competition things) which are configured in a similar way.
>>
>> An important effect of this centralisation is that it's easy to build
>> a component which relies on other things elsewhere on the server,
>> since you can spin up the whole thing in one go and check it works.
>> If we wind up hosting things which need to interact with each other
>> from different places that seems like something which will become very
>> hard to check outside of the production environment.

Jimmy wrote:
> That may not be exactly how it ends up, but that's the intention, yes.

I'm not sure I follow. Are you saying that it's intentional that we
break up the current working, single-setup server config in favour of
lots of smaller moving pieces which each developer needs to put
together manually?

Note that at the moment there is nothing forcing anyone to build an
entire saffron clone just to work on the website, IDE, etc. though
many apparently choose to do so. Almost the components I develop can
be worked on in isolation already, and I do do so, and then brought
together for integration testing at the end.

My point was that such a separation would be a significant step
backwards from where we are now. I've no idea what potential benefits
could come from such an approach to justify it. Can you suggest any?

> I'm sure it will be more pragmatic than it sounds, but for this website
> work, which is entirely static content, I think it makes sense.

I'm not sure I follow why the PR portions of the website being static
content means that they should be broken into a separate repo. The
presence of a build system on that "static" content also rather
nullifies the idea that their being "static" is something that
differentiates it.

Thanks,
Peter

[0] http://thread.gmane.org/gmane.science.robotics.srobo.general/6682