Skip site navigation (1)Skip section navigation (2)
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>