Re: httpd-2.0/apr/apr-util Code Freeze
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes: > Can we begin a code freeze, excepting _minor_ build and code fixes, until > we have > a stable tarball ready to share? I have win32 folks trying to make > apache2.0a9 build, > this just doesn't make any sense. Once Ryan's patch is in, let's roll, and > then go back > to town. I think that whoever plans to tag/roll should suggest a target time (e.g., "Friday noon PST") as well as a timeframe for soft freeze (only build fixes and minor code fixes welcome for 16 hours prior to target??). A hard freeze right around the tag is expected. Part of this was implied in your earlier note (you anticipated that Ryan would commit a fix sometime today and we'd tag/roll later today). Now that Ryan suggests "Thursday or Friday" I wonder when you want a freeze. I don't want a freeze now if we don't tag/roll until Friday afternoon. Thanks... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: httpd-2.0/apr/apr-util Code Freeze
I'm tagging and rolling right now. The tree currently builds on Windows and Linux, and I believe based on Jeff's recent commits, I have to believe that it compiles everyplace else. It also works on OS/2 and BeOS AFAIK. Tag and roll coming in the next hour or so. Ryan On Wed, 7 Mar 2001, William A. Rowe, Jr. wrote: > Folks, > > I'm going to propose something radical. Although Jeff's recent commit > points out > a potentially serious problem (discrepancy between the file size and file > offset types) > in the Win32 APR, which I will look at today, this server appears rather > stable, and > buildable, and rbb will have 'the patch' today for our OS2 woes (see - cross > platform > development actually carries benefits!) > > Can we begin a code freeze, excepting _minor_ build and code fixes, until > we have > a stable tarball ready to share? I have win32 folks trying to make > apache2.0a9 build, > this just doesn't make any sense. Once Ryan's patch is in, let's roll, and > then go back > to town. > > It's been too long, time for a good tarball! I increasingly believe that a > pure > implementation of Roy's model can't work. Either 1) code freezes, 2) > dev/release branches, > or 3) parallel trees [I hate #3] seem required to allow development to > progress while folks > shoot down bugs. > > Bill > > > ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: httpd-2.0/apr/apr-util Code Freeze
william, the apache project is, i assume, suffering from the effects of many developers using cvs at the same time? if so, can i recommend reading the description of how to ease the pain of #3 below, described in http://advogato.org/article/247.html it outlines how to use cvs to do one or more simultaneous cvs branches on sub-sections of a codebase. i.e. how to use a cvs tag for a small sub-section of the codebase and to use _another_ cvs tag for the rest. simple example: one developer wishes to try out a new memory manager replacement for apr_pool.c, where this may have a massive impact if carried out in cvs main, plus if they tag the entire cvs repository to do it, _they_ get out-of-date. so they tag _only_ the files that are modified by their experiment, and pull in all the rest from cvs main. the same procedure can be applied simultaneously by many developers, each doing their Own Thing. and the idea is that you can _always_ do a tarball / release at any time, because the developers are expected to do a cvs update -j 'mydevelopmenttag' / code-merge once they have proved that their work is stable, and not before - without a really good reason. am also giving serious consideration to writing a script to be run on cvs commits that uses keynote - requiring that cvs commits be digitally "signed off" by at least two developers / reviewers. but that's another story :) luke On Wed, 7 Mar 2001, William A. Rowe, Jr. wrote: > It's been too long, time for a good tarball! I increasingly believe that a > pure > implementation of Roy's model can't work. Either 1) code freezes, 2) > dev/release branches, > or 3) parallel trees [I hate #3] seem required to allow development to > progress while folks > shoot down bugs. > > Bill > > > - Luke Kenneth Casson Leighton <[EMAIL PROTECTED]> - "i want a world of dreams, run by near-sighted visionaries" "good. that's them sorted out. now, on _this_ world..."
Re: httpd-2.0/apr/apr-util Code Freeze
There are a couple of bugs in the STATUS file that I started hunting today. Can we shoot for a tarball roll of sometime on Thursday or Friday? I agree, the no-freeze model just doesn't work in this environment. Ryan On Wed, 7 Mar 2001, William A. Rowe, Jr. wrote: > Folks, > > I'm going to propose something radical. Although Jeff's recent commit > points out > a potentially serious problem (discrepancy between the file size and file > offset types) > in the Win32 APR, which I will look at today, this server appears rather > stable, and > buildable, and rbb will have 'the patch' today for our OS2 woes (see - cross > platform > development actually carries benefits!) > > Can we begin a code freeze, excepting _minor_ build and code fixes, until > we have > a stable tarball ready to share? I have win32 folks trying to make > apache2.0a9 build, > this just doesn't make any sense. Once Ryan's patch is in, let's roll, and > then go back > to town. > > It's been too long, time for a good tarball! I increasingly believe that a > pure > implementation of Roy's model can't work. Either 1) code freezes, 2) > dev/release branches, > or 3) parallel trees [I hate #3] seem required to allow development to > progress while folks > shoot down bugs. > > Bill > > > ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
httpd-2.0/apr/apr-util Code Freeze
Folks, I'm going to propose something radical. Although Jeff's recent commit points out a potentially serious problem (discrepancy between the file size and file offset types) in the Win32 APR, which I will look at today, this server appears rather stable, and buildable, and rbb will have 'the patch' today for our OS2 woes (see - cross platform development actually carries benefits!) Can we begin a code freeze, excepting _minor_ build and code fixes, until we have a stable tarball ready to share? I have win32 folks trying to make apache2.0a9 build, this just doesn't make any sense. Once Ryan's patch is in, let's roll, and then go back to town. It's been too long, time for a good tarball! I increasingly believe that a pure implementation of Roy's model can't work. Either 1) code freezes, 2) dev/release branches, or 3) parallel trees [I hate #3] seem required to allow development to progress while folks shoot down bugs. Bill
Re: mm.h and -I/usr/local/include problems
[EMAIL PROTECTED] wrote: > > On Wed, 7 Mar 2001, jean-frederic clere wrote: > > > Hi, > > > > On our machine (BS2000) there is a mm.h in /usr/local/include and it is > > conflicting with the APR one in srclib/apr/shmem/unix/mm. We need to use > > CFLAGS="-I/usr/local/include" for the configure because the basic > > /usr/include only gives a very reduced set of includes. > > > > The problem is due to that APR puts the CFLAGS before its own includes. > > > > How should I solve this problem? > > Just reverse the order of the -Is and CFLAGS. If that works, let me know > and I'll check it in. That is easy, the CFLAGS comes from rules.mk, I have set: +++ COMPILE = $(CC) $(CPPFLAGS) $(CFLAGS) +++ and it works that way. > In reality, we probably want any system headers to > be used after any of our headers anyway, so we probably want to do this > for all of the Makefiles. That is what I would like to suggest... > > If you could just test it, I'll make the change on my box, and commit with > your name if it works. For something like this, making a patch isn't > really worth it IMHO. > > Ryan > > ___ > Ryan Bloom [EMAIL PROTECTED] > 406 29th St. > San Francisco, CA 94131 > ---
Re: mm.h and -I/usr/local/include problems
On Wed, 7 Mar 2001, jean-frederic clere wrote: > Hi, > > On our machine (BS2000) there is a mm.h in /usr/local/include and it is > conflicting with the APR one in srclib/apr/shmem/unix/mm. We need to use > CFLAGS="-I/usr/local/include" for the configure because the basic > /usr/include only gives a very reduced set of includes. > > The problem is due to that APR puts the CFLAGS before its own includes. > > How should I solve this problem? Just reverse the order of the -Is and CFLAGS. If that works, let me know and I'll check it in. In reality, we probably want any system headers to be used after any of our headers anyway, so we probably want to do this for all of the Makefiles. If you could just test it, I'll make the change on my box, and commit with your name if it works. For something like this, making a patch isn't really worth it IMHO. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
mm.h and -I/usr/local/include problems
Hi, On our machine (BS2000) there is a mm.h in /usr/local/include and it is conflicting with the APR one in srclib/apr/shmem/unix/mm. We need to use CFLAGS="-I/usr/local/include" for the configure because the basic /usr/include only gives a very reduced set of includes. The problem is due to that APR puts the CFLAGS before its own includes. How should I solve this problem? Cheers Jean-frederic
