[sig-srcomp] Planning meeting, this Thursday

[Alistair Lynn]

Hi all–

Peter, Tom and I will be having a hangout on Thursday about srcomp to plan what will be changing in it to support the upcoming competition.

If anyone else is interested in srcomp and would like to come along, do let one of us know.

Alistair

[Rob Spanton]

Hi Guys,

On Mon, 2015-02-02 at 20:18 +0000, Alistair Lynn wrote:
> Peter, Tom and I will be having a hangout on Thursday about srcomp to
> plan what will be changing in it to support the upcoming competition.

I can't make Thursday evening. But this is my general view on the
srcomp arrangement: change nothing, except for fixing bugs. It's
already shippable. The only thing that needs to be sorted out is the
disk images for the display drivers.

Cheers,

Rob

[Peter Law]

Hi everyone,

Alistair wrote:
> Peter, Tom and I will be having a hangout on Thursday about srcomp to
> plan what will be changing in it to support the upcoming competition.

The following is a summary of the things which we talked about (much
of which we're expecting to do) with a brief outline of why they need
doing. In each case I've prefixed with a rough level of importance and
followed in brackets by the person likely to do it where I could
remember. (Tom & Alistair: please dive in and correct anything I've
misremembered or missed.)

## Changes to the competition mode website pages
* Must: Update to new backend REST API (Peter)
* Should: The competition mode home page is rather ugly, and needs
some attention from actual UI designers (Tom may run a Doing)

## PEP 420 bug
* Could: There appears to be a bug in pythons handling of implicit
namespace packages [1] which breaks Flask, our python appserver
of choice. Since this is limited to install via pip, we can ignore it by
installing via `python setup.py install`.

## Write Docs
In order to make it easier for others to get involved, we need to
create docs which explain how stuff works.
* Should: API level docs (all)
* Could: full system explanatory docs

## Knockout handling
* Must: ensure ties in knockout matches are resolved properly (Peter)
* Must: ensure delays handling is consistent and works (Peter)
* Should: allow for knockout including only the top N teams, ie not everyone

## Simplify the process of adding delays
* Must: it took about 5 minutes to do this last year, which is about 4.5
minutes too long: #2496 (Peter)
(This will likely result in some structural changes to the comp state repo
to simplify automated processing of it.)
* Must: simplify the process of deploying a new compstate to all the relevant
machines. This operation consumed a good portion of the delay-adding time
mentioned above. #2664

## Compbox setup
* Must: We need an easily deployable local machine to run a clone SRComp
and other competition specific services. Note: this will _not+ be a clone of
saffron. Most likely a modified copy of last year's, but needs updating.

## Venue displays
* Must: Update to new backend REST API (Tom)
* Could: various UI fixes from trac (Tom)
* Could: develop a kisok system to automate deployment #2831; this took
several hours last year

## Shepherding info
* Should: script the generation of printable schedules for Shepherds (this
itself is a fallback in case of other failures similar to those from SR2014)
* Could: NEW: We noted that it might be nice if the Shepherds (at least the
head shepherd) could have a hard-wired screen which showed them
suitable information. This would supplement the information available via
other sources, but would be more reliable due to having a hard-wired
connection and running on a device we control. It would probably be placed
near the arenas.

## Various internal tidyups
* Should: makes srcomp slightly easier to understand and work with; don't worry,
it's well-covered by tests (all)

## Rules patch
* Should: Remove the phrase that the zones are marked with masking tape.
Everyone hates masking tape, and we really want to mark them coloured to the
zone colour. We should also mention that we'll almost certainly put down
_other_ tape to number the zones for humans (also colour-coded).
The result here is that this makes the linesmen's jobs much easier since the
numbers-for-humans can more easily be matched to the scoring sheets which
will almost certainly be printed in black and white.

## Update the score entry UI
* Must: design the score entry forms #2740
* Must: update the scorer to have a similar UI (Alistair)
* Should: fix bugs in the scorer, particularly the ability to override it (Tom)
* Should:

## Teams Status data
* Must: use SRComp as only source. Last year the website pages used a
separate endpoint within srweb for teams data, which was probably quite
expensive. Compstate already has the capability to hold this data, and should
become the only source. (Peter)
* Must: script the dumping of team-status data into compstate (Peter)

## Saffron SRComp deloyment
* Must: needs updating to PIP style sources

## Arena entry traffic lights #2839
* Could: build something which displays whether or not competitors may enter
an arena. This could reduce load on the linesmen.

## Testing
* Should: we aim to have the system complete sufficiently in advance of the
competition event to have a dry-run, possibly involving some actual linesmen.
This will enable testing of the whole system under battle conditions,
while also providing a valuable opportunity for the linesmen to acclimatise.

## Probably already fixed:
* #2454 - Team real names on the screens (Tom)

In most cases, the fallback for not achieving the planned changes is
that we ship stuff from last year or that we just don't automate
things which were previously done another way.

You'll probably note that some of the above disagrees with trac for
the moment. I plan to resolve that shortly, and will probably be
adding the Must and Should items to the 2015 competition milestone.

## External input (ie, how you can help)
* We'd like to work with whoever is going to be running the networking at the
competition to ensure that there will be enough available connections (etc.)
* We'd like input from the shepherds on the idea of a fixed screen
* We'd like to hear from anyone who wants to help!

Thanks,
Peter

[1] http://bugs.python.org/issue23389

[Peter Law]

Hi,

> The following is a summary of the things which we talked about (much
> of which we're expecting to do) with a brief outline of why they need
> doing. In each case I've prefixed with a rough level of importance and
> followed in brackets by the person likely to do it where I could
> remember. (Tom & Alistair: please dive in and correct anything I've
> misremembered or missed.)

It turns out I did miss some things -- additional items follow.

## Match scheduling
* Should: SMT solving based scheduling is ok, but takes ages. Alistair has
written a(nother) scheduler [2], which supports rounds and appears to have
suitably distributed output. This needs reviewing. (all)

## SRComp Extensions
* Could: Apparently there was a Doing in Southampton a while back where a
number of utilities based on SRComp were explored. It would be really great
to hear more about those which showed promise.

Thanks,
Peter

[2] https://github.com/prophile/sr-scheduler-2015

[Jeremy Morse]

Hi,

I haven't had time to read through in detail here; however Alistair
suggested that the 'srcomp' repo should be in maintainer mode as it's
deployed on saffron, so I've switched it from a standard project to a
maintained one.

--
Thanks,
Jeremy

[Jeremy Morse]

Hi,

This all looks pretty good, a couple of queries,

On 07/02/15 21:20, Peter Law wrote:
> ## Changes to the competition mode website pages
> * Must: Update to new backend REST API (Peter)

> ## Venue displays
> * Must: Update to new backend REST API (Tom)

There's some specific reason for this being necessary, yes? At this
point in time optimisations and performance are a legitimate concern.

> * Should: The competition mode home page is rather ugly, and needs
> some attention from actual UI designers (Tom may run a Doing)

Sam'd probably appreciate having his opinion sought, he does do similar
things for a living.

> * Must: simplify the process of deploying a new compstate to all the relevant
> machines. This operation consumed a good portion of the delay-adding time
> mentioned above. #2664

Just so I understand, this is because the compstate will be in at least
three places:
* saffron
* an on-site compbox
* someones machine as they enter new state
and that's it, yes?

> * Could: develop a kisok system to automate deployment #2831; this took
> several hours last year

Yes please; early investment here will solve all kinds of problems on
the day.

> ## Saffron SRComp deloyment
> * Must: needs updating to PIP style sources

Not wild about this; after a discussion with Peter, this is actually
going to cost a reasonable amount of dev time to deploy properly (rather
than just splatting out git repos), which is the opposite of simplifying
installation.

> ## Arena entry traffic lights #2839
> * Could: build something which displays whether or not competitors may enter
> an arena. This could reduce load on the linesmen.

Uncertain: it also undermines their authority. It's probably fine if the
exact procedure and timings are thought about carefully and tested.

> * Should: we aim to have the system complete sufficiently in advance of the
> competition event to have a dry-run, possibly involving some actual linesmen.
> This will enable testing of the whole system under battle conditions,
> while also providing a valuable opportunity for the linesmen to acclimatise.

That would be excellent.

> ## External input (ie, how you can help)
> * We'd like to work with whoever is going to be running the networking at the
> competition to ensure that there will be enough available connections (etc.)

That might fall on me again (my body is ready); some diagram based on
last years competition plan will ensure we're all on the same page here.

> ## Match scheduling
> * Should: SMT solving based scheduling is ok, but takes ages.
> Alistair has written a(nother) scheduler [2], which supports rounds
> and appears to have suitably distributed output. This needs
> reviewing. (all)

Might want to be in another thread, but this sounds good, the SMT/SAT
search procedure is designed to ignore all domain specific knowledge.
I'll take a look at it at some point.

--
Thanks,
Jeremy

[Peter Law]

Hi,

I wrote:
>> ## Changes to the competition mode website pages
>> * Must: Update to new backend REST API (Peter)
>> ## Venue displays
>> * Must: Update to new backend REST API (Tom)

Jeremy wrote:
> There's some specific reason for this being necessary, yes? At this
> point in time optimisations and performance are a legitimate concern.

Earlier in the year Tom & Alistair reviewed the API and reduced the
duplication of data that it offered. This results in fewer back-end
chunks doing much the same thing, which ought to be easier to
maintain. I don't know that it's been evaluated from a performance
perspective yet.

The above points are to get the front-end pieces in line with what's
now in the back-end.

>> * Must: simplify the process of deploying a new compstate to all the relevant
>> machines. This operation consumed a good portion of the delay-adding time
>> mentioned above. #2664
>
> Just so I understand, this is because the compstate will be in at least
> three places:
> * saffron
> * an on-site compbox
> * someones machine as they enter new state
> and that's it, yes?

Yup.

>> ## External input (ie, how you can help)
>> * We'd like to work with whoever is going to be running the networking at the
>> competition to ensure that there will be enough available connections (etc.)
>
> That might fall on me again (my body is ready);

Cool, thanks!

> some diagram based on
> last years competition plan will ensure we're all on the same page here.

Indeed; are you proposing that you produce said diagram?

Thanks,
Peter

[Jeremy Morse]

Hi,

On 09/02/15 19:23, Peter Law wrote:
> Indeed; are you proposing that you produce said diagram?

No, someone else, who understands the srcomp plans. One of the layers in
last years plans represented what I put up in terms of networks. If
someone familiar with competition software plans can patch the layout to
show where wired access is needed for software, I'll be able to
understand what's required.

--
Thanks,
Jeremy