Started work on ideas for simplifying testing and demonstration deployments

[Nick Coghlan]

On 19 December 2014 at 01:30, Mads Kiilerich <mads at kiilerich.com> wrote:

> On 12/17/2014 10:12 PM, Nick Coghlan wrote:
>
>> Hi folks,
>>
>> I just wanted to let you know that I've started working on some ideas
>> to use tools like Vagrant, Docker and OpenShift to make it easier to
>> run and deploy testing and demonstration instances of Kallithea.
>>
>
> That sounds great!
>
> The stack can be complex and with lots of options - especially complex
> when using rabbitmq.
>
> Do you plan on support different custom configuration and free choice of
> sqlite and postgresql ... and perhaps different choice of web server stack?
> I guess it depends on whether your scope is to demonstrate the application,
> to make a nice container for your setup, or provide a generic way to
> support several fine setups.
>

My near term goal is to get something up and running that would be suitable
for the forge.python.org scenario (so PostgreSQL as the back end), but
yeah, one of the best parts of this kind of automation is that you can
tweak it fairly easily to support different configurations.


>  The
>> difficulty of sharing proposed UI changes is one of the issues we run
>> into when folks are working bugs.python.org, so it's one I'd like to
>> tackle up front for my forge.python.org proposal.
>>
>
> Can you say more about that? You want to attach/include screen-shots in
> the PRs and/or comments?
>

No, I'd like folks to be able to easily run demo servers (for free) that
let them show other people a build with their changes applied. The initial
OpenShift quickstart installs Kallithea from PyPI, but I'd like to change
it to be easily configurable.

So the idea is that if you were making a change that actually updated the
UI, you could run up a live demo instance for people to look at, rather
than having to mess about with screen shots, etc.


> I'm currently playing around with patches that just recognize URLs to
> images and show them inline. (We have also disabled rst and do just use
> plain text so people get ASCII WYSIWYG and can focus on their message and
> be able to paste all kind of code snippets without interference from the
> templating language.)
>

Markdown is definitely worth a look for code review commenting. Mostly
stays out of the way, and is one lots of folks are familiar with courtesy
of GitHub, Gerrit, etc.

I agree ReST isn't a particularly good fit, though - it's better for larger
documentation projects where the semantic cross-references start to be
beneficial.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20141219/a95aaa65/attachment.html>