Date: Thu, 7 Mar 2002 12:45:36 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, John Baldwin <jhb@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>, Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Bosko Milekic <bmilekic@unixdaemons.com>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <Pine.BSF.4.21.0203071229590.37321-100000@InterJet.elischer.org> In-Reply-To: <200203071923.g27JN6I60361@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Mar 2002, Justin T. Gibbs wrote: > > The only way it will get delayed that long is if you spend all of your > time stomping up and down, writing in all caps, and tell the rest of > us that we have to follow the proceedures you think are appropriate. > That's not how colaboration works. You need to compromise and not get > all pissed off if the process requires you to delay your commit for a > bit. Justin, the stuff was backed out when requested, and has been so for quite a while now. NOT ONE SINGLE of the dog-in-the-manger people has bothered to review it in that week. How long is he expected to wait? John has only said that somehow it aesthetically offends his sensibilities in some way. He has certainly not given any techincal reason to not do it, (that I have seen). How long is a person supposed to wait when no-one can give a reason that it should not be committed and there are reasons that it should? > > > I prefer to work in smaller > > chunks and yet here you are trying to justify your nonsense by making > > further attacks on my methodologies and code that are completely > > absurd and completely unsupported by any evidence whatsoever. > > This is not an attack on any such thing. This is about *process*. You > want to commit in small chucks? Great! You want to get this stuff into > the tree quickly? Great! You want to make the code so it can be dynamically > configured for testability? Great! > You don't want to discuss API changes > that have affects on other ports, and other subsystems prior to committing > them? That's unacceptable when people are asking you to explain them first, > regardless of how well thought out or implemented they are. This is not a > race to commit. This is about developing a well designed system without > killing each other in the process. Talk about puting words into another person's mouth! NOT ONE SINGLE PERSON has asked to discuss this work! Matt has already said that he would GLADLY discuss it with anyone who's interested to do so. So far tehre ahve been no takers. > > For this kind of change, the commit message should have been the last, > not the first "public forum" to have expressed these ideas. It was being discusse on mailing lists as well as privatly before teh commit. > > Did I say anything about source files? This is about discussion prior > to commit. Nothing more. > > How is expanding an API not a change to that API? Why is it that when > other developers express a need to discuss these changes prior to them > being committed, their concerns don't matter to you? Are you the only > person in the project that can't keep changes in your local tree for > a few days while you present your ideas? > I have done no such thing. The facts are very simple: Looks very much like it from this direction. > > Matt: I'm going to commit this code to the tree > Others: We should discuss the rammifications first. > Matt: We can discuss it after its in. > Others: No, we need to discuss it first. > Matt: Commit > Others: Back it out until we discuss it. > Matt: !@#$%^$@#. Every time I try to do something its blocked.... > Matt: Backs out: Ok so what do you want to discuss? Others: .. Oh, nothing really, we just felt like stuffing you around again. > > That's not how I perceived this at all. John needs to be active in the > discussion on changes so they are resolved quickly and don't hold you > back. I have not said one thing about your changes not going in other > than to say that they should be discussed first. If John doesn't want > to have to merge with you, he'll have to get his patches into the tree > just like anyone else. No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. > Regardless, you have to be willing to discuss > and perhaps refine your changes prior to committing them. This is true > for anyone on the project, not just you. He's been sitting around for a week waiting for a single person to want to discuss it. I challenge you to find a single person who has asked to discuss the design. (and actually done it). > > It is only a huge deal because it was made into a huge deal. If the > change had been discussed prior to being pushed into the tree, this > would never have happened. I don't think that John, or anyone else, is > opposed to the change going in once some small issues are discussed first. > Just get over this "I've been abused" bit already and discuss the changes! > We all want to move on and I'd rather see us moving on with your changes > than without. No it's only a huge deal because OTHERS made it a huge deal. > > -- > Justin > 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?Pine.BSF.4.21.0203071229590.37321-100000>