svn commit: r197065 - in stable/8: etc/defaults lib/libc/stdlib sys/amd64/conf sys/i386/conf sys/ia64/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf

Jason J. Hellenthal jasonh at
Fri Sep 11 15:02:28 UTC 2009

On Fri, 11 Sep 2009 03:22 -0000, des wrote:

> "Jason J. Hellenthal" <jasonh at> writes:
>> If I may, I would like to introduce a distributed targeting system to
>> this conversation in addition to crashinfo. Given with the above
>> conversations I cant help but think that in a case like this it would
>> be helpful to setup a central database for collection of information
>> and write a little bit more code into crashinfo for uuencoding a blob
>> to send through email or maybe another way so data can be collected,
>> sorted & analyzed with statistics spilled out into a web page for
>> review.
> It's a good idea in principle, but I'm worried that such a system might
> get flooded with crash reports from people running old -STABLE versions
> and / or local patches.  There is no way we can control that, neither in
> the client script nor at the receiving end.

I am thinking more of something like the project where as they 
have two very well defined projects or areas that they can allow their users to 
work on and that they can close at any point in time. This would certainly get 
rid of the unwanted branch reports.

As for the others I can only help but think of Subversion, uuids, md5 sums, and 
specific version strings that are made up on compile time so as if r??????M is a 
version that is being submitted it would be turned down by the waiting server 
or stopped directly on client side. And for the rest of the world running CVS ;) 
I don't have something coming to mind at the moment.

I am pretty sure though by any means that a solution to all the above can be met 
with prejudice.


  Jason J. Hellenthal
  jasonh at

  - (2^(N-1))

More information about the svn-src-stable-8 mailing list