I arrived two days early so that I could recover from the first stage of my vacation preceding the conference, and then socialize. (The latter can be an advantage because trying to carry on a conversation in the larger groups later in the week can sometimes be daunting.) To some extent this was just a continuation of my vacation (i.e. funded out of my own pocket.)
Glen and Deb and I started off with an evening of conversation over dinner. This was mostly a "well, where are we now?" discussion. Glen and I adjourned later for a discussion of ports build infrastructure that eventually wound up with us toasting the memory of some departed four-legged friends.
As the various members of the Ports Management Team arrived over the next few days, I began spending time with them in various informal sessions. Ports remains my main area of interest.
Wednesday was the first day of the devsummit. I attended the nested kernels session which I will happily admit was over my head. I was also interested to hear how Isilon manages their use of FreeBSD.
Thursday morning brought the documentation session by Warren Block. Warren has many new ideas. While translations are not my interest, Warren is thinking about ways to bring people into the translation project that involve finding ways to lower barrier of entry. In particular, he is experimenting with technology that would allow non-technical users to contribute to a translation dictionary without having to have commit rights. (Later, actual commits would be vetted.) I found persuasive the idea that we are excluding "people with an interest in documentation but no grasp of our documentation build processes" from participating. This is an object lesson that my own viewpoint has been too narrow and based on my own past experience with various markup languages.
Thursday evening I was asked to sit in on the portmgr meeting. We spent several hours going over "where are we now and where do we want to go". Within the last 12 months we have finally acquired enough hardware to be able not just to build the bare-minimum packages and experimental (exp-) runs, but also to think about what our ideal build procedures should look like, and what kind of analysis tools that we need. Some of those ideas are still under active discussion, but I think I can comment about the following:
- Establish some "publish criteria" before declaring a quarterly branch as the "new" official branch. Right now there are no criteria other than trying to read through lists of error summaries. We need to be able to create some kind of automated figure-of-merit for each particular build. My view is that portsmon could be augmented to help with this, but in any case, we need this functionality.
- It is difficult to evaluate regressions on individual runs. A "test instance" of portsmon should probably be used to do this. A method already exists to display these data but even the portmgrs do not understand it well. (FWIW, portsmon does not "know" what builds are -exp builds; it treats all build inputs the same. It would be far easier to instantiate a separate "test" portsmon that takes input from those builds to display to those specifically interested, than to rearchitect the UI. This would continue to keep those data out of the current instance, which is intended for the general public as well as ports infrastructure developers.) (In fact, the development instance in Austin does exactly this, as well as gather occasional test results from my tier-2 machines here. I am used to it, but others would most likely be confused.)
Friday brought the first day of BSDCan proper. The key talk that I wanted to see was about QEMU package builds. I retain an interest in the tier-2 architectures. I believe that supporting multiple architectures helps keep FreeBSD more robust. Sean Bruno and Stacey Son have made a great deal of progress on the cross-build poudriere environment. Of particular interest was Stacey's list of what work remains to be done to complete the emulation. There is, of course, a tradeoff curve between how complete the emulation of (e.g.) syscalls is, and how many real-world use cases are affected. No emulation can ever be pefect, of course.
I also attended the afternoon network performance presentation. I do not have enough in-depth knowledge of the network system to understand all the implications, but was interested to pursue whether some of the framework could help us to do more general performance testing such as Kris Kennaway used to do. This is an area that I think we should spend effort on.
The most important session on Saturday was on packaging the base system. I expected this talk to be more controversial than it was. (Perhaps everyone was beginning to get tired ...)
There is a great deal of work that has been done so far, but it seems there is still some distance yet to go. One of the next problems to face will be to define "what do we consider a FreeBSD base system to be". However, there are already some variations on the theme, among the more notable being nanobsd, crochet, and freebsd-wifi-build. IMHO each ofthese is an incompatible attempt to solve the same underlying problem. If it is possible to create one solution that will encompass all these attempts, it will be a big achievement.
Summary: lessons learned:
It's hard to overstate the importance of the "hallway track". Among the people who I was able to reconnect with (including Glen as mentioned above) were Sean Bruno, Gavin Atkinson, Stacey Son, Justin Hibbits, and Marcel Moolenaar. A lot of good ideas get kicked around there as well.
Another lesson that I learned the hard way last year is that it's physically impossible for me to attend every single session and then every hacking lounge and every nightly social activity. I was much more judicious in pacing myself and this helped me not wear out as early on as I did last year.
All in all I got a much better idea of what areas we need to work on for the rest of the year by attending the conference.
mcl
