Date: Tue, 26 Feb 2002 20:47:31 +0000 From: "J. Mallett" <jmallett@FreeBSD.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: "M. Warner Losh" <imp@village.org>, julian@elischer.org, dillon@apollo.backplane.com, 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: <20020226204731.A2458@FreeBSD.ORG> In-Reply-To: <p05101406b8a19aae8813@[128.113.24.47]> References: <200202261822.g1QIMcK95505@apollo.backplane.com> <Pine.BSF.4.21.0202261117520.94891-100000@InterJet.elischer.org> <20020226.124843.125707643.imp@village.org> <p05101406b8a19aae8813@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 26, 2002 at 03:10:42PM -0500, Garance A Drosihn wrote: > All the effort which is going towards SMP is great to see (so I say, > from the sidelines...). But work which is actually committed is > easier to deal with, in a practical sense, than work which just > sits out there "being worked on" for months and months. I do not > want to pick "good guys" and "bad guys" here, but we do have to > clarify what is acceptable practice and what is not acceptable. But with acceptable practice here you run into this being a good example situation. You have Dillon who has good things which by all means belong in CURRENT, which belong in CVS, and which is finished and can be expanded over time. You also have JHB working in the ideal system for the work he is doing. A SCM which handles changesets along with revisions is _absolutely_ essential to develop such a large large set of changes, which will have good and bad design and implementation decisions made over time. If JHB wants to totally redo how a structure is used throughout his tree one day, he can make that change, see how it works with his general scheme, and then if the next day he decides it's wrong, he can back out that entire changeset. This is a very simple example of why for such a broad-implications project as JHB is doing, working in CVS and merging-as-he-goes may not be the best thing. I am sure that if John broke everything but smp-box-under-my-desk people would be yelling for weeks about how he needs to develop in a more suitable area outside of the tree, and possibly with a more suitable tool, like Perforce. Acceptable practice should be working on a project in the way that that project should be tackled. It should also be said that kicking and screaming when you are told "No" is no better than kicking and screaming when someone asks to commit something which may have implications on code that is NOT in the tree. Dillon has to work with what he has access to, and if he can improve it he should. On the same token JHB's work is extremely important and broad and needs to be kept seperate largely, but also needs to be respected as it does touch just about everything, and making it harder to ensure that when it is merged things will work As Advertised(tm) does nobody any good. I wonder if people would prefer to have 500 developmental branches in the repository, with HEAD being pulled up to each of them on a monthly basis. I'm sure those who mirror the repository would not be appriciative. Defining acceptable practice here requires you to determine who is the holder of work that applies more the CURRENT at this point, as well of the future of CURRENT. If Dillon's work can be made more SMPng friendly at the code level then it should be done as long as it is still applicable to CURRENT in and of itself. If it cannot be, then the work will be useless eventually anyway, so it's hardly worth wasting time on it, from either side. Just my thoughts, worth what you paid for them. /j. 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?20020226204731.A2458>