Date: Thu, 5 Jul 2001 20:31:43 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: obrien@FreeBSD.ORG Cc: Kris Kennaway <kris@obsecurity.org>, Dag-Erling Smorgrav <des@ofug.org>, Jim Pirzyk <Jim.Pirzyk@disney.com>, freebsd-current@FreeBSD.ORG Subject: Re: chgrp broken on alpha systems Message-ID: <Pine.BSF.4.21.0107052012000.37078-100000@beppo> In-Reply-To: <20010705173831.A15043@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Perhaps what we really need- and this is really a toolchain issues- is a compiler that is just as stringent on i386 as on alpha? I dunno- there used to be a flag to lint that would worn about non-portable size casts. Is there a gcc flag that would cover most of the heavy lifting for this on i386? I'm really well aware that people don't always have the time to test compile each micro change. I'm also heavily aware that groups like NetBSD have a mindset that makes them avoid such problems to begin with. Few (yes, no insult intended, but, yes, "Few") developers in FreeBSD really understand this except maybe at a vague intellectual level. I'm not sure how we can get there. Insults don't work- even though I certainly fire off too many salvos of them myself and am hardly in a position to be sanctimonious on this topic. This is a very complicated subject. It isn't just a cross-architectural issue. It's also a multi-timezone, no real design review, fix it quickly ex-poste type of problem. The same stuff happens *within* an architecture. Many companies have solved this type of problem by requiring proof of complete builds (and cstyle too) prior to committal (Sun) to a parent tree. I don't see that happening here. Nightly builds help. Legato and Auspex and other places I've worked- instituting a nightly build with email to everyone helps keep people at least *aware* of the breakage. But this is not quite pragmatic for a multi-timezone devloper base as we have because, like a WAN, the tree should probably be assumed to always be in transition. So- I'm not sure if institutional process really helps us here. Hence, we probably need some beefier tool support. Maybe we really should get serious about at least kernel LINT again. And this, btw, is just to check the syntax. The *semantics* of what we change is quite different. I fixed Matt Dillon's vm_zoneidle boo-boo in 15 minutes (12 of which waiting for a response on the breakage). It took about 2 hours this morning of boot/crash/fix/boot/crash/fix to actually sort out the semantics. I would suggest that at least the following might be helpful: a) Send changes to audit@ if they're major. b) *try* at least to compile on more than one arch - ask someone for help if you don't have access. Note that Bosko's changes were checked by me for alpha- that was a good way for this to work. Note that Matt's VM changes were checked by me, after things didn't work (or compile) any more. That's not such a good way for these things to happen. When things are a broken- and not just s cvsup timing issue, I intend to try and do the following: Send mail to -current stating apparent breakage State whether I intend to try and fix it myself or not If the responsible party for the breakage is known, they will be directly addressed also. I'll try not to be irritated. I just want the problem to go away. If the timing of the breakage is such that I'll miss my only window for working on Freebsd-Alpha for several days (as has happened about 7 times in the last year), so be it. The same issue will arrive for ia64 and sparc64, too. -matt On Thu, 5 Jul 2001, David O'Brien wrote: > On Thu, Jul 05, 2001 at 02:17:51PM -0700, Matthew Jacob wrote: > > David claimed he would upgrade beast at some point- but he's pretty > > busy. > > Acutally out of the state on a WRS forced "vacation". :-( > > > 1. If I had the authority to do so, I'd drive over to Concord and do it. > > I can do that next week some time. > > beast is actually now in an Exodus facility. > > Not that updating Beast would be the most productive thing considering > how totally unusable 5-CURRENT is on Alpha right now. > > > > Actually, you can work around this if you set enough environment > > > variables, but it certainly is annoying to do. > > What is so hard with ``make -m /home/kris/mk''? > In fact I would say that *no one* should be doing "warnings" cleanup with > testing on the Alpha or sparc64 -- the i386 lets people change sloppy > code to be even more sloppy and get away with it. > > -- > -- David (obrien@NUXI.com) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107052012000.37078-100000>