Bug#121459: microwindows build status
On 4 Jan 2002, Thomas Bushnell, BSG wrote:
> Michael Schmitz <firstname.lastname@example.org> writes:
> > (I rarely do these
> > days, rather rely on the maintainer to check build status and
> > logs).
> This is not such a good idea. Maintainers are generally not
> responsible for checking build status and logs; the port maintainer
> (whoever is responsible for making the binary NMU) should do that andn
> file an RC bug.
You have no idea what you're talking about here. While this may be the
best solution in an ideal world, it's pretty damn impractical in the
I've been filing 450 build logs since Dec. 31 for PowerPC. Today's been
rather slow, but there's been on the order of 100 builds a day, 70
successful (skim log file, sign, a minute work each) and 10 failed builds
(other than build dependencies that won't install, or disk run full, or
other fun stuff) per day. Only a select few are no-brainers like obvious
build dependencies missing these days. The others require careful
examination of the log and looking up stuff in the build tree (config.log
comes to mind) to even compose a meaningful fail log message.
That's been an hour filing success logs, at least another half hour filing
fail logs, plus whatever it takes to figure out why some freaking build
dependency wouldn't install, or what permanently installed part of the
bloated chroot (in order to catch most of the commonly missing build
dependencies) better be upgraded today. That's only powerpc - m68k builds
at a slower rate, but there's more problems with package dependencies
there, and more machines to keep running smoothly.
To cut a long story short - I find I rarely go the extra mile of filing a
meaningful bug report (forwarding only the fail logs didn't go over well
with a lot of developers) when the basics already take a big chunk out of
my day. There may have been the same bug noticed by another autobuild
admin, and been reported already (duplicate bugs from three or four
autobuilders go over real well, too). It may have been a sporadic problem
with the build chroot, gone the next time a package comes up. If there was
just a single failure to report each day I'd perhaps file a bug, but not
with things as hectic as they are now.
With all architectures collecting build logs at buildd.debian.org,
plus each of the autobuilder sporting its own web interface for looking up
status and log, finding out why a package is out of date on a particular
architecture has become painless enough IMHO. The autobuilders already
take a huge load off developers (imagine everyone manually building their
packages on each architecture).
> Indeed, there are many packages that miss getting into testing because
> of some problem uploading or building one port or another, and
> maintainers in general seem to be totally unaware of these. I think
In my book, that's a problem with the package maintainers (the lack of
awareness, not necessarily build or upload problems :-).
> the people who take responsibility for uploading the binary NMUs for
> various ports need to also take the responsibility for filing bugs
> when things are failing.
Technically these are binary NMUs, but I'd rather think of them as
happening on behalf of the maintainer by some obscure magic, and that
ultimately leaves the maintainer in charge of checking the result (at