Slashdot Mirror
XFree86 Politics
Pivot writes "Keith Packard wants to fork the XFree86 effort. 'It has been brought to the attention of the XFree86 Core Team that one of its members, Keith Packard, has been actively (but privately) seeking out support for a fork of XFree86 that would be led by himself. He is also in the process of forming a by-invitation-only group of vested interests to discuss privately concerns he has about XFree86 and the future of X. He has consistently refused to even disclose these concerns within the context of the XFree86 Core Team, which makes his membership of that team unviable. As a consequence, Keith Packard is no longer a member of the XFree86 Core Team.' The XFree86 team is trying to become more open, to combat the fork. Keith is a capable developer, having worked on FontConfig, Xft, the X render extension etc. Meanwhile, All is not good in how XFree86 drivers are being developed. Anyone remember the GGI initiative a few years back, and the uproar it caused?"
Mike Harris is a bright guy, as anyone who has followed the various Red Hat mailing lists over the last few years will know. When he speaks out like this about the inadequacies of the development process of XFree86 we should all stand up and take notice. Be sure to take the time to read the advocago link in this story.
Maybe he is holding it back. I say fork!
Actually to be honest, I would like the transparency server but more importantly things like the Mach64 driver need to be integrated so I can get XVideo and DRI w/o having to download binaries. The stuff in question has not been updated in ages and I am concerned that the 4.3 release will go unnoticed and I'll be stuck w/o dri.
I think XFree86 needs a good fork. It seems to suffer from a sort of PHP-Nuke meglomania. Vendor support is massively important; if ATI is nice enough to supply patches to add support for their latest cards and latest features, it would help linux and unix in general to be nice enough to check in the patches ASAP. If vendors look upon Xfree86 as worthless to support drivers for because of inability to delegate responsibility, then X and linux in general will never reach the usability levels that we strive for.
That being said, forks are dangerous and should only be done by talented contributing people with people skills. Keith Packard is a good coder, I hope he's as good with politics.
Gnuyen
Not Found
The requested URL
Apache/1.3.26 Server at www.xfree86.org Port 80
He better find a new home for his homepage methinks!
Trolling is a art,
I've read Mike Harris' log entry and I agree with many of the points he brought up.
... if XFree86 wants to be more open, why did they remove Keith Packard from the core team in the first place? I know he has contributed in XFree86 that is beneficial but still, despite that he wants to fork off his own XFree86 tree, does the people at XFree86 require to know what he (Keith) intends to do with it?
But the thing is
~ Old Warriors Society
When you signed up to work for our organization, we made a contract. That contract states that you are not allowed to work on any other external project without our permission.
Not only have you decided to form a competetive product, but you're also trying to steal our people away. We can't have this nonsense at our company.
This organization has to protect it's financial interests. We can't have competition from within. We don't want you to take anything away from our premere product.
You're fired. You'll hear from our lawyers in regards to the anti-compete clause that you agreed to.
XFree is old, should be rewrited from scratch, but the problem is the time. XFree works in a lot of architectures, and a lot of different hardware. Out there there are good alternatives (from a "design" point of view) like DirectFB but they run just on few hardware, and, usually, only 1 architecture. So, the problem is, XFree is too big to make forking a good idea, i think people should just make current X better without any fork. We need some standard for direct hardware access (like DRI) and concentrate work on them. Just an opinion...
Keith better be damned sure _why_ he's forking
That is almost certainly why he has been "privatly" talking to people about a possible fork. He isn't stupid, and there is no way you could fork a project like XFree86 without both internal and public backing of some sort.
Now that XFree86 Core has got its panties in a bunch and thrown Keith out, it has probably made the posibility of a fork even more likely. After all, Keithe has been one of the main drivers behing recent XFree86 development, he is passionate enough about XFree86, he has the skills to lead a fork, and he is unlikely to want to move onto something else. There is also the opurtunity to solve a lot of the internal development problems that XFree86 seems to suffer, which would be a good thing.
Now having said that, I hope that Keithe does not fork XFree86. Its a big project, and could simply cause a fabulous split in the developer base. That would be very, very, very bad.
...is one that constantly seeks out new talent and includes their efforts in the project. One thing I've learned about managing (FSVO) an open source project is that the worst thing you can do is to ignore people's contributions. Heck, if Mike's diary entry is still the state of affairs, there are more people with commit access to the Hercules CVS repository than there are XFree86, a project that's probably two orders of magnitude bigger!
No wonder people are getting frustrated. Perhaps a fork is in the best interests of the XFree86 project.
I'd be interested to hear Keith's side of the story, especially his concerns. If they're correct, though, and he's only willing to discuss them with a handpicked developer community, I doubt we'll hear anything useful.
Disinfect the GNU General Public Virus!
The message posted by "Moulinneuf" actually suggests to me that Keith probably is well-justified in doing this. It makes sense to kick people off an open source project if they don't contribute or do technically the wrong thing, but that's clearly not the case with Keith. OTOH, if a project member wants to test the waters for a fork privately, so what? Moulinneuf's message sounds like Keith was part of the secret service and spying for the enemy. Sounds like wounded pride and politics to me.
Another question one might want to ask, though, is whether it isn't worth starting an X11 server from scratch. X11 isn't as complicated as the XFree86 server makes it appear to be. And the priorities have shifted, too: stuff that used to be really important in X11 could perhaps now be shifted to simple generic implementations.
Such is the way of open source. Fork, I say! I only hope that Keith's concerns are truly pragmatic and related to the software, rather than ego.
The binaries for XFree86 are over 70MB in size, what on earth are they putting in there? Maybe it is time to fork this project or start again from scratch and apply modern design techniques. How about modularising the engine? Why do you have to download every driver for every stinking card out there when you only have 1 video card in your machine? This thing's bigger than early versions of Windows, and it's only a display driver. With a modular design the individual companies could produce their own driver which could simply drop into the main X engine. That would free up the developers from worrying about approving all the patches from each of the major vendors, and they could concentrate on writing some useful core software.
All those moments will be lost in time, like tears in rain.
Thats crap to put it midly. You write an X application right and it works everywhere. Please already run a huge range of X servers, including WeirdX, MetroX, Accelerated X, eXceed and the like all of which are different codebases, and WeirdX is even in a different language.
Its like arguing that you can't write a tcp/ip application if NetBSD and OpenBSD forked. The truth is that since both speak the same protocol it doesn't matter at all.
A forked tree would basically kill X as a _standard_ platform. If I write an X app, do I write it for XFree86 or XFree-KiethP?
Considering that I can run every Linux app imaginable using a completely non-XFree86 X11 server on Windows (XWin-Pro, Xceed), I'd have to disagree with you there. I'm sure the KDE team didn't "write KDE for" XWin-Pro, but it works fine. Also, there are non-XFree86 X servers for Linux that work great, one of which I can't remember the name (it's a commercial server).
X11 is the standard. XFree is just an implementation of the the standard. Similar to HTTP is the standard, but Apache and IIS are implementations.
I don't know a single app that targets XFree directly. They all target X11. The apps may take advantage of XFree86 features, but run on any other X11 server. The same will be the case if they fork.
But as the development in XFree is rather slow, and at least my impression is that all feature-improvements in the last 2 years have been partially or completely done by KeithP, I doubt that anyone would still bother to use XFree in another 2 years...
I'm not deeply clued in to XFree politics, but my off-the-cuff impression is that this would be a good fork. XFree, for all it's great qualities, could definitely be more forward-looking, especially in the rendering area (i.e., aa, subpixel, alpha etc) Keith's speciality. I don't know how it might work out, but it would be nice to see more competition/openness on the display driver front as well, especially 3D, and especially, 3D used for 2D rendering, which I'm sure Keith has some ideas about.
Have you got your LWN subscription yet?
The whole strength of the open source concept is that the many hands in a community can make complex problems shallow. If forks can't happen, then a monopoly on the supply of software develops. However, within there already seems a situation in which the threat of a fork is forcing a previously partially closed community to consider how to open up more.
Don't forget that forks are considered by Linus to be essential elements of a successful project. They allow the opportunity for alternative approaches to be tried, and if successful to be adopted. The trick in the kernel is that Linus recognises this and is prepared to merge again when a fork shows its worth
This hasn't worked through yet - it may well be that the threat that it might happen allows the situation to improve such that the natural progression is to bring the two sides together again. This is an opportunity not a threat and we should encourage it
This is a great laugh.... If you had any idea of the bad blood between XFree and Thomas Roell and XI.
Thomas Roell wrote the original X386 code base which he contributed to the X consortium. He then happily started his own business to sell x86 X-servers. Imagine how pissed off he was when other people took his code base and started undercutting his commerical offering
Until XFree 4.x was released XI's server was arguably the better offering. But I don't think you could make that case now...
D.
They already have the idea of a core. All they need now is to create a level of developers with commit permission to take the load off the hands of a few committers.
:)
There are established rules to how to be a committer.
Most important are the perks!
Same as now. X extensions are negotitated and its done with compatibility covered. Shared memory is an extension, Video overlay is an extension , Xrender is an extension ...
Its just X is so good at this people don't notice 8)
The window resize issue is a known one, and due mostly to a bug in the "smart" scheduling algorithm XFree uses, rather than any inherant slowness of X or XFree.
The lagging of the window contents behind the borders is likewise known, havoc pennington has been playing with XSYNC lately to try and reduce that issue.
Ok, I've participated in many X "discussions" and the one feature of X that is always trumpeted is the out of the box network transparency.
As the Windows and Mac OS GUIs increase in sophistication, we have seen that they have been able to add in "network transparency" to an extent (ok more like "remote viewing") with things like VNC, and other implementations, that exist entirely seperate from the GUI proper - they basically implement a very very basic bitmap-copying protocol.
Is there a case where THIS IS NOT SUFFICIENT? Is it really that much of a win to burden the entire architecture with a feature that in its common use can be implemented completely seperately and still solve 90% of the problem?
I'm serious here, can some a heavy/long-time user of X illustrate cases where they NEED network transparency built in (besides that it is "elegant" technically)? The only thing I can think of is having remote windows "integrate" with your local X server - but is this a COMMON CASE at all? I would imagine the common case to be temporarily using remote apps (potentially on an entirely seperate desktop instance) in which case it doesn't matter (or is in fact beneficial) that they are visually distinct, OR using an ENTIRE remote desktop (KDE, Gnome, etc.) in which case ALL your apps will be "integrated" visually since they will all be running on the remote machine.
In what circumstances would you WANT disparate remote applications, from potentially multiple remote machines, integrating invisibly in your current desktop ?(I for one would think this would be hell of a confusing! "Shit did I just 'rm' that file on my local machine, or the server!??") What is the benefit here? What is the cost?
It's 10 PM. Do you know if you're un-American?
Just an idea, but if you're using the latest 1.0.4xxx drivers from nvidia, they have a new (read "broken") 2D acceleration driver. Check out the forums at nvidia.com.
If you need decent 2D response, and you can spare the slight increase in 3D performance, just use the 1.0.3xxx series.
Hope this helps.
-- don't discount flying pigs until you have good air defense
What we actually need is a replacement for X11, redesigned from the ...), which is a shame, but it's
ground up, with compatability libs to allow normal, window-bound
X11 apps to work on it. We'd lose existing "special" apps (window
managers, screensavers, panels,
what needs to be done to allow for future improvements.
Don't get me wrong, I mostly like XFree... but the design is
(gradually) reaching the end of its useful lifespan. There are a
number of improvements I'd like to see that are fairly impractical
for a design based on X11. Resizing windows is nice, but I also
want to be able to scale them. (This implies that bitmapped fonts
should die, among other things.) Being able to grab a bitmap of
the desktop and use it as a window background is one thing, but
I really want a full alpha channel for every window (controlled
by the application for each widget in the window, or for each
pixel in an image canvas widget) plus an overall opacity setting
(controlled by the user) for the whole window. And so on.
Cut that out, or I will ship you to Norilsk in a box.
Me: Installs 3 series drivers
Me: marvels at sudden increase in 2D performance
Anyway, as I was saying, XFree86 is an excellent implementation and I won't hear a word said against it.
Me: attempts to mod own comment down
I'm not sure that's such an issue: X need not be bloated with the way it works. In 1993/1994, I was acceptably running X on a machine similar to the 386 you quote.
X has some superb architectural features (since 1986!) that Windows *still* doesn't have. There's no need to throw them away.
Oolite: Elite-like game. For Mac, Linux and Windows
Remember that multiple forks of the linux kernel already exist (e.g. the -ac tree) that are fairly important, and that the gcc 2.9x/3.x series is based on the old egcs fork.
I'm not saying that forking is always good, but forks in major packages do happen, it's not the end of the world, and a lot of good things can come from it. As major packages, the improvements made possible by a fork can have much more effect than forks of small, insignificant packages.
Keith has come by PSU (I mean Portland State, not Penn.) several times to lecture in Bart Massey's AI classes. I haven't met him, but I do know some of the people involved in some of this "new X stuff." My girlfriend even had lunch with him once. Several of the people I work with were involved in pre-XFree86 X development and have nothing but good things to say about him.
My take on this is, Keith has some pretty radical ideas for changing X. At least, radical in the eyes of the XFree86 "core team." I've seen him on the lists defending his opinions, and he does so maturely and patiently, even when people don't agree with him. I think he's just given up trying to convince the XFree86 team, but he doesn't see that as any reason to abandon his development. Why shouldn't he make a fork if that's what he wants? If XFree86 didn't want this, they should have never made the source open.
For this perceived treachery, the core team whines and boots him out. Pretty stupid considering he was making considerable headway with Xrender, the only major advance in the basic graphical functionality of X in many years (excluding hardware acceleration).
I'm gonna go out on a limb and say that if Keith is successful in what he's doing, there will be plenty of people running his stuff in the future, and XFree86 might become much less relevant.
From the announcement.
He has consistently refused to even disclose these concerns within the context of the XFree86 Core Team, which makes his membership of that team unviable.
We don't know if that is true or not, and we haven't heard his side of the issue yet. It may be a moot point, because it sounds like he anticipated those ideas would not be welcome, and this announcement probably confirms that notion.
What everyone seems to be saying, is he was the most useful person on the team, at least in terms of generating improvments in the system. All of the things I see attributed to him (like fontconfig and xft work) are the things I looked forward to in the latest release.
just forking for the sake of it just splits the developer base, and the new fork usually gets bad press and poor support.
:-(
I think I'm going to cry. Keith has done the most amazing stuff -- Xft, the modern font architecture -- all the really good features that I've played with recently. If he splits off, XFree86 is going to take a very serious hit.
Please, please, *PLEASE* try to work this out with Keith, XFree core. If you need to maintain more stability, think about a more unstable devel versions, or even a second "really unstable" devel tree that patches can at least enter the tree. Anything, just don't end up hating each other and refusing to share your code with each other.
Either side of such a fork would have a much weaker team. We need XFree86 so much right now, with 3d becoming important to mainstream Linux users. I appreciate all that the XFree folks have done, and asking for more seems ungrateful -- but please try to work it out without ultimatums. *Please*. The mplayer folks hang together, even though A'rpi's abrasive, because he's a really great coder, and everyone would be worse off if he wasn't involved.
Man. I feel almost as bad as when Bungie was purchased by Microsoft. The world *needs* Keith and XFree core being friends, not adversaries.
This and a war in Iraq, and it isn't even 1:00 yet. What a awful day.
May we never see th
About three years ago I was a happy user of XFree86 3.3.6; then XFree86 4.0 was released and my Matrox Mystique stopped working. After carefully determining that the cause was almost certainly a bug in the XFree86 4.0 driver, I decided to send a bug report to XFree86. I read all the relevant instructions on the web site, collected the required data, and sent a polite and detailed bug report to the appropriate mailing lists.
After some weeks I had received no answer. Bad luck, I thought, so I rechecked I had done everything as indicated in the XFree86 site and reposted my bug report. Zero feedback again. I sent about eight bug reports along three months more or less, and got no answer from any XFree86 developer.
I did get mails from some people with the same problem as me, wanting to know if I had found the solution. I had tried to debug the driver myself, but I don't really had the necessary skills and experience, not to talk about the technical specifications. So there was nothing users who suffered this problem could do; we had to stay with 3.3.6.
Finally, I got some explanation from the last bug report I sent. It was from another user who was frustrated with the way XFree86 was developed. He explained that the public mailing lists I had sent my bug reports to (as I was supposed to do) were only occasionaly browsed by a couple XFree86 developers. Real communication among developers happened in private, closed mailing lists that only people with CVS access could post to or even read.
So the problem went unfixed. Some months later I upgraded my computer and forgot about this. Probably, to this day, owners of Matrox Mystiques with a certain chipset can't use XFree86 4.0.x, and I bet the maintainers of the mga driver don't even know. I couldn't tell them.
Keith Packard has been denied commit access to the XFree86 CVS for several months now. (BTW, he was responsible for making the repository publically accessible---he had a long struggle with certain XFree86 Core Team members to let him do it.) This is obviously an insane situation: he has been the principal developer (outside of 3D and drivers, although he's worked on the latter a bit) for some time now. IMHO the situation is somewhat like locking Linus out of Bitkeeper: of course he would make alternate arrangements!
In short, this is a fork in name only: the major players in the distro business have committed to work with Keith, and this is the clear successor for realistic X development. Note that this is the third such event in the history of X: the X Consortium was eventually largely dismantled and replaced by x.org, which in turn was essentially superseded by the XFree86 project. A big hope is that a charter and organization can be set up so that the governance of the new organization is democratic (ala Apache Foundation, Gnome Foundation, etc), allowing changes in governance without the need to create a new organization.
As an X developer and heavy user, I personally am looking forward to having an X repository with current bits and sensible organization.
I find it very funny that you ask:
:)
if everyone started forking the kernel, glibc, gcc, and XFree among other core packages, where would that leave us?
When this exact thing happened with GCC some time ago. Did you know that GCC 3.0 is based off a fork of GCC 2.7.2 (IIRC) which for a while was known as EGCS? But, as EGCS progressed, it quickly surpassed GCC and, eventually, was adopted as the new GCC 3.0. So, had this fork not occured, GCC wouldn't be where it is today. I'm assuming that answers your question.
I haven't talked to Keith for more than 10 years and I haven't been involved with X development for at least that long. But, I remember him from when he worked for the X consortium in the '80s and I represented a member of the consortium.
Keith has been actively working on X for longer than many X users have been alive. He knows more about the original design decisions, the history and politics, and the problems with X than just about anyone currently living. I would trust his opinion over any other member of the XFree86 "team". And, let's get the facts straight on the idea of forking the XFree86 code base. XFree86 is a fork of the original X code base. X was designed to be forked by each group that used it. That is why it is under the X license.
If Keith has concerns they are valid concerns.
Personally I think a lot of what has been going on in XFree86 is misguided. Especially the way 3D has been implemented. Not to mention that the lack of a high performance local binding for X is criminal considering that several ways to implement it have been known for at least 10 years. It was IN commercial implementations of X 10 years ago.
Stonewolf
I suspect that many of the people post here are not involved in any of the WG's anywhere. I've been involved in several of them. It's not always easy. People disagree in the WG for a variety of reasons - some technical and some not. The non techncial issues include things like financial issues (as in being employed by a major vendor), long standing friendships within the group (you are my friend therefore your ideas must be the best path), etc. My current WG is the IETF PKIX and we recently ran through and incident of threats involving custard and pie throwing. We've had a couple of other incidents that lead me to think that a split of the WG might be imminent. Much to their credit, those involved bucked up and started acting like adults with work to do. They put aside their egos, financial interests, and got to the task at hand. This doesn't seem to be possible for the XFree86 group.
People who participate in WG's do so because they are passionate. They get emotionally invested in their ideas. It's hard not to. I would imagine that any of the open source projects work in much the same way. Kicking out someone who seems have been single-handedly driving their major improvements seems foolish on the part of the XFree86 group to me. This kind of a childish knee-jerk would seem to be a sure signal that he's on the right path. It seems that he will need the latitude to explore some paths and that he wasn't getting much support from the "Core Team" in doing this.
I've taken some time to do some research on this and I would tend to agree. The current "Core Team" seems to be stuck on their own ideas. I suspect that Mike Harris feels the need to chase some of his own ideas and see if they acutally pan out into something useful. That is the best reason to fork a project. If the code base splits temporarily or permanently, then it will be for the best.
Take the long view - say 10 years. Let's play what if with the different scenarios. Will any of us care that Mike Harris stayed with XFree86 project and kept the status quo? Probably not. Will any of care if he left, created a new fork, and smoked the old project? Probably yes. Will any of care if he left, created a new fork, which produced some really good ideas that got rolled back into the main fork? Probably yes.
With the proliferation of video cards, perhaps a trade-off in favor of flexibitiy (aka more cards supported and faster driver release) would be in all of our best interests. Perhaps Linux adoption would increase if I knew that I could run the latest ATI or NVIDIA card as soon as it hit the store shelves. Card makers might be more willing to issue Linux drivers if they didn't have to reveal the inner workings of their cards in an XFree86 patch.
As more and more makes and models of video card continue to be produced, the current XFree86 design will eventually crumble under its own weight anyway. It's like me asking you for a penney today, 2 pennies tomorrow, 4 pennies the next day and continuing to raise the power of 2 each consecutive day. Pretty soon you can't afford to pay me. You cannot continue to add every driver for every card every made as a "patch" the product.
My 2 cents,
Queen BHDGary secures my bank
Both KGI and GGI are alive and kicking at the moment. KGI, the Kernel Graphics Interface is almost rewritten from scratch, and GGI the user level library is developping very well.
Please click the links for more info.
Wow, so that's the end of Linux then, is it? Microsoft won in the end. Who'd have thought it?
What nonsense! This is Open Source. KP can create a fork if he wishes. Eventually, either his version will win out, or the original XFree86 will win out, or both will prove to be successful projects, or they'll find some rapprochement and re-merge the projects.
It turns out that it doesn't really matter. The net result will be that in 2004, there will be a better X for Linux than in 2003. And in 2005 X on Linux will be still better. Had there been no fork, the same would have happened. This is just how Open Source / Free Software works.
Reality is defined by the maddest person in the room
Lots of whiners will immediatly say "but that will allow window borders to be (horrors) INCONSISTENT and that will CONFUSE the poor stupid users!". To that ancient "inconsistent" argument I say it is totall BS and I challenge anybody to find a real user who is "confused" by the difference between a KDE and Gnome button or menu.
The biggest thing you said that almost everybody else suggesting alternatives ignores is that an Xlib compatability library is needed.[...]
...). Developers can choose the level of abstraction that matches their need. Why should they care wether the Kit is loaded into the server or linked to the client?
I fully agree that Xlib compatibility is very important, but that can't be the driving factor in a project that wants to replace X. Such an evolutionary approach is far better handled by extending X than by writting an replacement IMHO.
Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected.
What makes you say it is a bad idea? We are not fixing the look nor feel of any object created, we just define a set of very generic interfaces to request certain kinds of objects (Buttons, lines, text,
First of all it makes it absolutely impossible to write such an emulation layer.
That's wrong.
Also despite claims to the contrary, it actually *increases* the amount of communication Why? Because widgets quickly grow complicated with many many cofiguration options and it gets COMPLICATED.
I absolutly fail to see your point.
You create a tree of graphic-objects that describe the look and feel of your application once. Afterwards there is NO communication between client and server anymore till the applciation updates its look or the user causes a change in the client's state. Usually not even events leave the server!
We tried remote-displaying our demo. Via Fresco the communication needed 1.9kBit/s (alive pings) after an initial burst to create all the necessary graphics, even while moving/resizing/scaling/... the windows. Doing the same using VNC to export the same demo at the same color depth and using the same screen-size up to 800kBit/s were used when doing those operations. We allow that factor of ~400 for unforseen complications;-)
You should further notice that individual graphics do not get complicated. Complex things are build up out of a couple of simpler graphics. This is *very* different from how both GTK and QT work and way more easy once you get used to thinking in terms of small building blocks.
Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.
Yes, we are incompatible for now. Nobody is working on an Xlib emulation layer. It can be added and it will be added once Fresco becomes stable enough to hold its own. Nobody can use Fresco for serious work yet, so nobody will miss X compatibility. We'd still have to keep updating the code to keep in sync with the rest of Fresco, thus draining resources that can be put to far better use elsewhere, Doing such an emulation layer now would do more harm than good.
Regards, Tobias
I saw this link on OSNews and thought it should be reposted here. This is a member of the XFree BOD giving more information on why Keith was expelled and a discussion of how X is governed (i.e. the distinction between BOD and Core). He also argues for LSB taking a much larger role with respect to X (I can't help but think that BSD, Solaris, etc.. would object to that).
OTOH YMMV as far as this attack since there is no discussion of what specifically are the issues leading to the fork and rather vague comments about "corporate interests".
Finally KeithP put out his response .