>>> No offence, but how many times did you break the build? Could you please >>> compile your code before committing next time? Thanks a lot!
>> Just an observation: a few years ago when I got sick of Linux's "headlong >> rush" development model, I subscribed >>to various BSD mailing lists to see >> what else was out there. I considered FreeBSD at the time - there was a >> >> neverending avalanche of "[head tinderbox] failure" messages. This told >> me that I would be more likely to be >> running code written by people who knew what they were doing if I went with >> Open, Net, or DragonflyBSD. >Quite honestly, the head/current branch is going to have build >failures.. It's the test bed.. Stick with the release system unless you >want cutting edge.. just remember.. cutting edge cuts sometimes... In the context of this thread, 'test bed' could mean anything. To clarify, are you saying: a) You think it is ok for commits to be made to the head source code, that cause it to not compile. b) Anyone who disagrees with this should be running release, not current. The head branch is distributed around the world by a network of mirror sites, and then downloaded and compiled by a large number of people. It seems a very inefficient use of resources for this infrastructure to be used to see if some code will build. Would it not be more useful for current to be a test bed of bugfixes and new features, rather than directing users to a release and having current as a test bed for "will this compile"? Or I suppose we could all just wait 6 months for a release candidate to see if today's current has introduced any regressions on our hardware. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
