Date: Fri, 08 Dec 2000 17:57:42 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Christopher Masto <chris@netmonger.net>, cvs-all@freebsd.org, cvs-committers@freebsd.org Subject: Re: cvs commit: src/sys/vm phys_pager.c Message-ID: <3A30A286.30E102EC@newsguy.com> References: <20001205145908.K8051@fw.wintelcom.net> <Pine.SUN.3.91.1001205180108.24320A-100000@pcnet1.pcnet.com> <20001205152054.M8051@fw.wintelcom.net> <3A2EFBC4.EE8D90B1@newsguy.com> <20001207173453.A18103@netmonger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Christopher Masto wrote: > > object = vm_object_allocate(OBJT_PHYS, > - OFF_TO_IDX(foff + size)); > + OFF_TO_IDX(foff + PAGE_MASK + size)); > > Honestly, this thread is ridiculous. If the code didn't work in the > first place, AND nobody noticed because it's so rarely used, AND the > change is _obviously_ trivial, then what's the problem here? "stable" > is not "immobile". Typos happen. Go look the cvs repo or cvs-all archives, and you'll see plenty changes very much like the one above where the committer just happened to make a typo and not notice. Also, using cvs also sometimes can result in mistakes, by confusing versions, mixing local repo with remote repo, etc. Further, any code with macros and/or #ifs may not compile cleanly under different options than what the author tested them with. This is not hypothetical. It *happens*. It has happened in the past, and will happen again in the future. And risking breaking -stable's world is just not worth waiting a few hours to see if no one had a problem. > Even if this fix was wrong (and apparently it was), it doesn't change > the fact that it was: > > 1. A fix for code that was known to be unusably broken But, nevertheless, didn't break world. > 2. Extremely unlikely to hurt anything (esp. given #1) As far as *functional* changes go, this is right. But the problem is elsewhere. See above. > 3. Extremely unlikely to break the world (obvious by inspection) Experience tells another story. In particular, typos have an annoying tendency of escaping visual inspection because the human mind tends to adjust what it is seeing in terms of what it expects to see. > 4. Trivially reversible And trivially simple to wait 24 hours. > You've got the right argument, but you've picked the wrong example > to apply it to. There has to be _some_ flexibility in the rules, > and it would be hard to find a better example of where "shakeout > in -current" has no value. It is very, very bad when -stable world breaks. It tarnishes our reputation, increases support workload, and make people less confident in the process. Perhaps I see the rules in a different light than many others. To me, "common sense" there refers to being able to discern when a commit _must_ be merged as soon as possible. I have no problems with Alfred making such a call. But the call he made, and many others seem to support, is one of "may" be merged instantly. I don't think anything may be merged instantly unless there are reasons that _requires_ it to be merged instantly. This, at least, is my view of the rules in the light of the problems that have happened in the past. Alfred, I'm not disputing your ability to make judgment calls. I just think that the risk of silly mistakes (mentioned above), that have nothing to do with what your _intentions_ were when you wrote the fix, outweights the benefits to be gained by an instant MFC (as a matter of fact, I don't see any benefits except your own convenience). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org capo@the.great.underground.bsdconpiracy.org "The bronze landed last, which canceled that method of impartial choice." 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?3A30A286.30E102EC>