Date: Mon, 22 Oct 2012 09:42:42 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r241823 - in head: . etc etc/atf etc/mtree lib lib/atf lib/atf/libatf-c lib/atf/libatf-c++ libexec libexec/atf libexec/atf/atf-check share share/atf share/doc share/doc/atf share/exampl... Message-ID: <CAGH67wSa_gOgAXXMCQ70NJsKm7Ny%2BCT_CS486_80dD4PtUm36w@mail.gmail.com> In-Reply-To: <20121022150706.GD70741@FreeBSD.org> References: <201210220118.q9M1Ifh5098857@svn.freebsd.org> <20121022150706.GD70741@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 22, 2012 at 8:07 AM, Gleb Smirnoff <glebius@freebsd.org> wrote: > On Mon, Oct 22, 2012 at 01:18:41AM +0000, Marcel Moolenaar wrote: > M> Tinderbox breakages that are the result of this commit are entirely > M> the committer's fault -- in other words: buildworld testing on amd64 > M> only. > > Taking into account the fact that last couple of weeks head was usually > not buildable rather than buildable, I strongly disappreciate this. > > It looks to me as we are again treating head/ as a pile of stuff, > not as an operating system one can install and use. > > Now that we have a big choice of VCSes: svn user branches, git and > perforce, why isn't it possible to settle things in private branch > and only then commit them to the head/? I had been checking in changes to p4 over the last 4 months and then I ditched it for a local svn checkout when preparing the final patch that I sent to Marcel; I had run the patch in svn in two different sets of VMs in a make tinderbox manner several times. All but a handful of non-build critical items made it into this commit, and the only breakage that was present was accidental and affected ATF runtime. Maintaining all these moving pieces has proved challenging (esp. because I lack the scripts to track all of the changes that I had at IronPort with p4), and even then tracking new files in p4 is entertaining compared to svn, git, etc. This unnecessary complexity plus the fact that one needs p4 in order to collaborate with the changes I'm working on is the primary reason why I'm ditching it for git. The only breakage that's occurring now we've found is people using clang/libc++ (and libc++ looks like it has bugs that would have been caught with C++ applications written in a C++ standards-compliant manner) and various optimization levels which would not have raised red flags with make tinderbox in the first place. If there was a widespread (gcc and/or standard compiler/linker flags) issue with the build a) we would have seen it be now in the tinderbox emails and b) I would have CCed the current set of mailing lists so the issue would have been resolved quickly. The fact that it wasn't caught illustrates the fact that although we're trying to pilot clang as the default compiler by next month, there's a huge gap in required testing for commits. Looking forward, the major items for ATF have been committed. The rest of the patches which will be committed will be considerably smaller, targeted to specific components, and [for the most part, minus test integration in the tinderbox builds which will only be done after extensively testing is performed] will not affect the standard build process. Thank you for the concern though and I understand where you're coming from. -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wSa_gOgAXXMCQ70NJsKm7Ny%2BCT_CS486_80dD4PtUm36w>