Here are notes or comments about the Hackathon:

from Tim [edit section]

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]

• 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