Le 27/10/2015 17:27, Jacob Champion a écrit :
>
>> The most exciting work on httpd for me has been Christophe Jaillet’s
>> memory optimisation patches. With each patch the code gets cleaner
>> and the server gets faster. We need more of this kind of stuff.
>
> How would you improve the process and encourage those sorts of
patches, then, from someone who _isn't_ in the httpd committers list? It
seems to me that optimization needs to be done by experts in a codebase,
not by newbies. And code cleanup is difficult when you don't already
have a clear direction to push the code in.
>
> --Jacob
>
Hi,
I understand your point.
Personally, when I first looked at httpd, it was more or less in the same
spirit as what is done on the kernel Janitor project. This project is aimed
at cleaning and fixing potential issues in Linux kernel.
So I started looking at what could, according to me, be improved in httpd.
Not an easy task when, as you say, you don't have any direction to push.
To give you some ideas of what can be looked at easily by new comers:
EASY
====
- Fix coding style issue: [1]
(even if I don't really think that the 'indent' command line given
there
is that good. It generates way too much changes)
--> See http://svn.apache.org/r1700332
- Identify where standard C functions or apr_ or ap_ functions can
be used
in order to remove code duplication.
If familiar with it, 'coccinelle' can be used for that.
--> See PR 39518 or 42006 as some examples
- Speedup/cleanup code
--> See http://svn.apache.org/r1701717
- Some parts of the server generate some HTML pages (in
modules/generators,
mod_proxy_balancer...). The generated output does not always
comply with
the HTML standard and could be clean-up.
--> See http://marc.info/?l=apache-httpd-dev&m=142593723110939&w=2
- Improve existing documentation [2]
- Improve (or sometimes fix) code documentation generated with doxygen
- Look at comments added by users in the online documentation and
propose
patches to take these comments into account
MEDIUM
======
- Identify and improve memory usage. For that, you must first know and
understand the way APR memory pools work.
--> see PR 52648 or http://svn.apache.org/r1681685
- Identify places where 'varbuf' could be used to improve memory usage
- Fix compilation warning (if any)
- Use and fix items reported by static analyzer such as cpp_check or
sparse
- Check bug reports in bugzilla, try to reproduce the issues, try the
(sometimes) proposed patch. Mark bug reports with the 'PatchAvailable'
keyword when it is missing
- Look at differences between trunk and 2.4.x branch to identify and
propose
what can be backported. The closer they are, the easier it will be to
backport other proposals
HARD
====
- Write tests to add in the test framework [3]
It could also be a good idea to tag some bugzilla reports with something
like
[good first bug] (such as what is done in the bugzilla project itself or
LibreOffice). This would give the opportunity to new comers to have a
starting
point.
This mean that some maintainers should tag these bugs report and LEAVE THEM
OPEN, EVEN IF EASY TO FIX.
The best is to open a report on bugzilla for each individual patch you
submit
(see [4]). You can use the Keyword 'PatchAvailable' to identify them
even more
easily.
It help us tracking them and they don't get lost in a mailing list.
I'll be glad (and I know some others will also) to have a look at it and
push
it to the repository.
If you are interested by one of the few ideas above and need more inputs on
where/how exactly to start, do not hesitate to ask.
Other (old) ideas can be found at http://httpd.apache.org/dev/todo.html
Hoping these few lines can help or can be a starting point for new comers.
[1] http://httpd.apache.org/dev/styleguide.html
[2] https://httpd.apache.org/docs/2.4/
[3] http://httpd.apache.org/test/
[4] http://httpd.apache.org/dev/patches.html
