> My big concern is that nightly installable builds will be a support > nightmare. > There are a large number of users that will always take the latest no > matter what. > > I realize there is an argument to be made for users being free to do > hang themselves. But I question whether that is what organizational > help desks are prepared to support. > > The real issue that needs to be addressed is how to produce supportable > releases on a more frequent basis. In the past the consensus among the > gatekeepers has been to move to a biweekly release cycle. Whatever is > ready for a given release date gets pulled up and anything that isn't, > doesn't. > > However, this requires having a much greater availability of release > management and testing resources.
And perhaps an argument for automated tests that could prove out a release? If you mean manual testing resources, given the scope of platform support and myriad branches for OpenAFS I doubt 'enough' will ever be enough :) If we could bend those resources to creating and maintaining functional tests then that might be a better use of time. Definitely a challenge though. > Coupled with the biweekly release schedule, I believe it is important > that the web site provide guidance to end users as to which release > build is known to be reliable on which platforms. Otherwise, users > will > always go for the most recent build and frequently end up with something > much less reliable than we would prefer. > > Jeffrey Altman ____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
