Am 13.08.2013 21:10, schrieb Adam Borowski:
> So I guess it would be best to put the threshold at automated vs
> human-supervised builds. What about setting the flag per-tool rather than
> per-deployment? For example, pbuilder would default to verbose (as you
> can't restart builds) while dpkg-bu
Dmitrijs Ledkovs wrote:
> We have build log analyzers running for the build logs.
Checking heuristically for problems you know about does not help find
the class of problems you don't know about yet.
> How about a new DEB_BUILD_OPTION="silent" which opts into silent build
> log? Does that sound r
Adam Borowski angband.pl> writes:
> Non-spammy builds are better for builds done by a human.
No.
They’re better for builds done by the developers of the upstream
software on their own systems where they know what they’re doing.
And even then, it’s a big maybe.
Every other human is a packager
On Tue, Aug 13, 2013 at 08:30:16PM +0200, Dmitrijs Ledkovs wrote:
> In controlled environments, one doesn't get to re-run a build, as the
> instances are stripped-down and destroyed on build failure E.g. all
> the jenkins instances running debian package builds, PPAs,
> auto-package-tests, automate
On 13 August 2013 19:59, Julien Cristau wrote:
> [why oh why are you breaking threading?]
>
> On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote:
>
>> We have build log analyzers running for the build logs. And the
>> important compiler warnings (errors) fail the build.
>> If we make t
[why oh why are you breaking threading?]
On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote:
> We have build log analyzers running for the build logs. And the
> important compiler warnings (errors) fail the build.
> If we make this opt-in, we will fail to achieve this goal. As when on
6 matches
Mail list logo
