httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apache-2.0/src/lib/apr/time/beos access.c
Date Tue, 14 Sep 1999 22:36:13 GMT
+1 on Ben's point-of-view, arguments, and points.

I can't add anything more useful/explanatory, so I'll just shut up and
root for Ben :-)

Cheers,
-g

On 13 Sep 1999, Ben Hyde wrote:
> Ryan Bloom <rbb@raleigh.ibm.com> writes:
> ...
> > I will at this point leave it up to the maintainer of each platform to
> > determine if they want to merge their code into the unix directory.  If
> > everybody who is working on APR merges their code in, we will remove the
> > subdirectory structure that currently exists.
> 
> Fair, but unlikely to actually give rise to any change.  It maybe too
> late for for BEOS and Windows.
>...
> Doing the #if.. at toplevel licenses files like 1.3's http_main.c.
> Code that didn't absolutely have to fork does, then it starts to
> change so one branch has enhanements, variations of sequencing,
> bug fixes while the other doesn't. For example in http_main
>...
> The reader is left unsure if those variations are by design 
> or chance.  This kind of dry rot is encouraged by forked a bundle 
> of code on day one - because that was easiest - and then pushing 
> the two branches up hill ever since.
>...
> At the heart of my preference for the style I suggest is that is
> creates a huge improvement in the sympathy and synergy across cross
> platforms.  Having built stuff in this manner I am regularly pleased
> with the way that when you fix something on one platform you are much
> more likely to consider the same senario on the others.  We
> transitioned a mess of code to this style after I noticed repeated
> cases of a fix on one platform (usually a very subtle fix involving
> locks and memory management) was ignored on another because they
> hadn't yet suffered from the stress that exposed the problem.
>...
> Yeah, I've seen code like that.  And yes it is lexically very ugly.
> Consensus rarely forms about what topology of #if is right because
> porting across various features is a mess.  A mess that is be pushed
> around from one place to another.  I like to think my preference is 
> for something who's structure enhances the social engineering during
> the long maintainance period.  Yes, it does create a lexically ugly,
> in your face, quality to the variation on features.

--
Greg Stein, http://www.lyra.org/



Mime
View raw message