Date: Thu, 28 Jan 1999 18:30:10 +1030 From: Greg Lehey <grog@lemis.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Nate Williams <nate@mt.sri.com>, "Justin T. Gibbs" <gibbs@plutotech.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: MAINTAINER file (was: cvs commit: src/sys/i386/eisa ahb.c) Message-ID: <19990128183010.D8473@freebie.lemis.com> In-Reply-To: <199901280609.WAA93705@apollo.backplane.com>; from Matthew Dillon on Wed, Jan 27, 1999 at 10:09:03PM -0800 References: <199901280133.RAA40079@freefall.freebsd.org> <199901280332.UAA25969@pluto.plutotech.com> <199901280546.WAA26358@mt.sri.com> <199901280609.WAA93705@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 27 January 1999 at 22:09:03 -0800, Matthew Dillon wrote: > >>>> >>>> Revision Changes Path >>>> 1.5 +7 -2 src/sys/i386/eisa/ahb.c >>> >>> There certainly was a bug there, but your commit made the driver >>> non-functional. Why not pass your concern on to the author/maintainer of >>> the driver instead of committing something that does not address the >>> problem? If I had missed your checkin mail, I would never have noticed the >>> bug especially after you cleared the compiler warning without really fixing >>> the problem. >> >> Justin's response is *exactly* the kind of thing that striving for -Wall >> buys us. We're fixing the warning, but not the problem. > > Bullshit. You don't know what the fuck you are talking about. I > committed the adjustment, but it was plainly suspicious to me that > I pushed it out to the lists and left it on my hotlist. > > This is one adjustment out of over 800 that I've committed today. If you > want to spend the time to go through each and every one of them like > I have, then you have a right to comment on it. But otherwise, I am > not interested in people sitting on the sidelines making reactionary > ( and completely unsupported) comments about things they have no clue > about because they haven't bothered to run through what's been done. Well, there are other issues apart from whether you introduce bugs. Everybody does that from time to time. A different issue is that a number of parts of the system are still in a state of flux, and any changes, even correct ones, can be a nuisance. Consider the situation today: I was just about to commit some changes to vinum, and to my surprise I found that the version I had just supped had been updated an hour earlier. I had to first investigate the changes (which, as far as I can tell, fixed bugs rather than introduced them :-), and then merge them with my own. I did find one change, however, which introduced a warning. If I had supped an hour earlier, I would not have got these updates. In fact, I suppose there's a chance that I missed a few as it is. I have vinumconfig.c, vinumio.c and vinumstate.c. Were there others? CVS is a useful tool, but it's not infallible if people check in across the network, as I do. In general, I think it makes sense to distinguish between two kinds of modules: those that relate to mature software, such as the base system, and those which relate to software which is still changing relatively frequently, such as CAM and vinum. In the latter case, I think that one person should coordinate changes to the module. One possibility would be to put a MAINTAINER file somewhere to indicate this property. What do you others think? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990128183010.D8473>