17 messages in org.freebsd.trustedbsd-auditHEADS UP: Audit integration into CVS ...| From | Sent On | Attachments |
|---|---|---|
| Robert Watson | Feb 1, 2006 10:15 pm | |
| Kövesdán Gábor | Feb 1, 2006 10:22 pm | |
| Julian Elischer | Feb 1, 2006 10:32 pm | |
| Robert Watson | Feb 1, 2006 10:32 pm | |
| Robert Watson | Feb 1, 2006 10:55 pm | |
| Mike Jakubik | Feb 2, 2006 12:03 am | |
| Robert Watson | Feb 2, 2006 12:35 am | |
| Kris Kennaway | Feb 2, 2006 12:40 am | |
| Robert Watson | Feb 2, 2006 12:50 am | |
| Mike Jakubik | Feb 2, 2006 12:54 am | |
| Kris Kennaway | Feb 2, 2006 12:57 am | |
| Robert Watson | Feb 2, 2006 1:17 am | |
| Tom Rhodes | Feb 2, 2006 2:13 am | |
| Mike Jakubik | Feb 2, 2006 3:15 am | |
| Peter Jeremy | Feb 2, 2006 9:02 am | |
| Doug Barton | Feb 3, 2006 1:19 am | |
| Robert Watson | Feb 3, 2006 3:52 pm |
| Subject: | HEADS UP: Audit integration into CVS in progress, some tree disruption | |
|---|---|---|
| From: | Doug Barton (dou...@FreeBSD.org) | |
| Date: | Feb 3, 2006 1:19:10 am | |
| List: | org.freebsd.trustedbsd-audit | |
Robert Watson wrote:
On Wed, 1 Feb 2006, Kris Kennaway wrote:
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 ready?
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 this is 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 problems.
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.
Doug
--
This .signature sanitized for your protection
To Unsubscribe: send mail to majo...@trustedbsd.org with "unsubscribe trustedbsd-audit" in the body of the message