On Wed, 2011-05-04 at 15:49 -0500, Zach Pfeffer wrote:
Hmm... I took a look at:
https://wiki.linaro.org/Platform/Infrastructure/Specs/RemoteDevelopmentBoard...
..and there nothing about multimedia live debug.
I meant the bit about live debug and development, which is what you mentioned in your previous message. The one there is not specific to multimedia, but we can either change it or add one that is.
On 4 May 2011 15:43, Guilherme Salgado guilherme.salgado@linaro.org wrote:
On Wed, 2011-05-04 at 15:32 -0500, Zach Pfeffer wrote:
Hmm...actually I was thinking a little more interactive and less batch. Having a remote system that I could do live debug and development one.
That's one of the user stories on the wiki page.
On 4 May 2011 15:26, Michael Hope michael.hope@linaro.org wrote:
On Thu, May 5, 2011 at 8:15 AM, Guilherme Salgado guilherme.salgado@linaro.org wrote:
Hi Michael,
On Thu, 2011-05-05 at 03:12 +1200, Michael Hope wrote:
On Wed, May 4, 2011 at 7:50 AM, Guilherme Salgado guilherme.salgado@linaro.org wrote: > If you do, I need to know more about how you'd like to use them, to make > sure we provide something that is suitable to everyone. > > At this point I'm interested in drafting some user stories so if you > have any, please do add them to the RemoteDevelopmentBoards[1] wiki > page. Also, if you'd like to participate in the discussion at LDS, don't > forget to subscribe to the blueprint[2] on Launchpad.
Hi Guilherme. We currently have a Versatile Express and three PandaBoards in the London data centre: https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
There's also a bunch of hardware in my home office that is slowly being replaced by the data centre boxes.
These are set up as porter boxes. Toolchain people are a bit unique as we're very much an end user: a board which is reliable and consistent is more important than the latest and greatest. They're used for building GCC (~5 hours), testing it (~7 hours), building packages, debugging, and all the usuals.
One tricky thing is benchmarking. If you run a benchmark you want the same environment as last time and some type of exclusive access. The
I've added a user story with this requirement.
environment can change over time as these are generally development benchmarks so you can run a baseline first.
Do you mean that when the environment changes you want to run the baseline benchmark against the old environment?
There's two stories:
- A developer benchmarking their latest changes. They can run a
baseline, bring in the change, then run to show the improvement. The environment should stay the same over that week
- The continuous build recording benchmark results with every build.
The environment should always stay the same so that the numbers can be compared
-- Michael
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- Guilherme Salgado https://launchpad.net/~salgado