On 2013-08-16 6:47 PM, Gregory Szorc wrote:
On 8/15/13 2:50 PM, L. David Baron wrote:
On Thursday 2013-08-15 14:11 -0700, Gregory Szorc wrote:
I feel that having developers develop on the same toolchain as
official builds (producing bit-identical builds if possible) would
cut down on patch development costs due to reducing the frequency of
failures resulting from discrepancies between the build
environments.
It also increases the costs of upgrading the toolchain and the costs
of porting to new environments.
Furthermore, it reduces the chance that we'll quickly catch real
bugs in our code that only show up on some toolchains. Catching
bugs quickly greatly reduces the cost of fixing them since the code
is fresh in its author's mind.
I'm going to push back against this a bit. Currently, the cost of
supporting a new toolchain or build environment is highly distributed
and not always planned since any developer at any time can use a varying
toolchain or environment and experience breakage. Bugs are filed and we
get distracted unbusting unsupported toolchains. There are benefits,
sure, but there is a disruption cost here.
I don't think the cost here is as high as you think, in most cases it is
the developer who has encountered this problem who's fixing it in.
By strictly limiting the number of supported environments and
toolchains, we limit the overall effort required to support them. If I
were to order our environments by their uniformity, I'd say Windows is
the most uniform (we ship MozillaBuild and Microsoft ships a pre-built
toolchain), followed by OS X, and finally Linux. While I don't have hard
numbers, I'm reasonably confident saying environment variance is
directly proportional to the number of bugs filed for build breakage.
I'd say Windows build breakage not caught by our automation is rare.
Linux and OS X build breakage, however, is comparatively common.
I don't contend your point that supporting new environments or
toolchains is a lot of work. However, I'm not sure if the cost is higher
if we hold off, especially when you consider the advantages of
performing the upgrade on our terms (as opposed to whenever people in
the wild file bugs and cause mini fire drills by doing so).
Hmm, I don't really know which issues we're trying to fix here. We
explicitly break builds with toolchains that we know we don't want to
support. We allow builds for all other toolchains. Expectiung that
everybody uses the exact same toolchain as what we use in our
infrastructure is not reasonable, and it hurts because of the reasons
that David mentioned. We've always done this, and it just so happens
that Apple clang 4.1 is a compiler that we're explicitly not interested
in supporting. Has anybody else complained about anything here? :-)
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
