Here are notes or comments about the Hackathon:

from Tim [edit section]

== from Tim ==
I thought the timing was pretty good for this, for a Saturday event.
We held the event from 10:00 to about 4:00.  Most attendees were
not experienced with Fuego, and were there to learn about it.
I did a very cursory introduction to Fuego at the beginning of
the meeting.  For beginner Fuego training, it would be better
to have more detailed training material, going over terms,
the user interface, installation, and basic usage of the tool.
It would be good, in my opinion, to put together basic
beginner Fuego training like this (either in the documentation, or
as a presentation, or a video tutorial, or all three).  The quick intro
I did at the event was not as organized as it would have been
for a real training session.

It took about 30 minutes to set up machines and re-arrange
the lab.  The machines worked well, although there was a glitch
in setup of the Linux laptop used as the Fuego host, that I had to
take some time to resolve.  I should have tested this more thoroughly
before the event.  Given that we came into the lab "cold", and
basically all we had to do was configure the wifi on the server
and test board (the raspberry pi), I think the ease of setup for
the hackathon is a testament to how easy it is to set up Fuego.
(The problem I had was related to sshd on the server, so unrelated
to normal Fuego usage - but important for our use of the server
at the event.)

I thought the Sony lounge worked well for the meeting.  The
space could be re-arranged easily.  We borrowed a monitor
and Japanese keyboard.  In hindsight, having a US keyboard
would have been good.  We used the projector during the
first part of the hackathon (essentially, the training part),
but then didn't use it much during the actual hacking.  In
hindsight it would have been good to use it more, given
that both project groups ended up huddling around smaller
screens for their work.

I thought using the wiki for ad-hoc issue reporting worked well.
I think everyone made an account, and several issues got created. 
It is very useful to record issues as they are encountered, and these
can be turned into regular issues pages fairly easily.  The Fuegotest
wiki should probably have better password security, but hopefully
everyone used a throwaway password for the setup.

I think the tests we actually developed were fairly rudimentary. 
This is to be expected given the amount of time we had.  I tried
to explain how to do a documentation project, but that required
reStructuredText skill that no one had at the event, including me.
Possibly if this had been planned out a little more, with information
at the event about reStructuredText, and a plan up front for how
to do the work, this could have worked.  But this was not prepared
enough to actually work on at the event.
The other tests were basic, but could actually be used on real
hardware to accomplish something.  They could serve as the
seeds for continuing effort in these test areas (mmc and year2038
checking)

Some time was spent trying to figure out what to actually test.
I was involved with the mmc test that got written.  A lot of effort
was spent on the test program that ran on the target, and working
around issues with it being required to run in a minimal shell environment.
This is a significant issue that makes writing a test program more difficult.
The other project (the year 2038 test), took a different approach and
required perl.  Probably for both of these projects, something in C
would make more sense for the test program for the target.  C provides
a rich library, and has no interpreter dependencies.  However,
developing something in C from scratch would have taken much longer.
Maybe we should have some native code templates for this type of thing.
(Maybe we could just re-use some of the LTP template code.)

I originally envisioned having a brainstorming session, but only the
people with Fuego experience would have benefited from that or been able
to contribute to it.  It's quite difficult to have a productive event
with people with wildly different experience with the project.

Summary [edit section]

= Summary =
 - have time for setup (30 minutes to 1 hour)
 - have training material ready to go, if needed
 - don't try to have a brainstorming session with beginners
 - have a project leader for each team
 - make sure test machine has all required peripherals (screen, keyboard, mouse)
 - make sure host machine has sshd configured right
 - try to figure out projects better ahead of time
 - use projector for team work