Personally, i would like to see less "experimental" code in 6.1.
Perhaps it would be better to wait until everyone feels the code is
Why do you care if code that is not enabled by default is present in
the system? :-)
Well, I think there are some potential risks. The main ones are:
(1) That the unconditionally compiled bits cause problems. Primarily
the audit support in login, sshd, etc. Apple has been running with
basically the same code for a couple of years now, but there is always
risk in change.
(2) Risk to users who do try the experimental support and run into bugs, or
run into things that we will change for a 6.2 release as we fix
I was with you right up until that last bit. Given that we are changing the
release model to time-based releases as opposed to feature-based, the
"danger" that we'll go a long time without users having access to new
features is significantly lowered. Therefore, IMO we need to be even more
careful about making sure that -stable branches stay stable; including
A[BP]I issues. No matter how carefully we label something as "early
adopter," etc; users of -stable are still going to complain if something
they come to count on changes out from under them, and I have a lot of
sympathy for that argument.
My vote would be to leave it in HEAD until it's thoroughly cooked, then make
the decision to MFC or not based on how close we are to 7-RELEASE.
This .signature sanitized for your protection
To Unsubscribe: send mail to majo...@trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message