Re: Explications needed...
On Fri, Dec 29, 2006 at 07:58:34AM +0100, Sven Luther [EMAIL PROTECTED] wrote: Don't you find it a bit hypocrit to have x86 uploads go directly to the archive, and not allowing even a single day delay which would allow to stop unclean DD-build-boxes breakage and a clean state, and on the other day let the other arches depend on the good will of the buildd maintainer, who is usually a single person, who doesn't communicate much, and who sometimes is not able to sign and thus upload the packages for a couple of days (sometimes more even, but i guess this is the exception). It's even better than this. The DD could upload on any arch and let buildds do the job for the others. The arch could even be arm. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
Le jeudi 28 décembre 2006 à 16:45 -0800, Steve Langasek a écrit : So first of all, neither the debian-arm list, nor the #debian-arm channel, nor his blog are a communication medium that's guaranteed to reach the arm buildd maintainer *or* the buildd local admins. For the former, you want [EMAIL PROTECTED]; for the latter, there is no list of contacts other than the buildd maintainer, since these may change semi-frequently and most buildd changes need to be coordinated with the buildd maintainer anyway. An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not doing his job as buildd maintainer. You can't pretend to be the one handling builds for the whole archive while not following discussions around problems specific to this architecture. Would you trust a release manager who wouldn't be reading debian-release? If he only uploads packages that haven't been built by the autobuilders, or failed to build on the autobuilders, we still have the problem that there is no single party who can account for the configuration of all the buildds that were used for uploading packages, because there has been no coordination -- so building these packages on rogue autobuilders is a poor predictor of whether the autobuilders will be able to build them again later when a security update is needed. Indeed, in the case of Aurelien's buildds, we have the additional variable of using emulated arm systems -- I don't know what ARM instruction set qemu emulates, and I don't know who else among the ARM porters knows, maybe it's been discussed and maybe it hasn't, but it's definitely another variable that contributes to these buildds being a poor predictor for the official autobuilders. Please, let's be consistent. How is it any different to the sourceful upload case? In fact, I trust Aurélien's buildd much more than my own sourceful uploads; last month I have broken an amd64 package by not building it within the right chroot, while this cannot happen with his buildd using the same software setup as the official buildd network. Uploading packages like this is an expedient fix that does nothing to help, and possibly quite a bit to hinder, long-term support for etch. We want to fix autobuilder problems, not cover them up. Then let's fix them, now. For example, by making Aurélien an arm buildd maintainer. Unless you want etch to be delayed for 6 months because of missing buildd infrastructure, but things like that could never happen, could they? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
[RFH] Review of year 2006
Hi, Ana Guerrero and me started preparing a review of year 2006. We use DWN, Planet Debian, debian-project@, debian-devel@ and debian-devel-announce@ as sources for this review. But we now face the following problems: (a) we want to try to be objective, but with two persons only writing it, this review becomes everything else but objective. (b) this is a huge amount of work to do. With lots of discussions on -project and -devel this year, we currently see no light at the end of the tunnel. So it would be nice if some more persons would volunteer to help with this review. It is planed to publish it on times.debian.net and it would be nice to have it also on other places published, as LWN or linux.com. First drafts for January and February are availible on [1]. Ana and me are currently working on March and April. Coordination for the review should go via debian-publicity ML. We need volunteers for both (a) and (b). It would be nice if our small team could be strengthen by a few more members. Greetings Martin [1] http://times.debian.net/~zobel/2006 -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
Josselin Mouette [EMAIL PROTECTED] wrote: An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not doing his job as buildd maintainer. Please show where reading everything on [EMAIL PROTECTED] is given as a requirement for buildd maintainership. You can't pretend to be the one handling builds for the whole archive while not following discussions around problems specific to this architecture. Similarly, people can't pretend that mailing debian-$arch is a substitute for emailing [EMAIL PROTECTED] (which is in the buildd section of the devel-ref). In message http://lists.debian.org/debian-project/2006/12/msg00161.html and the parent of http://lists.debian.org/debian-project/2006/12/msg00155.html Aurelien Jarno comments about emailing [EMAIL PROTECTED], so what has this [EMAIL PROTECTED] vs [EMAIL PROTECTED] to do with anything? Would you trust a release manager who wouldn't be reading debian-release? I'd trust one who didn't read eveything on debian-release. I'm uncertain about who did what on the whole RogueOrNot buildd, but much of that email seems to be unhelpful. This looks like an old problem: the project doesn't recover gracefully if people in its organizational structure become unresponsive. Any bright ideas on how to fix that? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
On Fri, Dec 29, 2006 at 11:36:45AM +, MJ Ray [EMAIL PROTECTED] wrote a message of 43 lines which said: An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not doing his job as buildd maintainer. Please show where reading everything on [EMAIL PROTECTED] is given as a requirement for buildd maintainership. It seems common sense! Debian has a serious problem if you have to write everything down. A buildd maintainer must be able to type Unix commands on a keyboard. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
On Thu, Dec 28, 2006 at 04:45:32PM -0800, Steve Langasek wrote: On Thu, Dec 21, 2006 at 11:39:13AM +0100, Aurelien Jarno wrote: All started with this email: http://lists.debian.org/debian-arm/2006/08/msg00151.html ARM was *in danger*, a lot of stuff (java, xulrunner, mono, ...) were not working correctly. People worked hard to fix that, but it was very difficult to get packages depending on fixed stuff to get requeued. Also a lot of arch-specific compile errors were actually due to build daemon problems. Yes, let's be clear here: ARM was in danger because of a large number of packages that were *not buildable*, not just because they weren't built. The call for help was in identifying the reasons for the build failures so that the underlying problems could be fixed, *not* for hand-building packages and ignoring the implications for security support. I feel it's deeper than that: now that aurélien completely stopped to upload non built packages at all (a thing he did on a regular basis before, and just automated with his rogue autobuilder) just look at [1], whereas every single arch is keeping up quietly, arm and sparc seem to go to the deepness of hell. I don't know who are the sparc buildd admins, but for sure, the arm port do not seem to be that well. [1] http://buildd.debian.org/stats/graph2-week-big.png -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpHKqw7fEGny.pgp Description: PGP signature
Re: Explications needed...
Stephane Bortzmeyer [EMAIL PROTECTED] wrote: MJ Ray [EMAIL PROTECTED] wrote Please show where reading everything on [EMAIL PROTECTED] is given as a requirement for buildd maintainership. It seems common sense! Huh? It seems common sense that most subscribers ignore at least some list emails, particularly on unguided lists like debian ones. This has been common for years. See these links from 1999 and 1998: http://cmc.dsv.su.se/select/coping-with-too-much-email/#filtering http://cmc.dsv.su.se/select/information-filtering.html Debian has a serious problem if you have to write everything down. A buildd maintainer must be able to type Unix commands on a keyboard. I agree. It seems silly if we must write buildd maintainers do not have to read all emails to debian-$arch. So, back to the more general problem: how should the project handle bits of the organization going silent? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
On Fri, Dec 29, 2006 at 11:20:30AM +0100, Josselin Mouette wrote: An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not doing his job as buildd maintainer. You can't pretend to be the one handling builds for the whole archive while not following discussions around problems specific to this architecture. I think you're confusing the buildd admin with the porters. I expect porters to read the [EMAIL PROTECTED] list, I don't expect the same from the buildd admin. The buildd admin's job is getting packages built, while the porter's is to deal with architecture specific issues. The buildd admins aren't always also porters for that arch. But I think it would be a good thing that (some) porters also see all the buildd logs. That way they know alot faster about problems the port might have. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
I think you're confusing the buildd admin with the porters. I expect Maybe that's because the buildd admins used to be the porters, and then, for some reason I do not understand, this mysteriously stopped being true. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
