On Mon, Oct 22, 2012 at 09:42:42AM -0700, Garrett Cooper wrote: G> On Mon, Oct 22, 2012 at 8:07 AM, Gleb Smirnoff <gleb...@freebsd.org> wrote: G> > On Mon, Oct 22, 2012 at 01:18:41AM +0000, Marcel Moolenaar wrote: G> > M> Tinderbox breakages that are the result of this commit are entirely G> > M> the committer's fault -- in other words: buildworld testing on amd64 G> > M> only. G> > G> > Taking into account the fact that last couple of weeks head was usually G> > not buildable rather than buildable, I strongly disappreciate this. G> > G> > It looks to me as we are again treating head/ as a pile of stuff, G> > not as an operating system one can install and use. G> > G> > Now that we have a big choice of VCSes: svn user branches, git and G> > perforce, why isn't it possible to settle things in private branch G> > and only then commit them to the head/? G> G> I had been checking in changes to p4 over the last 4 months and then I G> ditched it for a local svn checkout when preparing the final patch G> that I sent to Marcel; I had run the patch in svn in two different G> sets of VMs in a make tinderbox manner several times. All but a G> handful of non-build critical items made it into this commit, and the G> only breakage that was present was accidental and affected ATF G> runtime. G> G> Maintaining all these moving pieces has proved challenging (esp. G> because I lack the scripts to track all of the changes that I had at G> IronPort with p4), and even then tracking new files in p4 is G> entertaining compared to svn, git, etc. This unnecessary complexity G> plus the fact that one needs p4 in order to collaborate with the G> changes I'm working on is the primary reason why I'm ditching it for G> git. G> G> The only breakage that's occurring now we've found is people using G> clang/libc++ (and libc++ looks like it has bugs that would have been G> caught with C++ applications written in a C++ standards-compliant G> manner) and various optimization levels which would not have raised G> red flags with make tinderbox in the first place. G> G> If there was a widespread (gcc and/or standard compiler/linker flags) G> issue with the build a) we would have seen it be now in the tinderbox G> emails and b) I would have CCed the current set of mailing lists so G> the issue would have been resolved quickly. The fact that it wasn't G> caught illustrates the fact that although we're trying to pilot clang G> as the default compiler by next month, there's a huge gap in required G> testing for commits. G> G> Looking forward, the major items for ATF have been committed. The rest G> of the patches which will be committed will be considerably smaller, G> targeted to specific components, and [for the most part, minus test G> integration in the tinderbox builds which will only be done after G> extensively testing is performed] will not affect the standard build G> process. G> G> Thank you for the concern though and I understand where you're coming from.
Okay, now I see that you had did a lot of testing and my blame was ungrounded. Sorry. But the commit message from Marcel was so provocating such blame :) And probably I was also driven by the fact that I closed a number of build breakages last week, which weren't mine. Sorry again. -- Totus tuus, Glebius. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
