Date: Thu, 05 Jul 2001 19:22:34 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Dima Dorfman <dima@unixfreak.org> Cc: kris@obsecurity.org, mjacob@feral.com, obrien@NUXI.com, des@ofug.org, Jim.Pirzyk@disney.com, freebsd-current@FreeBSD.org, Jordan Hubbard <jkh@osd.bsdi.com> Subject: Re: chgrp broken on alpha systems Message-ID: <XFMail.010705192234.jhb@FreeBSD.org> In-Reply-To: <20010706015445.5B7203E28@bazooka.unixfreak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06-Jul-01 Dima Dorfman wrote: >> In the WARNS= case, another >> workable method would be to commit the warning fixes but don't commit the >> actual WARNS= change until the build has been verified on all archs. > > This doesn't work. The point of WARNS, as I see it anyway, is not to > scrub the tree so that `make buildworld` produces less warning output. > The point is that people who are modifying programs are less likely to > introduce bugs if warnings as treated as errors (presumably, the > compile outputs good warnings that actually help find bugs). The > above (your idea) works when WARNS= is set the first time, but not > when a program with WARNS set is modified. This, I think, is the real > problem; it isn't a problem to test on all arches when you *first* set > WARNS. The problem is somebody making a small change to the program > later. They may not even know WARNS is set; their code didn't trigger > warnings on their test box, so they think it's okay. Furthermore, > this makes it harder for non-committers to submit changes; at least > committers have potential access to the other arches (e.g., beast). Good point. However, I would argue that we don't need to just lower the standard and say its ok for warnings to persist. These things can be fixed to work on all archs. One thing that would help is for people to be a little less uptight and when a bogon pops up on one arch just fix it and go on. Yelling and screeching about it doesn't really accomplish anything, and people who are more familiar with the arch are in a much better position to fix the little bogon's (size_t instead of int) anyways. Basically, some people take offense every time the alpha build breaks and spend more time complaining about it then it would take to just commit the simple fix. Recently, this trend has started changing somewhat (Matt does commit lots of quick fixes for simple build breakages nowadays) and I think that just realising that developers have limited time to spend on this project (volunteers after all) and being a little more flexible is probably the most practical solution. It is current after all. By the time changes get MFC'd, they will have surived all the archs and won't break stable. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010705192234.jhb>