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:48:21 -0800
From: "Roy T. Fielding" <fielding@ebuilt.com>
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0 STATUS
Message-ID: <20011112014821.A2534@waka.ebuilt.net>
References: <20011111010444.33888.qmail@icarus.apache.org>
 <20011110172014.E11988@ebuilt.com> <20011112011418.Y7138@clove.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011112011418.Y7138@clove.org>
User-Agent: Mutt/1.3.20i

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.

  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.

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.

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.

....Roy