Diary for mharris
Older diary entries for mharris (starting at number 6):
11 Jan 2003 »Wow, I didn't realize that many people actually read advogato.org diary entries. ;o) I figured a handful of people would read my last entry and offer a few comments etc. however I received over 100 emails, as well as numerous /msg's in IRC from various people.
I was quite surprised that every single one of the emails was completely encouraging and positive. Not one single negative comment in over 100 emails! Mind boggling. I guess I just happened to put into words what a rather large number of people have been thinking for quite some time now, at least according to the plethora of feedback I received.
One thing that is very very aparent from the feedback I got, is that the community very much wants to be able to communicate openly with X developers. People want to be heard, and they want to be able to learn more about X development in general. Many people expressed an interest in getting involved in XFree86 development but just had no idea where to start, and in their prior efforts at trying to learn something, or to hack on a given part of the X server, or somesuch, were extremely disappointed at being unable to get anyone to respond on public forums.
Another overwhelming thing people commented on, is that they have reported bugs to the email@example.com list before, which were well detailed, and not gotten any response back. They were not acknowledged, they had no idea if anyone ever looked at the problem, and they had no idea if the problem was fixed already, or if it would ever be fixed, or how to tell in either case. This drives home the need for bugzilla.
Some of the XFree86.org developers are of the mindset that a bug tracking database will do nothing more than consume their time, time they could be spending working on X. Some believe that such a bug tracking database would only make things easier for distribution vendors, as people would file bug reports to XFree86.org instead of their distribution vendor. And they forsee bug database maintenance being an overwhelming task that just wouldn't work.
Well, considering the extreme majority of bugs that get reported are not distribution specific, and ARE generic XFree86 bugs, why SHOULDN'T they be reported to a central bug tracking database viewable by all? Bugs can be easily cross referenced to distro specific bug databases as is done in many other projects that are successfully running right now like GNOME and KDE for example. GNOME, KDE, and other large projects have very well ran bug tracking databases, and the developers would not dream of giving up this wonderful tool.
Tell me - how many projects the size of XFree86 do not have some form of bug tracking database? How many projects the size of XFree86 do not have some kind of project management? How many projects the size of XFree86 do not have development communities built up around them where the developers work with other people in the community, and try to harness new developers to contribute to the code?
GNOME is huge. KDE is huge. Both of these projects could probably not function well at all if all they had was an incoming email address that wasn't publically viewable where bug reports were submitted.
Also, I don't know how accurate this is, but last night, I was told that these projects have several *hundred* developers whom have CVS write access. The general rule is that you follow the CVS rules, and if you screw up, your CVS write priveledges are suspended temporarily for a period of time. If someone screws up in a huge big bad way, then their priveledges are suspended for longer. It was news to me, but it certainly seems to work for them.
One way or another, X11 needs a publically available, real world bug tracking database that the community can use, even if zero of the developers use it who think it is a useless waste of time. Lord knows how that will happen, but it is IMHO something dreadfully needed.
Another thing that annoys the hell out of me, is there always seems to be an aire of politicalness that lays over X development. Instead of being a contributing X developer, I sometimes feel like I'm treated negatively by some people simply because I work at Red Hat, like that somehow should make any difference.
I sometimes wonder if I were to create a firstname.lastname@example.org address and communicate with that if I'd get treated differently by some people. Mind you, this doesn't occur all the time, and certainly not by everyone. It does happen occasionally though, and when it does, it frustrates the hell out of me. I look at X development completely outside the walls of my position at Red Hat. I think of myself as mharris the person interested in doing open source X development, and not as mharris the person forced to work on X development as an employee of Red Hat as a work duty.
I work on open source software because I enjoy working on open source software, and I always will. I work on X for the same reason. It's just my employment at Red Hat that got me started working on X in the first place. I like my job greatly, because it lets me do something I enjoy doing, not because I HAVE to do it. Why must people put up these walls and boundaries? It's senseless. We're all open source developers, and I at least, for one, don't care if another developer is using Red Hat Linux, Debian, Mandrake, FreeBSD, or whatever. Who cares? Why create barriers and refuse to help someone or to listen to them because of their distro of choice, or their employer? Childish.
Anyway, the good side of things is that I see some of this wall coming down now, and have talked with several other developers of whom use other OSs or work for some other company, or whatever, and there seems to be a consensus that people want to work together.
I think in our quest to produce open source software, we have more in common than we have in difference, and that the more we communicate _with_ each other, the more that can be accomplished.
In closing, I'd like to make one more comment. Aparently, after my last entry, people discussed it on the xpert/xfree86 mailing list. Despite being subscribed to the list on 2 separate email addresses, I haven't received mail from xpert list since Dec 17, 2002, and so I completely didn't see any messages on the topic posted there, and so I haven't been able to respond to whatever discussions occured. I have subscribed to the list under a third address now, and am receiving email@example.com once again now. I certainly look forward to hopefully positive minded discussions about these topics on the list, and towards future open source / free software collaboration with everyone in the community who feels like doing so. And of course, regardless of what OS or distribution they use.
And finally - thanks to the hundreds of people for all of your supportive emails! It's very encouraging!
9 Jan 2003 »Seems like I don't create diary entries too often. Well, I wont try to lie about it and make excuses. Diaries, journals, etc. have never really been my thing I guess. Many people have bugged me to start updating my journal here though, so I figured I would break down and try to start updating it.
Been spending a lot of time lately split between reading tonnes of video hardware documentation, standards, and other technical documentation, as well as the usual XFree86 hacking.
I am considering lately releasing my own Radeon driver that is separate from the XFree86 project's driver. There is just way too much time that lapses between the time someone submits a patch to XFree86.org and the time that it gets reviewed by someone and applied to XFree86 source code base - a priveledge that only around 14 people have, and of which about 6-8 use on any regular or semi-regular basis.
ATI submitted open source patches for the Radeon 9500 hardware about the time it was released. That was many many months ago. That patch still hasn't been integrated into XFree86 CVS, and as time goes on, I am thinking it is very likely not going to get integrated into 4.3.0 either. Just yesterday, ATI sent me 2 or 3 more patches that build upon the last patch they submitted which wasn't applied. How long is ATI going to continue submitting patches to XFree86.org that take 9 months to get into CVS, and then perhaps another 4-6 months to be available in an OS distribution? Quite frankly, if I were ATI, and submitting patches as frequently as they do, and the patches just sat there, I might start thinking twice about bothering in the future.
So, where does this leave things? Well currently, it leaves the latest XFree86 CVS radeon driver missing Radeon 9500 support, and a few other bug fixes and enhancements from the first ATI patch. It also leaves it missing various other fixes, etc. from the newest 2-3 ATI patches that are supposed to apply on top of that. Also, I have written a patch to add support for some FireGL 8700/8800 hardware, and some Radeon 8500 hardware that was previously unsupported. I haven't sent my patch upstream yet, as it is obvious to me it won't get applied, at least not anytime soon, so why bother? Until they commit ATI's patches, there is no point submitting further patches. Also, there is a number of other Radeon driver features I would like to work on, and get them out into the hands of actual real users sooner rather than later. If you submit a patch though for something, and sit and wait 6-9 months before someone on the inner circle has time to volunteer to review it, commit it into the repository, or reject it with given reasons (or silently), you get discouraged rather easily.
After thinking about this for a while, and also thinking about our upcoming Red Hat Linux release, I decided that I don't NEED to wait for the various things to be incorporated into CVS. I receive a copy of ATI's patches as well, and am more than capable of integrating them myself into the driver base. And, as an added bonus, I *DO* have the time, or I will _make_ the time. I'll be doing this work this week hopefully, and will put up a new web page somewhere where people can download the driver source code and also binary drivers to try. I will do my best to support the drivers as well, and I plan on also trying to get the code into XFree86 sources upstream too over time, but that wont however be my priority.
When people bitch and whine on the XFree86 mailing lists, or email an XFree86 core team member to ask why some patch that was sent in has not gotten applied yet, the general response is that "There are only a certain number of developers available, of whom are working on XFree86 on a voluntary basis, and there is quite a bit of work to do. The patch will be reviewed in time, and probably applied before the next XFree86 release.", or something to that effect. In other words, there is a shortage of volunteer man hours in the project with which to get work done. However, on the same note, no new developers are ever given CVS write access to the CVS repository, not even a small portion, such as a single X driver. So basically patches sit there and rot until someone "gets around to it". XFree86 development is just not scalable.
What is worse (IMHO), is that recently, they have removed the link to their developer page from the website. At least I am unable to find the link to the developer page anywhere on their web site. If you type in the URL manually however, the page is still there. It can be seen at: http://www.xfree86.org/developer.html. You'll notice at the bottom of the page there is a section "How to become an XFree86 developer." and it says:
How to Become an XFree86 Developer
We are no longer accepting applications at this time.
I've no idea of their reasoning behind that decision, however it concerns me greatly. Granted, many people apply for XFree86.org membership, submit a simple patch, are accepted, and then do little or nothing after that, so from that angle, I can understand their position to not accept more developers. On the other hand, more developers are needed IMHO. Do people really need to be "accepted" as an X developer first in order to contribute? Well, it might help a bit, but it is not really necessary. Most of the NDA information available to member developers is largely out of date, and new NDA docs haven't been forthcoming for quite a while since companies that do give docs out, tend to do so on a person by person basis now rather than to a single entity like XFree86.org.
So, where does this leave everything? I really don't know. I would like nothing more than to see the XFree86 project thrive, and also to see more capable and willing people contributing to the code. I'd like to see a community of development around X11 like that of the Linux kernel, and I'd like to see people openly discussing developmental issues in an open forum not unlike the linux-kernel mailing list. That type of a developer community has just never formed around XFree86 however, and I have no idea why.
The XFree86 development team has a number of very talented people working on each release, mostly voluntarily, but like any developer, they can only accomplish so much work in a finite amount of time. XFree86 development doesn't really seem to scale to well. The more people who might try to contribute, might have to wait a long time for one of the core members to even look at their code, comment on it, accept/reject it, etc. I think most people just give up before getting too involved, simply due to the lack of close and open communication between all developers. I know many developers who have commented that to me at least.
I've talking a bit with a few other Linux and BSD distribution XFree86 maintainers lately, and they've shown an interest in collaborating on sharing patches more closely and directly, and on working closer together as well. I'm hoping we can form a closer development community that is very open and be able to help each other, and not duplicate efforts as much as is done now. XFree86 does NOT have a bugzilla or similar bug tracking database. Instead, bug reports are sent to an email address (firstname.lastname@example.org) which someone might or might not ever actually read. Many people think of this bug report address as a blackhole, or a /dev/null alias. In many cases, I believe they are right.
Since there is no way to "track" a bug through various stages, through resolution, many bugs, and likely many fixes also just fall through the cracks. Since XFree86.org doesn't really have any way for various distributions to share patches efficiently, or to keep track of the status of an issue, or to even find out if a bug has been fixed or not, and if so, if it is in CVS or not, distribution development tends to needlessly end up with each vendor/distro doing a lot of duplication.
I would like to bring all XFree86 package maintainers, and developers together collaboratively somehow in order to track issues, share patches, and reduce duplication of effort as much as possible, and also to feed things back to XFree86.org in a manner that is useful to them, and preferably also cuts down on the amount of work that they need to do in order to incorporate changes, bugfixes, etc.
Another thing that is a problem, is that once a new release of XFree86 comes out, the older releases are more or less completely abandoned after a short while. Even if you send in a bugfix patch for an older release, with patches for the various new releases as well, usually only the newest release or head of CVS gets the bug fix. In some cases someone will commit the fix to an older release as well, however that is not usually the case. It is understandable with a fixed number of vulunteer core developers, that maintaining code for several years for every release of the codebase is a huge task, however many distributions and vendors MUST support the XFree86 releases they've shipped for a certain amount of time, and in many cases can NOT upgrade the given distro release to a new XFree86 release on a whim, due to various customer commitments, or simply due to regression of certain features/drivers in newer releases. There needs to be a more long term way for others to get involved in the maintenance of XFree86 releases that the core team is not interested in maintaining any more, or simply do not have the volunteer time to spend doing so. I would like to discuss this issue with XFree86.org, and with other distribution maintainers also.
All in all, I would like to see XFree86 development increase rather than decrease, by helping other developers, and by getting more people interested in being developers in the first place. I'd also like to contribute a lot more to the project than I do now, and to help remove duplication of effort.
I also realize that XFree86.org does not have the manpower or volunteer time to necessarily contribute to these ideas as they already have their hands quite full. So by helping to organize external community projects that do not make demands upon XFree86.org members, I think many of us developers can accomplish a lot of work on our own, which we can then submit to XFree86.org at intervals that are more convenient for them, rather than things sitting in patch queues for months on end, awaiting volunteer time.
Anyhow, this is a rather long entry, comprised of various thoughts that have been on my mind for quite some time. Many thoughts of which people have ignored that I've mentioned things too, or have refused to comment on for whatever their reasons. Perhaps I should be more proactive with my ideas and see where it leads. I'll start with the Radeon driver and see where that goes...
10 Jul 2002 »Been a while since I updated...
I just got back from OLS a day or so ago. OLS was a blast. Don't be fooled! OLS is not a Linux Symposium, it is an alcoholic symposium! Sure, there were Linux presentations, BOF sessions, and other Linux related things going on, but that is just a front for the REAL reason OLS exists - to get piss drunk!
Alan and Telsa shared their hotel suite with me during the symposium, and we imbibed in many different spirits during the 6 day drink fest that endured. ;o) One thing that prevails in Ottawa, is bars and pubs. I've never seen a town anywhere that has street after street of fine drinking establishments. I now understand why the Symposium is held in Ottawa. ;o)
After Canada day, I visited an old drinking buddy Richard in Ottawa and partied for a few days with him and other friends. After Ottawa I went to Toronto for the remainder of the week. I walked around Toronto for several days until my feet fell off. I am still recovering from the blisters.
While in Ottawa and Toronto, I finally got a chance to work on my music collection of the bands "Annihilator", "Dream Theatre", "Symphony X", and "Rhapsody". I'm only missing one DT album now, one Annihilator, a few Symphony X CD's, and am just beginning my Rhapsody collection. $600 worth of music. I'm afraid to look at my VISA bill for the whole OLS/Ottawa/Toronto rendezvous as it will likely be quite scary. Oh well, I had a great vacation, so it was worth it. Might as well enjoy things while I'm here, as I can't take it with me when I go right? ;o)
I'll be posting my OLS pictures somewhere on http://people.redhat.com/mharris/ once I pick up a CF reader soon. Now that I'm back, it is time to catch up on email and bug reports.
11 Mar 2002 (updated 11 Mar 2002) »Been hacking on XFree86 Imakefiles trying to get parallel make to work once again. In the 4.1.0 timeframe, rebuilding the X rpm's took 40 minutes on my machine. 4.2.0 should not take any longer, especially considering XIE and PEX are both no longer built, and Glide3 is a separate rpm once again. Nonetheless, it takes 50minutes now and drives me nuts. Glide3 takes at least 11 minutes to build, and PEX/XIE must take about 5-10 minutes, so I would expect to now have XFree86 4.2.0 rpms buildingf in abour 20-25 minutes with parallel make. These Imakefiles are damn scary shit however.
You're in a twisty maze of deeply nested heirarchial directories. There are Imakefiles in all directions. Beware you do not become eaten by a grue.
1 Mar 2002 (updated 1 Mar 2002) »For a while I've been wanting to experiment with the AMD x86-64 technology. I've been deeply interested in it since it was publically announced back in 1999. With the various CPU architectures that currently abound, as well as the new ones coming out, it is interesting to compare them feature-wise, performance-wise, and sanity-wise.
Having now used various Intel ia64 machines, I am completely unsatisfied with the slow kludgyness, and personally am convinced that ia64 does not show much promise for the future at all, at least not in its current state. "Take three swings, then go sit down."
On the other hand, AMD's x86-64 Hammer processor I believe will be the next logical step in the evolution of the modern deskop PC, not to mention servers, and high end workstations as well.
The Hammer processor, being a clean 64bit extension to the existing Intel ia32 architecture, breathes new life into the aging legacy of Intel dominated computerland.
Being as interested in x86-64 as I am, I decided last night to finally download the Simnow Hammer processor simulator from the above URL, and give it a whirl. My goal was merely to get it to boot up a standard 32bit x86 kernel and get into userland. After a few bumps I had from misreading the fairly poor documentation, I got it up and going, and booted a boot disk I had laying around. While it was an interesting experience in a small sort of way, it was more of a computer-geek-with-a-new-toy thing than it turned out to be actually useful. My test system is a dual 1Ghz P-III Xeon with 1Gb of RAM. The simulator took about an hour just to post the BIOS, which was quite disappointing. It took another hour for it to get to the point of decompressing the kernel. Then it got to the Bogomips calculation and sat there for another hour or so. Finally it started initializing the kernel, and then eventually completely died with a kernel panic.
While the experience did fail, it was worthwhile enough to conclude one thing: Simnow is totally useless from any practical standpoint. I could watch the instruction pointer increasing, and almost count faster myself. So basically, dont expect simnow to be useable for any real usage other than watching the registers move, and experimenting with them.
The next logical step was to download the cross compilation utilities, and install them. I'd like to begin building rpm packages at some point, and you need to start somewhere. Ideally I would like to obtain a copy of the Simics simulator from AMD under license and/or real prototype hardware, but for now, I'll suffer with crosscompilers. ;o)
28 Feb 2002 »Banged on Mesa again today, and also fussed around with a SEGV in xkbcomp which caused my XFree86 build to die. Dang untrustworthy computers, always getting in the way. of getting work done.
Why doesn't XFree86 3.3.6 just die? I mean really? If you've got a video card from 1993, er.. time for an upgrade. "But it works, and I shouldnt have to upgrade." Well, whatever. Developers splitting their work time between maintaining 80 different versions of XFree86, just so everyone can be happy, means that MUCH less time is spent working on the current technology, which means a longer time period of lag-behind-Microsoft in Linux land.
Sure, not all hardware supported by 3.3.6 is supported in 4.x, however, if distributions continue to ship 3.3.6 forever, there is zero incentive for any developers out there to port existing 3.3.6 drivers to 4.x infrastructure because "it works now already".
If anything, by distros dropping 3.3.6 support sooner, (which is no longer actively maintained upstream I might add), developers have more time to make 4.x better, and not have to worry about coexistance issues, upgrade issues, and many other complexities.
Hardware that isnt supported in 4.x will be much more voiced and known, and the statistics gathered from this process can be used to decide exactly what video drivers are still widely needed that are not part of 4.x yet.
I dunno about other X developers, but I would rather spend time porting a 3.3.6 driver to 4.x infrastructure than continuously have to deal with all of the issues that one must deal with to endlessly support XFree86 3.3.6, Mesa OpenGL software renderer being the primary major annoyance.
There. I feel better now getting that nugget off my chest. ;o)
Now, back to my regularly scheduled coredump analysis.
27 Feb 2002 »Wow, I've had an Advogato account all this time, and only now have I gotten off my arse and posted a diary entry. ;o)
Today I hacked on Mesa fakeglx a fair bit, trying to backport it from Mesa 4.0.1 to Mesa 3.4.2, so that XFree86 4.2.0 libGL will work with XFree86 3.3.6 servers. Lots of fun.
[ Home | Articles | Account | People | Projects ]