[OpenAFS] buildbot and packages

Ken Dreyer ktdreyer@ktdreyer.com
Mon, 17 Sep 2012 10:25:38 -0600

Thanks everyone who replied. There was a lot of email on this thread,
so I'm going to write a quick summary.

There are concerns that this would increase the support load on
organizational helpdesks that support AFS internally, and on the
OpenAFS community overall.

There are concerns that generating the packages (at least on Windows)
will dramatically increase the build time on the buildbot slaves.

Windows binaries go through a manual signing and registration process,
so the additional developer dependencies there may make it infeasible
to do fully automated packages for Windows at all right now.

It's important to identify these snapshot builds as "not official".
This must be clear to the user before they install it, and clear to
the support staff after the software has been installed. The web
interface for downloads must have big warning signs, and from a
support perspective, we should use unique version strings accessible
by "rxdebug -v" or "fs version" etc.

There are concerns about how to do version numbers for these
snapshots. I did some research and it looks like we were setting
version numbers of "9.9.9" back when we had nightly CVS snapshots.
Those were just source tarballs though, so they weren't as accessible
to the casual user as what we're talking about. And this wouldn't
really work well for nightly builds since the date value wouldn't be
encoded in the binaries.

Ben pointed out that whatever version numbering scheme we use should
be cross-platform so it can align with package managers where

Simon pointed out it would be nice to extend the build testing to
packaging so that package maintainers could still catch the necessary
packaging changes (eg. when new files appear). This would probably
need to be balanced against the other factors.


I think a good next step would be to decide how we should handle
version numbers in snapshot packages. For example: should configure.ac
in the 1_6_x branch contain something like "1.6.2" or "1.6.2git" right
now, and a build script could tack on a date or git hash to that
number every night? I'm open to writing patches to the
"build-tools/git-version" script, or otherwise.

- Ken