You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/11/11 02:20:14 UTC
Re: cvs commit: httpd-2.0 STATUS
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
Re: cvs commit: httpd-2.0 STATUS
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 12, 2001 at 09:28:40AM -0800, Aaron Bannert wrote:
>...
> Whether or not this is a showstopper is negotiable, and I think it
> is completely reasonable to move ahead with a GA release if we are
> ready. OTOH, I don't think we should do significant style updates *after*
> a release. In the mean time I'd personally like to make an effort to
> clean up the style and make it consistent and readable.
Nothing is stopping you. If you want to make an effort, then just go ahead.
It is impossible for somebody to say "don't spend your time with that; do
<this> instead." Of coures, they can veto your patch, but I'd wonder what
kind of technical justification they'd have for that :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0 STATUS
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 12, 2001 at 09:11:52AM -0800, Ryan Bloom wrote:
> > > 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
> >
> > I disagree that this is a showstopper.
>
> So do I.
Whether or not this is a showstopper is negotiable, and I think it
is completely reasonable to move ahead with a GA release if we are
ready. OTOH, I don't think we should do significant style updates *after*
a release. In the mean time I'd personally like to make an effort to
clean up the style and make it consistent and readable.
-aaron
Re: cvs commit: httpd-2.0 STATUS
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 12 November 2001 05:55 am, Bill Stoddard 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
>
> I disagree that this is a showstopper.
So do I.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0 STATUS
Posted by Bill Stoddard <bi...@wstoddard.com>.
> 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
>
I disagree that this is a showstopper.
Bill
Re: cvs commit: httpd-2.0 STATUS
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sat, Nov 10, 2001 at 08:49:27PM -0500, Jeff Trawick wrote:
> How many people really give a shit? I'm truly curious.
I do. =) I believe that our code is also a way to teach people.
We are espousing our code as a "reference implementation" - to me,
that means it must be clean, precise, and the best we can make it.
In my (limited) experience, clean code is also usually easier to
review. So, I think there is a tangible benefit by enforcing a
unified style throughout the code base.
I first learned the httpd code by sifting through the code. If the
code is all jumbled (tabs and spaces conflicting, long lines, bad
scoping, etc), that would have bugged me enormously. Now that I'm
familiar with the 2.0 code, it bugs me even more. =) At least in
the 1.3 series, most of the code was pretty standardized. But,
people who cared about the code style no longer have the time to
be bitchy about it. I have no problem being a style pedant and
forcing all of the code being conformant.
The one valid complaint I've seen about code style changes is when
it is done after a release. That was Dean's complaint in the 1.3
series - people were committing style changes after 1.3 was
released. I'd like to learn from that and do it proactively.
> Personally, I'd "fix" the style in code I'm mucking around with, I
> have no issue with other people "fixing" style on a larger scale, but
> tracking this in the STATUS file and even bringing up the
> "showstopper" label seems a little silly to me when we haven't had a
> beta since April :)
Recently, Ken, Aaron, and I have been making some attempts at
reformatting as we go along, but I wonder if it would be best to
speed this up by doing it all at once. Perhaps a perl script
would come in handy?
Yes, there are other things I'd like to tackle, but I think this
at least deserves merit in STATUS. =) -- justin
Re: cvs commit: httpd-2.0 STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jeff Trawick wrote:
>
> How many people really give a shit? I'm truly curious.
..whoops.. but I don't think it's a show-stopper for a release.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: httpd-2.0 STATUS
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jeff Trawick wrote:
>
> How many people really give a shit? I'm truly curious.
I do. It irritates me and detracts from my concentration when
I'm scanning code and then have to go back and look more carefully
because some bloody brace wasn't where it was supposed to be.. or
an if-enclosure is misindented.. or..
It's just an irritation, but there's no need for it.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
Re: cvs commit: httpd-2.0 STATUS
Posted by Jeff Trawick <tr...@attglobal.net>.
Justin Erenkrantz <je...@ebuilt.com> writes:
> 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.
How many people really give a shit? I'm truly curious.
Personally, I'd "fix" the style in code I'm mucking around with, I
have no issue with other people "fixing" style on a larger scale, but
tracking this in the STATUS file and even bringing up the
"showstopper" label seems a little silly to me when we haven't had a
beta since April :)
Best wishes,
Jeff
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: coding style cleanup Re: cvs commit: httpd-2.0 STATUS
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sat, Nov 10, 2001 at 06:21:18PM -0800, Brian Pane wrote:
> While I'm not opposed in principle to doing a code cleanup before
> GA, I'd feel much more comfortable if it either:
> * didn't delay the release, or
> * added some quantifiable, incremental value for users.
I think it adds some quantifiable, incremental value for the
people coding the bugger. =) You are right in that it would
have no effect on the users.
And, I think we could do it in such a way that it didn't delay a
release. Realistically, we'll have some time after 2.0.X (28?)
goes beta to do some last-minute things. AIUI, all of the other
release showstoppers *need* to be addressed before labeling
anything GA, so I think that we have a few weeks before having a
GA ready at the earliest. That should be enough time to do it.
If we are to do style changes, I'd like to do it in a way that
doesn't harm developers trying to get a release out the door.
If we don't do it before we go GA, we're never going to do it.
And, we'll be stuck with that style until we open 2.1 for
development. -- justin
coding style cleanup Re: cvs commit: httpd-2.0 STATUS
Posted by Brian Pane <bp...@pacbell.net>.
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
>
Can you quantify the value of doing style cleanups before GA?
I.e., what's the value to the customers (the people who'll use
2.0) of holding up the release in order to fix up the coding style?
I might just be overreacting, but I'm particularly worried about
making this a release showstopper because I fear that it could
offset some of the potential benefits of 2.0.
I assert that a big part of the value proposition that 2.0
will offer to users is lower capital cost:
* Compared to 1.3, it should require less hardware to handle
the same volume of traffic.
* Compared to various commercial servers, it should offer
competitive performance, quality, and features without the
licensing fees.
(Both of these points assume that we'll produce a 2.0 GA release
with great performance and quality, but I think we're close to
doing so.)
From this perspective, delaying GA is generally a bad thing.
While we fix the code indentation, potential users may have to
buy more servers to handle traffic growth under 1.3, or buy
more per-host licenses for commercial servers.
While I'm not opposed in principle to doing a code cleanup before
GA, I'd feel much more comfortable if it either:
* didn't delay the release, or
* added some quantifiable, incremental value for users.
--Brian
Re: cvs commit: httpd-2.0 STATUS
Posted by Ryan Bloom <rb...@covalent.net>.
On Monday 12 November 2001 09:12 pm, Justin Erenkrantz wrote:
> On Mon, Nov 12, 2001 at 01:48:21AM -0800, Roy T. Fielding wrote:
> > 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.
>
> [ Obviously, you know way more about this than I do, but I would
> appreciate any clarification. ]
>
> My understanding from past conversations on list was that no one
> could veto a rolling of a tarball. However, at the same time,
> it was mentioned that it was not possible to do a GA release if
> there were any outstanding "showstoppers" - as these are in effect,
> vetos. The limitation here is not in the actual rolling of the
> release (you can't stop that) - just the upper limit on what we
> can call it. If it has a showstopper listed in STATUS, my
> understanding is that it may not be called GA. Am I wrong?
Yes and no. The whole point of calling something a showstopper is that
everybody on list agrees that you can't have a GA release with that bug
present. So, it isn't that it is a veto, it is more like an agreement that these
issues are too important, and nobody will suggest GA until they are fixed.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: cvs commit: httpd-2.0 STATUS
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Mon, Nov 12, 2001 at 01:48:21AM -0800, Roy T. Fielding wrote:
> 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.
I will move my note in STATUS to be a non-release showstopper as
that seems to be the consensus here.
> 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.
[ Obviously, you know way more about this than I do, but I would
appreciate any clarification. ]
My understanding from past conversations on list was that no one
could veto a rolling of a tarball. However, at the same time,
it was mentioned that it was not possible to do a GA release if
there were any outstanding "showstoppers" - as these are in effect,
vetos. The limitation here is not in the actual rolling of the
release (you can't stop that) - just the upper limit on what we
can call it. If it has a showstopper listed in STATUS, my
understanding is that it may not be called GA. Am I wrong?
-- justin
Re: cvs commit: httpd-2.0 STATUS
Posted by Aaron Bannert <aa...@clove.org>.
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
Re: cvs commit: httpd-2.0 STATUS
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
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
Re: cvs commit: httpd-2.0 STATUS
Posted by Aaron Bannert <aa...@clove.org>.
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