Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Mon, 12 Nov 2001 01:14:18 -0800
From: Aaron Bannert <aaron@clove.org>
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0 STATUS
Message-ID: <20011112011418.Y7138@clove.org>
Mail-Followup-To: Aaron Bannert <aaron@clove.org>, dev@httpd.apache.org
References: <20011111010444.33888.qmail@icarus.apache.org>
 <20011110172014.E11988@ebuilt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011110172014.E11988@ebuilt.com>
User-Agent: Mutt/1.3.23i

On Sat, Nov 10, 2001 at 05:20:14PM -0800, Justin Erenkrantz wrote:
> On Sun, Nov 11, 2001 at 01:04:44AM -0000, jerenkrantz@apache.org wrote:
> >   +
> >   +    * Source code should follow style guidelines.
> >   +        This can't wait until we have a 2.0-gold release because then
> >   +        style corrections will conflict with bug fixes found after
> >   +        release which is not nice.
> 
> Personally, I think this is a release showstopper, but I can be talked
> out of that.  I don't want to end up in the situation where we go GA
> and then do style changes and then the diffs AFTER the GA become
> cluttered with style fixes.  So, I think this needs to happen before
> we go GA.  For now, it lands in release-showstopper category.
> 
> It also may be best to devise a plan of attack for getting files 
> converted to the right style.  -- justin

Justin and I have been discussing this topic offlist for some time
now, and just finally decided to make a note of it in the STATUS file.
I feel that style consistency is a very important part of any reference
implementation for a number of reasons. Many people will read this
code. Some will be looking for bugs which will be contributed back
to the group in the form of patches. Others will use the code as an
educational tool. Some will use it as a foundation on which to build a
more complicated and valuable application. Having inconsistent code style
(in some cases even within the same code segment) means that it is just
that much more difficult for code review. Less eyes means less found bugs.

I propose that we come up with a schedule and some simple guidelines.
1) The style changes should be the minimum to meet our style guidelines.
2) Any style change should avoid interrupting any development work on
   a part of the code (WRT outstanding patches, parts of the code that
   a developer has indicated they are working on, parts of the code that
   are in flux).
3) Code style modifications shall be announced on the list prior to
   in-CVS modification (3 days lead time? may we proceed one subdirectory
   at a time?)


I'd also prefer this not to hold up a GA, but I do think it is not something
that can wait until after. OTOH, I believe we can do the changes in a
non-invasive and rapid manner. How does this sound?

-aaron