Hi, all!
I'm starting on trying to get as many HTTP issues resolved as I can
before Libevent 2.0.x-stable comes out. (My current target there is
mid-November, pending any tricky bugs that people find in 2.0.8-rc.)
But as I've noted before, I am not as familiar with evhttp as I am
with the rest of the parts of Libevent that I've been maintaining.
Niels is the evhttp guru, but Niels is hosed with work, so I'm trying
to come up to speed as well as I can so I can merge patches and fix
bugs.
Nevertheless, I also am pretty busy with my day job, and I won't be
able to fix every single pending issue without help. So right now, the
best possible way for a change to get into Libevent 2.0.9-x is for it
to have as many of the following properties as possible:
* It fixes an actual bug, or implements a feature that is necessary
for using evhttp sanely.
* Somebody has already written a patch for it that applies cleanly
against the master branch.
* The bug and/or patch has an entry on the bugtracker/patchtracker. [1]
* There is a unit-test for the failing case, or --failing that-- a
*short* test program requiring no external tools I haven't got
installed, or --at the very least!-- simple, easy-to-follow
instructions to reproduce the bug at issue.
* Where there is a standards-conformance issue, there are references
to the relevant parts of the relevant standards.
For issues that miss one or two of those criteria, I'm going to _try_
to do something useful. For issues that meet almost none, I'm going to
see what I can do, but that might be fairly little.
Thus, if you've got an evhttp issue you really want fixed or an evhttp
patch you really want applied, you can improve its odds of getting
resolved by doing as many of the following as possible:
* Have a look at the trackers [1] and make sure there's an entry for
it. If you just sent an email to the list a few months ago, don't
assume that it's still in my to-do box.
* (Remember to "monitor" the issue on sourceforge, so you get an
email notification if somebody comments on it, asks you about a
possible fix, etc)
* If there's a standards-conformance issue, find where the correct
behavior is documented, and make sure the tracker entry says what that
behavior is. (e.g., "RFC 3986, Appendix A".)
* If there's a bug, try to come up with the simplest way to
demonstrate it. That could be:
* A short C program, using Libevent or not.
* A new unit test for Libevent.
* A short program in your other favorite language, assuming that
the libraries you're using are fairly ubiquitous.
* Simple shell instructions, using telnet or netcat or some
ubiquitous tool.
If the desired behavior of your test program isn't totally
obvious[2], please try to explain what it should be.
* If there's a patch, make sure it applies to git master. If there
isn't, and you think you could write one, that would be great.
[1] The trackers are at https://sourceforge.net/tracker/?group_id=50884 .
[2] Please act like I'm extremely clueless when you're deciding what
ought to be obvious.
yrs,
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majord...@freehaven.net with
unsubscribe libevent-users in the body.
