On Thu, Sep 20, 2012, Dave Pigott wrote:
Let's try to think of a way of handling this properly. Let's gather the requirements and see if there is some sensible "ticketing" type system, with some auto-configuration, that would make sense. In terms of re-flashing a board, this would be easy to provide access to, by connecting the board to a USB port on the gateway server. It always mounts with a known volume name (which is configurable, of course), so there's no issue of having to udev it like we do the snowballs.
The initial plan when discussing how to best allocate TC2 boards was that we'd have (amongst others) two boards for platform work, but we ended up being short of boards, so we prioritized boards to people working on big.LITTLE kernel code or testing it and on TCWG for A15 work on KVM or A15 optimizations / errata work. I believe the latter use is still very important, but lacks engineers to support it. There were also 2 boards meant for LAVA.
Platform work kind of requires having boards physically with the people working on this or that platform.
Maybe we want to revise the LAVA allocation to allow some platform work on TC2; 4 TC2 is a bit much for LAVA alone given how scarce these are.
Except for the ones in LAVA, the allocation spreadsheet is in: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AoZqvK7R1biJdGxmRU...
So in short, I don't think the ticketing system will help Android, but it might be relevant for e.g. shared hackbox usage between TCWG and PMWG for instance.