At 12:54 PM 3/4/2003, Chris Monson wrote: >I have been starting to make attempts to contribute to this project. >In so doing, I have discovered that I have a lot of questions. I tried to >get the list FAQ, but it said it was empty, so please forgive me if this > information is located elsewhere. I will happily take any pointers to > documentation instead of responses to my questions.
:-) That listserv query should at least point users to a page ... sorry. >I submitted a patch to allow for an IPLookups directive last week, got >some feedback, and have submitted a new patch. My question is this: >when does a patch become "golden"? Is there a BDFL for Apache like >there is for Python and Linux? I ask this not because I really want my >patch to get in (although that would be cool, I really want what's best for >the project) but because I am curious. No, we don't share the concept of any omnibudsman. Every committer and project management committee (PMC) member shares responsibility for reviewing the patches that overlap their areas of wisdom. We do have the concept of a release manager, but that's more specific to creating a release, and they generally accept the entire current stable tree when they package one (fixing only small flub-ups that might occur due to timing of the newest patches). Patches to Apache 1.3 are contemplated very seriously, that is an old and venerated code base that is complex and easy to tickle into bad behavior on this platform or that. Many people "trust in 1.3" so we try to make as few changes as possible to preserve that stability. Earlier versions no longer accept any revisions whatsoever, they are no longer maintained. Patches to Apache 2.0 usually go through the process of our Apache 2.1-dev branch first. That's the 'sandbox' where we can get things right before possibly polluting the next stable Apache 2.0 release. Many patches aren't suited for Apache 2.0 (we are trying to preserve binary compatibility between releases so that 3rd party module users aren't playing catch-up between the other parties' releases and ours.) Someday in the next months we will decide that Apache 2.1-dev has enough very "useful features and improvements" and begin the process of releasing Apache 2.0. >Also, when posting issues, like a previous post of mine about a possible >infinite loop in mod_proxy, what is the best way to go about it? Pretty much exactly as you've done :-) Sorry that I personally haven't responded, but I'm not much of a 'proxy guy' - although we have several that monitor this list and will chime in. >I see that tools like gdb and strace are favored, and I am learning to use them with >Apache, but I am admittedly a novice in this area. I don't want to piss people off, >but I do want to find out how to go about finding and fixing Apache issues. One of the best ways to do so is to check out the httpd-test repository, and look at the perl-framework. If your patch passes those regressions (and you mention it) that is a definite plus. The really strong argument is writing a test that reproduces the crash/protocol violation/ugly behavior and demonstrating through perl-framework that your patch corrects it :-) >Sometimes something is easily reproduced and would be better addressed >by someone familiar with this process (rather than waiting for me to bungle it). >On some mailing lists, accomplishing both goals simultaneously is something >of a balancing act. This list feels fairly tame, however, so I guess I'm just > asking whether that impression is correct. We are told we are intimidating, but don't believe that. We are also told we are slow to review patches (a belief which you are free to entertain.) Just remember (like most projects) we are volunteers with limited time, and even those most active have many, many priorities to juggle. Just remember to ping the list once a week if we are ignoring you, it's not deliberate rudeness on our part, we just get busy. If you see your bug pop up in bugzilla, be sure to include a link to your patch, more eyeballs are always good and if your patch closes a bug, then we have more input to go on committing that patch. Thanks for your patch, someone feel free to steal bits of this response to add to http://httpd.apache.org/dev/patches.html (the link you were looking for) and answer [EMAIL PROTECTED] with a link to http://httpd.apache.org/dev/ Bill
