Re: The wider implications of debhelper/dbus breakage
On Fri, Jul 17, 2009 at 09:05:29PM +0200, Luk Claes wrote:
> 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...
I don't know about you, but I don't download my mails interactively.
Offlineimap is great.
> >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.
That is absolutely not the same thing, as my experience with d-i dailies
has shown.
> >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.
Ah, so this is about not interfering with testing migration, I guess?
If it does indeed happen often that testing migration is delayed because
of long-delayed uploads, then I agree that that's a bad thing; but I'm
not convinced that autosigning is the answer. I do consider it bad form
for a buildd maintainer to "often" take more than one day to sign their
uploads. That doesn't take a long time, and shouldn't be delayed. When
it does happen for me that I don't sign my uploads for a long time, it's
usually because I was somewhere for work where I couldn't reach my mail,
and got home so late that I didn't have the courage to pick up my laptop
anymore, or so; clearly, a rare situation. Thus, this should not in
principle significantly delay testing migration, unless I'm missing
something.
> >[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,
No, I'm counting the time it takes for me to sign a package.
> not the time needed to download the log,
Which is done in the background and does not take any of my time.
> process it
Processing the mail is done by scripts, and takes less than a second per
mail. In fact, it goes so fast that I can do several logs per second.
This process, for all practical purposes, is semi-automated.
> and wait till the cronjob acts on the to be uploaded package.
Which is done multiple times per hour.
> 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.
I'm not quite sure what you mean by those two sentences.
> >[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...
In my case, it happens only once every few months. I do think that if it
happens more often than that, I should give up my buildd hosts because I
clearly don't have the time to handle them properly.
--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
Reply to: