Re: Multiple stability issues with r208557, r208809 on amd64

On Tue, Jun 8, 2010 at 4:59 PM, Xin LI <delphij_at_gmail.com> wrote:
> Do you mean between the two revisions or something?  I committed
> r208557 which doesn't seem likely to cause any runtime issue; 208809
> is isp(4) change which is not part of your kernel...
>
> [delphij_at_delta] /usr/src> svn log -r 208557
> ------------------------------------------------------------------------
> r208557 | delphij | 2010-05-25 15:19:51 -0700 (Tue, 25 May 2010) | 4 lines
>
> Grammar nits.
>
> Submitted by:   b. f. <bf1783 googlemail com>
>
> ------------------------------------------------------------------------
> [delphij_at_delta] /usr/src> svn diff -c 208557
> Index: release/doc/en_US.ISO8859-1/relnotes/article.sgml
> ===================================================================
> --- release/doc/en_US.ISO8859-1/relnotes/article.sgml   (revision 208556)
> +++ release/doc/en_US.ISO8859-1/relnotes/article.sgml   (revision 208557)
> _at__at_ -327,7 +327,7 _at__at_
>       based on <filename>libarchive</filename>, have replaced the GNU
>       Binutils versions of these utilities.</para>
>
> -    <para>BSD-licensed version of &man.bc.1; and &man.dc.1; has
> +    <para>BSD-licensed versions of &man.bc.1; and &man.dc.1; have
>       replaced their GNU counterparts.</para>
>
>     <para role="merged">&man.chflags.1; now supports a
> <option>-v</option> flag for
> _at__at_ -378,7 +378,7 _at__at_
>       disable the use of TCP options.</para>
>
>     <para>&man.nc.1;'s <option>-o</option> switch has been deprecated.
> -      It will be removed in future release.</para>
> +      It will be removed in a future release.</para>
>
>     <para>The &man.ping6.8; utility now returns <literal>2</literal>
>       when the packet transmission was successful but no responses

Hi Xin!

Well, I hope that that wouldn't cause my machine to tank (otherwise it
likes to be a grammar nazi too much :P)...

What I was trying to identify is a general trend in terms of
evaluation of different versions of CURRENT; somewhere after the code
revision that I noted (r206173), the code appears to be regressing
more and more to the point where CURRENT has become completely
unusable to me in a development scenario, other than just a throwaway
NFS rootfs, s.t. recent code changes need to be thoroughly inspected
and the regression / multiple regressions needs to be root caused
before 9.0-RELEASE, otherwise this will definitely gate multiple
people from upgrading to newer versions of FreeBSD. This probably is
somewhat related to the locking changes, and the fact that several
drivers might have been broken before, but because there were
safeguards around certain sections of code, or because it was
operating at a slow enough rate, the system itself appeared sane and
happy from the outside. But that's probably just useless conjecture
anyhow...

I realize that CURRENT is supposed to be relatively in flux and it's
primarily for development and evaluation, but I thought that the whole
point of having development branches was to avoid the scenario where
the software itself was completely unusable on dev boxes so that
several folks could work in parallel with [relatively] minor conflicts
between each others' changes. Part of the reason why I've avoided
passing along pkg_install patches -- I want to make sure that I do my
job in testing things to a large degree so I don't break other
peoples' machines unnecessarily (and I'm sure that the bulk majority
of developers on the project feel the same as well).

Thanks!
-Garrett