Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Mon, 12 Nov 2001 09:42:05 -0800
From: Aaron Bannert <aaron@clove.org>
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0 STATUS
Message-ID: <20011112094205.I7138@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> <20011112011418.Y7138@clove.org>
 <20011112014821.A2534@waka.ebuilt.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011112014821.A2534@waka.ebuilt.net>
User-Agent: Mutt/1.3.23i

On Mon, Nov 12, 2001 at 01:48:21AM -0800, Roy Fielding wrote:
> While I agree with the desire for a readable code base, I have a couple
> of disagreements with your argument
> 
>   1) we don't call it a reference implementation -- we just call it the
>      best implementation of a general-purpose server.  Tomcat is a
>      reference implementation of Servlets.  The IETF doesn't have such things.
> 
>   2) it isn't a showstopper, because the current state of the code base
>      is no worse than the last release and we certainly aren't going to
>      prevent 2.0.28 going out as alpha or beta before it is done.

In no way do I want this to hold up any alpha or beta release. (2.0.28 should
go out ASAP, IMHO.) If there is enough support for this before GA, we might
be able to slightly delay GA, but then again given enough support we could
probably take care of this pretty quickly.

>   3) Nobody can veto a release -- showstoppers are merely a tool to make
>      everyone aware of a veto on a specific change or a bug that everyone
>      agrees must be fixed before a release.
> 
> > 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?)
> 
> 2 and 3 are a contradiction.  Lead time implies nobody can change the code
> in the interim, which inevitably interrupts someone's development.

It was my intention that the group decide how to resolve 2 and 3. How
willing are we to interrupt progress to bring the style up to a consistent
state? OTOH, how lenient are we going to be on prior readability violations
(to put it harshly ;)?

> The last time we did this (pre 1.3.0), we created a file in the repository
> that listed the indent status of every other file in the repository, and
> some of us just marked what we were working on in that file.
> 
> For the most part, style changes should be made very carefully and by hand.
> The indent program should only be used on massively hosed files, and then
> afterwords that person has to go though and fix all of indent's mistakes
> by hand.  I don't know of any massively hosed files in 2.0 right now.

I believe guideline #1 addresses this. Prefer by hand, change
only the minimum to make it readable/style-compliant.

> It is more important that the code be readable than that the code be
> 100% compliant with all of the whitespace or comment guidelines.  Sometimes
> that calls for extra whitespace to make things line up in columns.


-aaron