On Fri, 13 Jan 2017 13:58:25 +0100
Josef Skladanka wrote:
> On Thu, Jan 12, 2017 at 7:42 AM, Tim Flink wrote:
>
> > The idea was to start with static site generation because it doesn't
> > require an application server, is easy to host and likely easier to
> > develop, at least initially.
> >
>
On Thu, Jan 12, 2017 at 7:42 AM, Tim Flink wrote:
> The idea was to start with static site generation because it doesn't
> require an application server, is easy to host and likely easier to
> develop, at least initially.
>
> I don't really have a strong preference either way, just wanted to say
On Wed, Jan 11, 2017 at 11:42:32PM -0700, Tim Flink wrote:
> The motivation is to enable more complex visualizations of results. If
> we're interested in the current state of all ruby packages or all
> python packages it's not all that easy to see that at a glance with our
> current resultsdb inter
On Wed, 11 Jan 2017 12:43:23 +0100
Lukas Brabec wrote:
> Hi team,
>
> I would like to open discussion on topic "Task Result Dashboards".
> I'm posting here in order to avoid long of the grid discussions we
> had last time regarding the docker testing stuff.
> T
On Wed, Jan 11, 2017 at 12:43:23PM +0100, Lukas Brabec wrote:
> * What is the motivation, what do we want to achieve with such
>dashboards and who is the 'non-techincal audience'?
I guess that depends on what you mean by the technical audience.
Other than people who are steeped in QA day in a
Hi team,
I would like to open discussion on topic "Task Result Dashboards". I'm posting
here in order to avoid long of the grid discussions we had last time regarding
the docker testing stuff.
There is a tracking ticket in phab [1] that links to tflink's initial ideas