httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: I'd like to make some contributions
Date Thu, 17 Jun 2004 20:17:42 GMT
At 09:12 AM 6/17/2004, Joshua Slive wrote:

>On Thu, 17 Jun 2004, Guernsey, Byron (GE Consumer & Industrial) wrote:
>
>>Don't expect a quick response.  I submitted a feature patch to bugzilla over a month
ago and it hasn't changed state from its "new" state or had any activity or ownership changes.
 I posted a followup message here a few weeks later and have not received a single response.
 I continue to read messages here to see if this process described in the below URL actually
works or if I just need to maintain separate patches for the version we use at GE indefinitely-
something I don't want to do...
>
>>        Details how code patches should be submitted are described at
>>        http://httpd.apache.org/dev/patches.html
>
>Perhaps this page needs a section entitled "What to do if my patch gets ignored".  It
could go something like this:
>
>Because Apache has only a small number of volunteer developers, and these developers are
often very busy, it is possible that your patch will not receive any immediate feedback. 
Here are some suggestions on what you can do in this case:
>
>1. Encourage other Apache users to review and test your patch, and then append a note
to the bug report with the details.  Developers are much more likely to review and commit
a patch if they see that it has been widely tested.
>
>2. Post to the developers list with the bug number included as specified above, pointing
out your patch and why you feel it is important.  Feel free to do this about once a week and
continue until you get a response. Just be sure to be polite about it, since the developers
are unlikely to respond to rude messages.

Don't forget the number #1 way to gain brownie points to get your patch
or complaint reviewed;

3. Review the bugs database for similar errors.  If there are duplicates, close
them as duplicates of the initial report (this cross references the two bugs
to each other.)  Add an extra note when closing well documented dups that
the particular bug report contains useful unique details.  If there is a report
that isn't identical, but might be helped by your patch, mark it as 'depends on'
the bug report containing your patch.  Finally mark the original incident as
'depends on' your bug report, with patch.

4. If you have free cycles in the process, feel free to address other bug
reports you can politely and correctly address.  As ugly as this job is, 
sort of like the poop crew following a parade, it leaves the principal 
committers with time to address the real bugs and their solutions instead 
of sweeping up the droppings.

And also remember that holidays (not necessarily your nation's), vacations 
and even the release cycles of other projects will affect how focused the
majority of the committers are at any given time, along with things like
security issues that are addressed often 'behind the scenes'.  (We try to
keep absolutely as much of the development process open, and on this
list for open participation.)



Mime
View raw message