On Sat, 11 Jan 2003, David Dawes wrote: >>There are allot of interesting comments here by Mike, particularly his >>interest in forking XFree86 and creating his own work. At least I think >>interesting....and BTW doesn't the ATI maintainer work for Redhat? > >Definitely interesting. > >One main point I would like to answer now is the issue of the developer >page on the web site. New membership was basically closed down temporarily >while the whole membership/developer situation was being reviewed. > >After this message goes out, [EMAIL PROTECTED] will be converted to >a public mailman list -- so if you want to subscribe, go to >http://www.xfree86.org/mailman/listinfo/devel/ > >In the interests of openness, there won't be any private list to replace >it, and the whole issue of joining XFree86 as a developer will be moot.
David, this is wonderful news. I'm very pleased to see this change happen. I've wondered for a long time why the private devel list was private, considering almost if not all of the discussions that have taken place on it in all the time I've been on it have not really been something that private. I hope that the XFree86 core team members will continue to use the list now for the same purposes it has been used in the past. By active participation between existing core team members, other existing member developers, and also new potential developers, it may be possible to create a lot more people interested in contributing to the project. So this is very good news. >BTW, as far as bug tracking goes, there's nothing stopping >anyone setting up and maintaining a bug tracking system on >behalf of XFree86. You really have to understand that forcing >volunteers to do anything is impossible though, so the >effectiveness of such a system is something that will only be >discovered by doing it. That's always been understood. I would not want someone to try and force me to use something any more than one of you developers on the core team would want someone else to try and force you. We all of course volunteer our time to work on things that we personally feel like working on, and part of that is having control of how our own time is spent. It would be wrong for anyone to try to force a developer to use bugzilla against his/her will, and would potentially be insulting. >As far as commit access goes, frankly, if those asking for it >could establish a record of submitting complete and correct >patches that didn't need review (and Mike, your record on this >isn't anything to boast about), then you might have a better >shot at it. Well David, out of all of the patches I've submitted to XFree86.org that I've written personally myself, the percentage of them that were applied to CVS is pretty high, and almost all of those without any modification or with minor formatting modifications, or a some other similar very trivial change. When patches are committed, before I drop them, I manually examine each diff line by line in order to see if the patch was applied without modification or not, and to ensure it was done correctly without things getting lost. I also do this detailed patch drop review in order to try and understand any modifications that have been made to a patch - to learn of course. In the past I have also submitted various patches found on mailing lists, and things people have sent me that fixed something for them. A great deal of said patches I merely passed along upstream in hopes that they might be useful to the project after someone did a good code review. This was somewhat of a mistake of course, as I had no idea what was expected, and found out quite some time later that my processes and procedures for submitting patches was not entirely the best. As you'll recall, as soon as this was brought to my attention, I emailed you directly and asked you what you expected in patches, and what you expected to accompany them, etc. I immediately modified my methods, and since then, most of the patches I've submitted have been of my own writing, or have been much more closely scrutinized. Also, if I can't vouch for a patch's correctness, I tend to get the person who wrote it to submit it instead, be they some random person off the net, some other X developer, or some other Red Hat developer. I've refused TONNES of patches sent to me, and have referred numerous people to submit things directly to [EMAIL PROTECTED] I've also refused to apply things until they hit CVS so that I'm guaranteed that all people who use XFree86 benefit from a patch, and not just Red Hat users. Other patches I've submitted include various i18n stuff, some written by other people at Red Hat, and some of it which was code developed by someone off the net, bounced from distro to distro to distro and ended up at us, having no idea who originally wrote it, and having no familiarity with the area of code it touched, but being told that "it fixes Chinese" or similar with no way for me to be able to confirm that - as I'm not Chinese. In these cases, I've passed the code upstream to XFree86.org, as I assume someone there _is_ able to look at such patches and decide if they're crap or not. And I haven't been let down for the most part, because if something is crap, it usually gets rejected, and while not always - it is usually rejected with an explanation, and such rejections are appreciated. However, due to fault of my own, I'll be the first to admit that I have not had a great track record for patches of unknown origin in attempting to find out who wrote them, or even to indicate wether I consider the patch good or not. If I could go back and resubmit a lot of patches, I would probably add to a lot of them things like: "I didn't write this, and don't know who did. I was told it fixes xyz, but haven't personally confirmed that. I applied it for a test build and it's been in beta testing for x days/weeks, and user feedback claims it fixes the problem. Since I am not able to verify the code quality, please review this for possible inclusion, and let me know if it is garbage." If I had been told I was doing something wrong much earlier, I probably would have began to change the way I was doing things. Until one is told they're doing something wrong however, or starts to think it themselves, if they aren't aware of the issue, they will probably continue to do it. This doesn't mean that I've never written a bad patch and sent it in, or gotten something wrong the first time however. Have you? Has anyone? I doubt it. There aren't that many people who _see_ my patches when they're submitted. I'd certainly be interested in more than one single person doing peer review on patches I submit, and then making comments publically about my capabilities without any way for anyone public to confirm or deny such claims. I think in the future, I might just post patches here on the devel list first to get wider peer review before submitting to the patch queue. That is how the Linux kernel development mailing list works, and it seems to work very good. I very much want to know if something I've written is bad, or has a mistake in it, and I'd like to see peer review on a public list, one where if you screw up 200 people point it out, not just one person. So please, point out my faults. My ears are open, and my desire is great to correct them, and do so in front of my peers. I'm sure other developers who submit patches would also like to have public feedback on what is wrong with them, and to let other developers comment on them too. I eagerly look forward to such open development process. -- Mike A. Harris _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
