Alan DeKok wrote:
Alexander Clouter wrote:
So, how long before I can type 'make menuconfig' eh? :)
Much of that is already in the code. Many of the features can be removed at build time:
- threads - accounting - proxying - dhcp - vmps
I am personally for a single version but with some ifdef uglyness for experimental bits that is enabled by default. If people want different 'trains' then they could just learn how to use git and be done with it....at least they can then use 'git bisect' too.
The issue is more that major changes to the code can affect production systems. It's safer for the production systems to have limited fixes to a "stable" release, and then to have a "feature" release that adds new features.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Especially with this project. Its amazingly stable considering how complex it has gotten and the features that keep getting shoved in. Alan loves rewriting code he doesnt like, and he seems to dislike lots of it over time. Personally, I have always chosen to use the latest bits being worked on at the time of project deployment and further maintenance usually means a complete redeployment. A few patches, recompile, repackage, rewrite of config and off we go. Any critical production system wishing to upgrade should retain the services of a competent freeradius engineer to ensure it all goes smoothly, not like it cant without it, but some of us could use the income. In a sense, that is what distributions are supposed to be doing, so retiring old trains but keeping them alive for critical fixes is a very nice and responsible thing to be doing to help them out. If a bit tedious and annoying as well. I do think some of the oldest trains could stop running already. Thank you Alan for all your hard work, both here on the lists and on the project itself. Joe