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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
