[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The wider implications of debhelper/dbus breakage



Wouter Verhelst wrote:
On Fri, Jul 17, 2009 at 12:10:56PM +0200, Luk Claes wrote:
Wouter Verhelst wrote:
Right. However, having sbuild run lintian would allow a buildd
maintainer to assess issues with packages by looking at *warnings*,
rather than 'just' errors. This isn't something an automated system can
do.
Right, though that's why we expect maintainers to look at them.
Although there may be architecture specific lintian warnings, they
should be really rare.

They would still catch this kind of bug, though. Also, there *are* many
system-specific warnings emitted by gcc, and those can easily be picked
up by mutt highlighting.

Besides, we want to get some support for autosigning packages built
on the buildds. So we improve the speed of buildd uploads and we
make the job of buildd maintainer more attractive to porters so they
could really investigate (architecture specific) build errors
instead of spending time in downloading, checking and signing
successful build logs.

Hmm.

I'm not sure that's very useful, really. Due to scripts and mutt's GPG
key passphrase caching, my daily buildd mail signing stuff never takes
more than a minute[1], even on days with hundreds of logs that need to
be signed (except if highlighting tells me that there's something that
needs to be looked at, obviously). Perhaps such scripts could be shared,
but other than that...

Unless you have a light speed internet connection you're cheating here...

Additionally, I personally dislike a buildd host that is silent in the
usual case. The fact that there is routinely "something to do" forces me
to continually think about it and not neglect the things I need to do to
maintain it[2]. You'll note that there've been times when the powerpc
dailies were broken for long amounts of time in a row, when I used to
maintain it; this is mainly because the system's output would not be
very different between 'nothing is working' and 'everything is working
fine', so I just wouldn't notice when things were broken.

There are still the admin messages which give a summary of what happened and the logs for the non successful builds.

In other words, I personally do not feel that, from a buildd
maintainer's point of view, the "disadvantages" of having to sign mails
(which is no work at all, really) outweigh the advantages (me being
much, /much/ more aware of what's happening, and being able to take care
of it that much better). I understand that the delay in uploading that's
inherent in manual action isn't ideal from an RM's point of view, but
then that shouldn't be more than 24 hours in the usual case anyway (and
if it is, that's a sign that the buildd maintainer is getting bored with
the job, or needs help, or some such, which shouldn't be the usual case
anyway).

In the usual case at least one of the buildd maintainers takes more than 24 hours to process the log.

[1] and a minute really is exceptional; the average is more like 10
    seconds or so.

You're only counting the time autosigning would need, not the time needed to download the log, process it and wait till the cronjob acts on the to be uploaded package. The latter could be done without autosigning, but as it's measured in hours (maximum), it doesn't make sense to optimise it currently...

You seem to only look at the most optimal situation which is very rare in practice.

[2] obviously there'll always be times when I'm too busy to look at that
    stuff for a few days in a row, but those are the exception rather
    than the rule.

Though unfortunately they don't collide with times when other people are too busy and for a few days it's also not very comfortable to switch to someone else for processing the logs...

Cheers

Luk


Reply to: