cvs commit: src/lib/libarchive archive_private.h archive_read.c archive_read_data_into_fd.c archive_write.c archive_write_set_compression_bzip2.c archive_write_set_compression_gzip.c archive_write_set_compression_none.c

[Maxim Sobolev]

Scott Long wrote:
> Maxim Sobolev wrote:
> 
>> I think extending tinderbox to add into CC all people who have 
>> committed into files that have changed since the last successful build 
>> will help to improve situation a lot. This should be pretty easy to do 
>> - after the buld is complete dig out revisions of all source files (by 
>> direct parsing of CVS/Entries) and save it into some persistent 
>> location. If the next build breaks, again make such list and for files 
>> whose versions differ do cvs log, parse results and compile the list 
>> of people to be notified from it.
>>
>> -Maxim
>>
> 
> No, extra email will just be ignored, just like it is now.  We need

I don't think so. We do have several similar systems in place for ports 
for ages and they are extremelly helpful in keeping the tree sane. Just 
ask yourself: how often do you read freebsd-current and compare it to 
the same interval for your inbox.

> people to raise their personal standards and stop treating the FreeBSD
> CVS server as personal sandbox.  This is just amateurish.

Well, I agree with you wholeheartedly, but do you have any more or less 
practical approach to raise people's personal standards? I don't for 
example, at least not in the volunteer project.

Also don't forget that we are not milti-platform now, so that it's not 
realistically to expect that every committer will test every change he 
makes on 3-4 platforms even just by compiling it, let alone by whole 
buildworld (yes, I know that we do have cross-builds now, but the time 
for making 3-4 buildworlds in a row is prohibitive for most of people).

And the situation is not going to improve, since the probability that 
somebody will break something is vaguely proportional to the number of 
active committers times number of supported hardware platforms.

Therefore, IMHO, the only realistical approach is to improve tinderboxes 
to minimize detection window (i.e. faster, multi-CPU hardware and/or 
tools like ccache) and to make breakage information delivery more direct.

-Maxim