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

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.


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    ([EMAIL PROTECTED])

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to