Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
To: dev@httpd.apache.org
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Subject: Re: Is Apache getting too patchy?
Date: Fri, 30 Oct 2015 07:05:47 +0100
Lines: 114
Message-ID: <n0v1bv$5ng$1@ger.gmane.org>
References: <38B6AA15-AB3C-47AC-B96D-7DA8094F99F9@jaguNET.com>
 <562E5A1F.9080201@gmail.com> <20151026222322.232ef884@baldur>
 <40FF7659-3F5A-4010-9A4B-D7E09B9ACF95@c8h10n4o2.org.uk>
 <995B8E3C-91B1-4A36-9940-A91EE86AE9B1@sharp.fm> <562FA608.8020501@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
In-Reply-To: <562FA608.8020501@gmail.com>


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