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: httpd-2.0/server core.c Makefile.in connection.c
Date Mon, 05 Mar 2001 07:47:32 GMT
On Sun, Mar 04, 2001 at 05:59:46PM -0800, rbb@covalent.net wrote:
> On Sun, 4 Mar 2001, Bill Stoddard wrote:
>...
> > It's in so leave it in. But I think Ken does bring up a valid point.  Jeff
> > and I spend a good bit of our development time fixing compile breaks, many
> > which are introduced by 'cosmetic' changes to the code or build environment.
> > In general, folks have been MUCH less disciplined about what they commit to
> > Apache 2.0 than what they commit to 1.3.  It's time for that to change. I
> > would request that you (all of us) try to compile our commits against
> > multiple OSes as a courtesy to the other active developers.

>From the Apache project guidelines:

"All code changes must be successfully compiled on the developer's platform
 before being committed."

I believe that has been happening.

"However, it is sometimes impossible for a developer on one platform to
 avoid breaking some other platform when a change is committed, particularly
 when completing the change requires access to a special development tool on
 that other platform. If it is anticipated that a given change will break
 some other platform, the committer must indicate that in the commit log."

Ryan certainly has been noting the possible breakage on Windows, which is
both fair and follows our accepted practices. We've all busted Windows
before because most of us don't have a Windows dev setup for Apache;
similarly, some changes have been made by Windows developers which has
broken Unix-ish builds. It happens.

I don't necessarily want to use the dev guidelines as a weapon in the old
back pocket, to be referred to when it suits, and ignore when it doesn't.
The guidelines should be alterable when we choose to do so. But in this
case, I wholeheartedly agree with it.

Each of us has limited time and capabilities. Requiring cross platform
builds before any commit is simply too high of a bar for most people to
cross. It just isn't workable.

>...
> don't work as expected.  I fully intend to continue to continue to _try_
> not to break the build, but mandating that everybody needs to build on
> multiple platforms is unfair.  Should I never commit just because I can't
> compile on Windows?  How about AIX?  Old versions of FreeBSD?  When do we
> draw the line?

Agreed. Most of us just don't have the access to do so. Further, it is very
difficult to do cross-platform testing if the change isn't in CVS(!). I find
it much easier to get a change over to another platform by simply doing a
"cvs update" command :-)

> People need to be aware that different platforms behave differently, but
> we can't force people to try to compile on different platforms, it doesn't
> work.  Take a look at what has broken the builds recently.
> 
> APR_HEADER_CHECK:  How many times did we fix this on one platform, only to
> break it on another?

Yup. My fault for assuming M4 was a hell of a lot more portable than it
apparently is. Ya learn, I guess.

> ap_mpm_query:  I broke the build on BeOS.  I should have been more
> careful, but I could have just not made the change on BeOS.  I believe
> David is happier that I tried and failed, than if I hadn't tried.

Simple mistake. Easily fixed, too.

> addition of protocol.c:  I broke the Windows build, and in doing so,
> learned how to add a new file to Windows, so that when I added core.c, I
> didn't break the build.

You knew it for protocol.c, and learned. Then solved it right for core.c.
What more could be asked?

> People are trying their best, and if the build breaks, then it is a
> mistake, and it should be taken as such.

Right.

> If the build is broken on your
> system, can I suggest posting a quick message to new-htpd about it?
> Usually, the person who made the change will respond quickly and tell you
> basically what needs to be done to fix the build.

Well, I might argue with "quickly" :-) ... not all of us are strapped to our
computers. But there is a good chance that somebody will see the problem and
assist sooner rather than later.

Cheers,
-g

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

Mime
View raw message