* Marc G. Fournier ([EMAIL PROTECTED]):
> What's to track? Nothing happens on that branch ... I just CVSup'd
> RELEASE, followed by RELENG_4_7 and the only changes were pretty much
> related to the latest BIND vulnerabilities ...
The "security branches" are fortunately a very slowly moving target for
which you can develop and maintain *your* *own* patches.
What stops you from doing just this?
What keeps you from applying Matt Dillons VM patches to RELENG_4_7?
What keeps you from merging new features from -STABLE into your private
RELENG-branch?
You have chosen to maintain systems which stretch FreeBSD to its limits
and uncover bugs lurking in the code. This is great. But you cannot do
so on the one hand and refuse to face the administrative work on the
other hand. This does not work. You have the freedom to maintain your
own release with all the patches and fixes you need. Why don't you do
it? Instead you waste your time with complaining (and you waste my time
because I have to read it and think about the replies I am going to
send)?
As for the eroding stability: this is partly true, in my opinion because
-CURRENT and -STABLE's codebases have diverted to a great extent. There
were so many new CURRENT-only features implemented in the last few
months (SMPng, KSE, GCC update, GEOM, ...) which caused more or less
grief and instability for a long time. My guess is, that due to this no
one using -CURRENT had time to test features which were to be MFC'ed
extensively. And due to the ongoing instability of -CURRENT there were
probably not enough non-developer users with -CURRENT systems for
testing, so probably most things MFC'ed in the last few months got their
first round of thorough testing by a wide user base just after the MFC.
Anyone remember the ata(4) trouble?
I do not know whether the above was true when RELENG_3 was -STABLE; I
use FreeBSD only since 4.0. But I think that it could not have been that
bad, since I found 4.0 "useable". As it seems 5.0 will be shipped with
big red warning signs attached :)
> Purely security vulnerabilities ... no 'critical patches' ... I would
> consider most anything related to the VM subsystem to be 'critical', at
> the very least ...
Please discuss this with the security officer.
--Thomas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
