Date: Tue, 26 Feb 2002 17:57:22 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Bosko Milekic <bmilekic@unixdaemons.com>, Julian Elischer <julian@elischer.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Warner Losh <imp@harmony.village.org>, Jake Burkholder <jake@locore.ca>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 exception.s genassym.c machdep.c mp_machdep.c mpapic.c swtch.s vm_machdep.c src/sys/i386/include cpufunc.h pcb.h src/sys/i386/isa apic_vector.s clock.c icu_vector.s intr_machdep.c intr_machdep.h npx.c src/sys/kern ... Message-ID: <p0510140eb8a1bccc8720@[128.113.24.47]> In-Reply-To: <20020226165301.A29286@unixdaemons.com> References: <200202261822.g1QIMcK95505@apollo.backplane.com> <Pine.BSF.4.21.0202261117520.94891-100000@InterJet.elischer.org> <20020226165301.A29286@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 4:53 PM -0500 2/26/02, Bosko Milekic wrote: >On Tue, Feb 26, 2002, Julian Elischer wrote: > > JHB has had a 8 months to check in his stuff (hey the preemtion > > stuff was done in June) and since then it's only effect on the > > project has been to stiffle and stop all other development in > > the area. > > OK guys, now just a second. JHB clearly posted that _the > preemption code is not ready yet_. What the heck are you > trying to do? Make him commit broken code? Obviously no one would want any other developer to commit broken code. Julian may have picked a bad word by saying "done", as if it were totally complete and ready-to-commit back in July. I suspect that "worked on" might be a better phrase. The point is that work was started on it back in July, and here we are eight months later and other developers are still being told they can not commit their own changes due to this pending change. The problem is not the technical merits of the work JHB has done, the problem is that a large part of the source tree is being "locked up" for eight months. Given how many other developers there are who can work in that section of the source tree, it is not reasonable to "drift into" an eight-month lock on that tree. I think JHB has done a lot of valuable work in trying to keep work going on SMP when so few people had time to work on it, so I am not trying to paint him, personally, as a bad guy. I am saying that no single developer should have the right to put "a lock" on a large part of the source tree without an explicit vote for that lock by core, or the project as a whole, or something. We had that vote for KSE work. There was an explicit time-period, and people could hold Julian's feet to the fire about how that work progressed. We did not have that vote for SMP work, and now that Matt's all fired up to make some changes that "unofficial lock" is something which either needs to be made "official" -- with the same kinds of constraints that KSE had --, or it has to be moved aside. If the code "is not ready yet", after eight months, then it is a poor reason to hold up the work that other developers would like to do. If we knew it WOULD be ready in one or two weeks, then maybe we should wait for it. But here we have Matt eager to do a bunch of SMP work, and it would be a waste to put him on hold for some arbitrary and unbounded period of time while we wait for this other update "to be ready". I, personally, am also leery about any update, from anyone, which has been worked on for months with very little review, and very little real-world usage (ie, on a wide variety of machines). I am increasingly uneasy that what JHB will come up with is one huge "take it or leave it" patch, and I do not think that is a good idea. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu 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?p0510140eb8a1bccc8720>