Re: 2.1 Fallout; httpd v.s. httpd-2.0
On Sunday, November 24, 2002, at 10:42 PM, Justin Erenkrantz wrote: Um, the history is still available via CVS - just at a different repos. I know that I did a checkout of apache-1.2 and also went to ViewCVS to track down the chunking commit. The history is still there - it's just disjoint. Our group precedent here is clearly to create a new repository rather than using CVS branches. (And, even now, I still think it's the right decision.) We can make a duplicate of the httpd-2.0 CVS module and call it httpd-2.1 or whatever the heck we want, and keep the history. Why do we have to lose the history? -1 to losing the history -aaron
Re: 2.1 Fallout; httpd v.s. httpd-2.0
On Sun, 24 Nov 2002, Justin Erenkrantz wrote: > --On Monday, November 25, 2002 12:21 AM -0600 "William A. Rowe, Jr." > <[EMAIL PROTECTED]> wrote: > > > OUTCH! The point to the 2.x history is that we DON'T lose the > > history! I'm guessing I was one of only 5 committers with an rsync > > of 1.2 when the chunk security hole bit us. History is very, very > > precious in a project this large. > > Um, the history is still available via CVS - just at a different > repos. I know that I did a checkout of apache-1.2 and also went to > ViewCVS to track down the chunking commit. The history is still > there - it's just disjoint. Our group precedent here is clearly to > create a new repository rather than using CVS branches. (And, even > now, I still think it's the right decision.) When the 1.2 vs. 1.3 decision to go away from branches was made, there were a number of bugs in CVS relating to branches that made them just not work right. Those bugs are gone. When the 2.0 repository was created, it was because we knew it would be a complete restructuring of nearly everything. It is far easier to apply changes to code that is the same in both the head and backport to the branch when they are in the same repository. It is then just a matter of a single cvs update command, resolving conflicts, and committing. It is far easier to figure out what has changed between the branch and the head, etc. when it is a branch. If you are looking at 2.1 being as different from 2.0 as 1.3 and 2.0 are, then perhaps a branch isn't the best idea. But if you are looking at having that many differences before 2.0 has even had a chance to stablize, I think you are asking for trouble and how to manage the CVS repository would be the least of the worries... The history is accessible if they are in different repositories, but many operations that are automated via cvs become manual. > > Only if we have many branches; we propose very few. > > I think this is where you and I diverge. I'm taking a very long > perspective in that over time, we would have many branches. For 2.1, > it might not be bad to have them coexist. But, in two years, we'll > probably be at 2.8/3.0 (if not beyond). That's a stable release > every six months which is about our plan, IIRC. I don't plan for our > CVS repositories to last that long. -- justin Having a lot of old branches in a file doesn't really slow down most typical operations (ie. checkout and update) much. What slows things down is having an active branch that is a long way off the HEAD, since it means backpatching from the HEAD to the branchpoint, then forward patching along the branch to get the current version on the branch. It doesn't matter if you have to backpatch 100 revisions then forward patch 10 to go from 2.8 to 2.1 since by that time all we will really care about is 2.7 and 2.8, and 2.7 will still be close enough to the head. Again, it isn't branches that are the problem. It is only active branches and both how many revisions there are on the branch and how far back the branchpoint is from the head.
Re: 2.1 Fallout; httpd v.s. httpd-2.0
--On Monday, November 25, 2002 12:21 AM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: OUTCH! The point to the 2.x history is that we DON'T lose the history! I'm guessing I was one of only 5 committers with an rsync of 1.2 when the chunk security hole bit us. History is very, very precious in a project this large. Um, the history is still available via CVS - just at a different repos. I know that I did a checkout of apache-1.2 and also went to ViewCVS to track down the chunking commit. The history is still there - it's just disjoint. Our group precedent here is clearly to create a new repository rather than using CVS branches. (And, even now, I still think it's the right decision.) Only if we have many branches; we propose very few. I think this is where you and I diverge. I'm taking a very long perspective in that over time, we would have many branches. For 2.1, it might not be bad to have them coexist. But, in two years, we'll probably be at 2.8/3.0 (if not beyond). That's a stable release every six months which is about our plan, IIRC. I don't plan for our CVS repositories to last that long. -- justin
Re: 2.1 Fallout; httpd v.s. httpd-2.0
At 11:36 PM 11/24/2002, Justin Erenkrantz wrote: >No, it'd still be the case - an update isn't sufficient. I'd have to get a brand-new >checkout of httpd because my local working copy would refer to httpd-2.0. At best, I >might be able to run a script to tweak my CVS directories. Correct; you couldn't commit back from your current tree, a simple .pl script could fix your CVS/Repository files. >I'd prefer that we start 2.1 on a new repository that doesn't have "2.0" in the name. > Yes, that means losing history of 2.0 in that repository. So, be it. >It's not all that important, and we've done this at every branch point before. OUTCH! The point to the 2.x history is that we DON'T lose the history! I'm guessing I was one of only 5 committers with an rsync of 1.2 when the chunk security hole bit us. History is very, very precious in a project this large. >Some of the operations take too long as it is because of the large history of some >files. Only if we have many branches; we propose very few. >Regardless, whatever we do must be planned and agreed to ahead of time. -- +++1; that was the point of my note and the basis to Roy's objections :-)
Re: cvs commit: httpd-site/docs/dev anoncvs.txt devnotes.html how-to-release.html
* Justin Erenkrantz wrote: > We don't want to serve the original XML files. httpd-2.0's docs have > valid XSLTs which mean that they can be rendered with modern web > browsers. s/can/could/ ;-) Actually I don't know any browser, which is able to render the docs xml/xslt correctly. I really consider to start a discussion about removing the xslt references from the docs' xml files. (just btw.) nd -- If God intended people to be naked, they would be born that way. -- Oscar Wilde
Re: cvs commit: httpd-site/docs/dev anoncvs.txt devnotes.htmlhow-to-release.html
--On Sunday, November 24, 2002 9:51 PM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: Can I just state that this surprise really sucks? Why couldn't we follow the same protocols as in httpd-2.0/docs/manual/ where xml coexists peacefully alongside html output??? We don't want to serve the original XML files. httpd-2.0's docs have valid XSLTs which mean that they can be rendered with modern web browsers. httpd-site's content doesn't have a XSLT. Therefore, if we exposed the raw XML files to a web browser, they wouldn't make any sense to anyone. The eventual goal is not to have a docs directory in CVS at all, but we can't do that given our current infrastructure. Therefore, all of the content must be generated statically and checked into the repository. Hence, docs/ is only valid for transformations. -- justin
Re: 2.1 Fallout; httpd v.s. httpd-2.0
--On Sunday, November 24, 2002 11:01 PM -0600 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: Ken's change for htdocs was really a pita because existing checkouts were simply broken. This isn't the case for this schema. You update when you need to commit (and the system's informed you you cannot commit.) Planned chaos rather than unanticipated chaos. No, it'd still be the case - an update isn't sufficient. I'd have to get a brand-new checkout of httpd because my local working copy would refer to httpd-2.0. At best, I might be able to run a script to tweak my CVS directories. I'd prefer that we start 2.1 on a new repository that doesn't have "2.0" in the name. Yes, that means losing history of 2.0 in that repository. So, be it. It's not all that important, and we've done this at every branch point before. Some of the operations take too long as it is because of the large history of some files. Regardless, whatever we do must be planned and agreed to ahead of time. -- justin
2.1 Fallout; httpd v.s. httpd-2.0
Although I don't have the karma, I'll take the fallout and flak for coming up with the idea (although not the initial objection) that was raised for changing the repository's name from httpd-2.0 to httpd. A couple folks have suggested we shouldn't use a branch for various reasons. I mildly to strongly disagree with the reasons given. Centralizing the history into a single repository is massive goodness. Yes, with cvs this isn't an optimal and performant solution, but it has worked just fine for Tomcat. We aren't speaking of multiple oodles of branches, only one every blue moon (every six months to a year, perhaps.) If and when we convert to SVN, and the branch conversion bug is addressed and long gone, the entire history of the project since 2.0.0 will be available in a single place for all to review. That, I believe, is goodness. So, I then realized how badly this f*s things up without advance notice and consideration to all the places (cvs commit messages, viewcvs, et al) and folks (with active checkouts) that need to prepare for the change. So thank you Roy for flipping the switch back to 'normal' operations. So, proceeding on the idea that 2.X lives in a single repository, (which was voted for a month with absolute concensus) where can we go from here, and how do we have to prepare? Obviously, infrastructure needs to be involved, including apmail, viewcvs, and other things I don't recognize at the moment. End users need time to update their cvs checkouts to the new canonical location. Lets say 45 days from the beginning of the changeover, with a headline in the top level httpd.apache.org index.html and details in /dev/. So when we begin the changeover, how do we avoid becoming hopelessly confused? I believe we begin with warning commiters about 15 days before, then 5, then 2, then 1 day before the change. On that day, httpd-2.0 becomes httpd. All cvs apmail and viewcvs resources are redirected at that time. httpd-2.0 becomes a module alias, WITH NO COMMIT PRIVILAGES for any users. This way we don't have some scattershot history of httpd-2.0 and httpd commits. Now, only committers were affected by that change, because everyone can still check out httpd-2.0. Now over the next month and a half, we encourage folks who follow the news that the repository name has changed. We encourage them to change over in a short time, just as our friends in Europe had to exchange their money not so long ago. Finally (before 2.2, certainly) this change becomes effective. The alias to httpd-2.0 cvs repository disappears. Users scrambling to find out what broke should be greeted again at httpd.apache.org/ and /dev/ to news of how to fix it. Ken's change for htdocs was really a pita because existing checkouts were simply broken. This isn't the case for this schema. You update when you need to commit (and the system's informed you you cannot commit.) Planned chaos rather than unanticipated chaos. Folks, any other observations besides apmail, viewcvs and the other aspects we must consider before we contemplate a rename? Bill
Re: cvs commit: httpd-site/docs/dev anoncvs.txt devnotes.html how-to-release.html
At 12:33 AM 11/24/2002, Justin Erenkrantz wrote: >--On Saturday, November 23, 2002 7:28 PM + [EMAIL PROTECTED] wrote: > >>wrowe 2002/11/23 11:28:42 >> >> Modified:docs/dev anoncvs.txt devnotes.html >>how-to-release.html Log: >>Reflect the commands for the APACHE_2_0_BRANCH split. > >Umm, shouldn't these changes have been committed to xdocs/dev not docs/dev? docs/dev >is liable to be overriden at any time. -- justin Can I just state that this surprise really sucks? Why couldn't we follow the same protocols as in httpd-2.0/docs/manual/ where xml coexists peacefully alongside html output??? Fixing now. Sigh. Bill
Re: cvs commit: httpd-site/docs/dev anoncvs.txt devnotes.html how-to-release.html index.html
At 02:26 AM 11/24/2002, Sebastian Bergmann wrote: >[EMAIL PROTECTED] wrote: >> + user@host:~$ cvs checkout -d httpd-2.0 -r APACHE_2_0_BRANCH httpd That doc update was reverted, along with all of the other notes related to any s/httpd-2.0/httpd/ change that didn't occur (it had occurred, and was later reverted.) httpd-2.0 is the repository name. New docs have been committed to the site. Bill
Re: Before I start a new module...
Knowing nothing about your setup, I would suggest instead writing a simple script (perl or whatever) that traverses your docroot and /compresses/ the whitespace out of your files, instead of doing it dynamically and per-request. my 2c, -aaron On Sunday, November 24, 2002, at 05:33 PM, Pier Fumagalli wrote: Ok, I was kindly asked by my management to write a new module for Apache 2.0, since as of _TODAY_ we're using it in production for non-static content as well (whoho!)... Before I move all my apps over on the new Apache 2.0 server, I need to be able to strip whitespace from HTML (ok, my designers like using DreamWeaver, not my fault), so since I can use filters, well... :-) First question would be... Seems pretty odd that noone thought about it before (???), so, is there a module doing that already? If not, am I right in looking at what mod_bucketeer does for a start? Cheeridos! :-) Pier
Re: cvs commit: httpd-2.0 STATUS ROADMAP
[assuming you meant R-T-C] I don't know of any recent violations of our implied rules [in httpd]; when has this ever been a problem? -aaron On Sunday, November 24, 2002, at 12:36 PM, David Reid wrote: Given the recent behavior of some I'm actually now in favour of C-T-R for any stable tree... Treat adults as adults until they prove they can't be so treated. +1 for C_T_R for stable branches
Re: Before I start a new module...
--On Monday, November 25, 2002 1:58 AM + Pier Fumagalli <[EMAIL PROTECTED]> wrote: Since I already don't have a Content-Length header (since I don't know how much content I'm going to shoot out), and my boss is concerned about mod_deflate not being supported by (like) Netscape 1.3.1 when Javascript is disabled (or some stuff like that, a customer is a customer), well, got no options left... In order for the server to send gzip'd data, it must send the magic header to the server (Accept-Encoding: gzip). Any browser that doesn't support gzip wouldn't be sending that string. There are some fscked browsers that send that header and don't mean it, but I believe they are already documented somewhere. IIRC, the person Fitz mentioned who was writing mod_blank refused to use 2.0, so I don't think that'll be very helpful. -- justin
Re: Before I start a new module...
Cliff Woolley <[EMAIL PROTECTED]> writes: > On Mon, 25 Nov 2002, Pier Fumagalli wrote: > > > Before I move all my apps over on the new Apache 2.0 server, I need to be > > able to strip whitespace from HTML (ok, my designers like using DreamWeaver > , > > not my fault), so since I can use filters, well... :-) > > Funny you ask... there was a fellow on here within the last few months > asking what we thought about him doing exactly that for his CS senior > thesis project (I think). Check the archives for the last few months. > Unfortunately I've forgotten his name and the name of the module he was > proposing... but search for "whitespace" and you'll likely find it. It was mod_blank, and he first posted about it on 26-Sept-02. The only name I got from his emails is "Fabio", but his address is [EMAIL PROTECTED] >From what I found in my mail spool, it looks like he wrote it but needs to do some testing. Good luck, -Fitz
Re: Before I start a new module...
On 25/11/02 2:38 am, "Cliff Woolley" <[EMAIL PROTECTED]> wrote: > On Mon, 25 Nov 2002, Pier Fumagalli wrote: > >> Before I move all my apps over on the new Apache 2.0 server, I need to be >> able to strip whitespace from HTML (ok, my designers like using DreamWeaver, >> not my fault), so since I can use filters, well... :-) > > Funny you ask... there was a fellow on here within the last few months > asking what we thought about him doing exactly that for his CS senior > thesis project (I think). Check the archives for the last few months. > Unfortunately I've forgotten his name and the name of the module he was > proposing... but search for "whitespace" and you'll likely find it. I > don't know if he actually wrote the thing or what, but I'm sure he'd like > to hear from you. I'll dig into the archives... That's why I asked first, because I thought I remembered I overheard something about it... > I imagined there'd ever be a real-world use for such a > thing, so I never commented to him about it. Glad to hear there is one! > :) Yes, DUMB templating systems, such as JSPs... And 2.0 helps when you have idiotic stuff on the backend... Like using mod_cache to cache our JSP-generated news... That's next, after I strip the extra whitespace! :-) I _love_ 2.0! :-) Pier
Re: Before I start a new module...
On Mon, 25 Nov 2002, Pier Fumagalli wrote: > Since I already don't have a Content-Length header (since I don't know how And the C-L filter won't generate one for you?
Re: Before I start a new module...
On 25/11/02 1:52 am, "David Crooke" <[EMAIL PROTECTED]> wrote: > Why not just strip them once on install, instead of every time they are > downloaded? You could hook something into ftp or whatever the > Dreamweaver kids are using for upload, or a cron to come and sweep > stuff, keeping track of what's processed using a timestamp file. Nonono :-) The dreamwever kids use dreamweaver to create JSP templates (evill) so, I am _not_ serving files off disk, I mean, I'm stupid, but not _that_ stupid! :-) :-) :-) Plus JSPs leave a _lot_ of crap around in files, like, several newline characters where there shouldn't be any... And so on... It's just a _stupid_ templating system, but what the heck, they pay me to accept my designers, so... :-) Since I already don't have a Content-Length header (since I don't know how much content I'm going to shoot out), and my boss is concerned about mod_deflate not being supported by (like) Netscape 1.3.1 when Javascript is disabled (or some stuff like that, a customer is a customer), well, got no options left... Pier
Re: Before I start a new module...
Why not just strip them once on install, instead of every time they are downloaded? You could hook something into ftp or whatever the Dreamweaver kids are using for upload, or a cron to come and sweep stuff, keeping track of what's processed using a timestamp file. Pier Fumagalli wrote: Ok, I was kindly asked by my management to write a new module for Apache 2.0, since as of _TODAY_ we're using it in production for non-static content as well (whoho!)... Before I move all my apps over on the new Apache 2.0 server, I need to be able to strip whitespace from HTML (ok, my designers like using DreamWeaver, not my fault), so since I can use filters, well... :-) First question would be... Seems pretty odd that noone thought about it before (???), so, is there a module doing that already? If not, am I right in looking at what mod_bucketeer does for a start? Cheeridos! :-) Pier
Re: Before I start a new module...
On Sun, 24 Nov 2002, Cliff Woolley wrote: > to hear from you. I imagined there'd ever be a real-world use for such a > thing, so I never commented to him about it. Glad to hear there is one! Er, s/ever/never/ ;) But still, glad to hear there is one. :) --Cliff
Re: Before I start a new module...
On Mon, 25 Nov 2002, Pier Fumagalli wrote: > Before I move all my apps over on the new Apache 2.0 server, I need to be > able to strip whitespace from HTML (ok, my designers like using DreamWeaver, > not my fault), so since I can use filters, well... :-) Funny you ask... there was a fellow on here within the last few months asking what we thought about him doing exactly that for his CS senior thesis project (I think). Check the archives for the last few months. Unfortunately I've forgotten his name and the name of the module he was proposing... but search for "whitespace" and you'll likely find it. I don't know if he actually wrote the thing or what, but I'm sure he'd like to hear from you. I imagined there'd ever be a real-world use for such a thing, so I never commented to him about it. Glad to hear there is one! :) --Cliff
Before I start a new module...
Ok, I was kindly asked by my management to write a new module for Apache 2.0, since as of _TODAY_ we're using it in production for non-static content as well (whoho!)... Before I move all my apps over on the new Apache 2.0 server, I need to be able to strip whitespace from HTML (ok, my designers like using DreamWeaver, not my fault), so since I can use filters, well... :-) First question would be... Seems pretty odd that noone thought about it before (???), so, is there a module doing that already? If not, am I right in looking at what mod_bucketeer does for a start? Cheeridos! :-) Pier
other_child maintenance status
The maintenance function for "other" children has the prototype: void (*maintenance)(int reason, void *, int status) however mod_cgid defines status differently (although apr_wait_t = int): static void cgid_maint(int reason, void *data, apr_wait_t status) What is status? Unless I'm completely wrong (which is always possible!), it can be one of two things: * The mpm's call ap_wait_or_timeout, which returns (via apr_proc_wait) an exit reason (APR_PROC_EXIT/APR_PROC_SIGNAL) and an exit code (actually exit code or signal code), and passes the exit code to apr_proc_other_child_read as the status parameter (which is then passed to the maintenance function). This means the maintenance function gets the exit code or the signal code as the status with no way of detecting which is which. * However, on the other hand, apr_proc_other_child_check() calls waitpid() and passes the returned wait-style status to the maintenance function. This means the maintenance function can call the standard Wx macros to decide what that meant. This means the maintenance function gets the exit code in the top 8 bits, the signal in the bottom 8 bits, etc. as per the wait() call. The simplest solution would be to standarise on wait-style status, but how can the mpm's get that back without calculating it from the apr-style status, which seems a kludge? It seems much better to standardise on the apr-style status, but that seems impossible without breaking compat as an additional apr "why" code needs to be passed to the maintenance functions. Best wishes, James -- James Ponder; www.squish.net; London, UK
Re: binbuild.sh favors GNU tar
=?ISO-8859-1?Q?Wilfredo_S=E1nchez?= wrote: > >So does anyone object if I un-favor GNU tar? > >Looks like the real reason we favor it is to use the -z option > instead of having to run gzip after the fact. Running gzip in a pipe > chain would do as well, though. > +1 for un-favoring GNUtar -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A society that will trade a little liberty for a little order will lose both and deserve neither" - T.Jefferson
Re: [PATCH] mod_deflate extensions
>--On Friday, November 22, 2002 12:03 PM +0100 Henri Gomez ><[EMAIL PROTECTED]> wrote: > >> So we should use a copy of mod_gzip compression code in Apache 2.0. >> Also as someone involved in mod_jk/jk2, I'll need gzip >> compress/uncompress support in Apache 2.0 for a new ajp protocol >> I'm working on, so having compression/uncompression in Apache 2.0 >> will be mandatory for me. > > Justin wrote... > > No, we shouldn't be including zlib code (or any variant) in our > distribution. That's not our responsibility. It's also not > important enough for us to further bloat our code just because an > insignificant number of distributions haven't provided a good package > of zlib. If it's that important, those administrators can build > their own zlib or just not use any functionality requiring zlib. The > point here is that no functionality is lost if zlib is missing. I guess that's where some would disagree and the point of Henri's original posting. I happen to think that a LOT of 'functionality' is 'missing' from Apache if it can't do compression/decompression 'out of the box' but that's certainly no secret since I've been voicing that opinion for some years now. It's still just one man's opinion, as is yours. Diff strokes for Diff folks. > (And, if you are doing a mod_jk, zlib support should be optional not > mandatory.) > >> Ok, let be pragmatic. Did Apache HTTP developpers agree that >> compression should be added in Apache 2.0 by incorporating mod_gzip >> comp code in Apache 2.0 ? > > mod_deflate is already there and it uses an external zlib library, so > I'm confused why we should also provide mod_gzip and/or its > proprietary compression code. No one has suggested 'also providing mod_gzip'. That's a dead issue. Apache will never be using 'mod_gzip'. The issue was whether or not it's time to think about adding some actual compression/decompression code (like ZLIB) to the source tree itself and/or the Non-ZLIB inline compression engine that mod_gzip uses which is perfectly do-able and pretty much a no-brainer. ...and for the record... the 'compression code' in mod_gzip is NOT PROPRIETARY. It is still just simple public domain LZ77 + Huffman. It is as 'open-source' as your own product (Apache), if not even more-so. ALL of the code for mod-gzip ( compression engine(s) included ) has been donated to Apache 3 different times and it's all still sitting there on your hard drives ready for you to do whatever the heck you want with it. All of mod_gzip is also now sitting up at SOURCEFORGE free as the wind and under the same 'do whatever you like with this' conditions. > mod_gzip is freely available, and the ASF doesn't need to distribute > it (Remote Communications evangelizes it enough). RCI has nothing do with mod_gzip anymore. mod_gzip is all sitting up on SOURCEFORGE for some time now. > One of the main > reasons for selecting mod_deflate was that it didn't unnecessarily > duplicate code. Less code is better. We don't need to repackage > zlib. I have no desire for us to compete with the zlib maintainers. > We have enough work as-is. -- justin All points well taken. Your points go against the advice of people who actually wrote ZLIB ( Dr. Mark Adler and others ) with regards to anyone who 'distributes' applications that (may) depend on it (ZLIB) but your concerns about how much the Apache Group is able to deal with are well-grounded. Jeff Trawick has already said he thinks including the 'minimal' amount of code neeeded by Apache to do what mod_deflate needs to do in the SRC tree itself would be GOODNESS and would circumvent a lot of build problems/bug reports but therein lies the issue itself. If it comes to a vote I would focus on that one single issue. Forget about mod_gzip's LZ77 engine or any other version of LZ77 that 'could' be used... if the Apache Group isn't even willing to add a minimal subset of ZLIB code to the SRC tree and compile/link against it then there's no use discussing whether that extends to any 'other' compression/decompresion code as well. Yours... Kevin
Re: binbuild.sh favors GNU tar
--On Sunday, November 24, 2002 12:18 PM -0800 Wilfredo Sánchez <[EMAIL PROTECTED]> wrote: So does anyone object if I un-favor GNU tar? Nope. Looks like the real reason we favor it is to use the -z option instead of having to run gzip after the fact. Running gzip in a pipe chain would do as well, though. +1. Don't know how it'd work on Solaris otherwise (since it only has POSIX tar by default). -- justin
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Whoops...not enough sleep :) That should read as R-T-C not C-T-R... I also tend to think this should be applied to the 1.3 tree. david - Original Message - From: "David Reid" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 24, 2002 8:36 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP > Given the recent behavior of some I'm actually now in favour of C-T-R for > any stable tree... > > Treat adults as adults until they prove they can't be so treated. > > +1 for C_T_R for stable branches > > david > > - Original Message - > From: "Jeff Trawick" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, November 24, 2002 2:20 PM > Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP > > > > "Bill Stoddard" <[EMAIL PROTECTED]> writes: > > > > > > I think that R-T-C is the most likely way we'll get good reviews of > > > > code moved to the stable tree. > > > > > > Jeff is speaking from his experience with 2.0 development and I would > have to > > > agree with him in this regard. > > > > I believe that our experiences with 2.0 development (and recent 1.3 > > maintenance) are indicative of what is going to happen with > > 2.0-stable, or at least much more so than any experiences from several > > years ago. > > > > Obviously the interpretation of that experience is subject to debate :) > > > > --/-- > > > > Everybody has their own vision and we have to find the greatest > > commonality to decide how to work. Here are some aspects of mine: > > > > . 1.3 maintenance needs to be a bit healthier... more involvement of > > people when somebody wants to fix something... right now it can be > > hard to get anybody to give a shit when you want to fix > > something... > > > > . 2.0-stable maintenance along the lines of 1.3, but I think that > > fixing things in 2.0-stable is much more important than fixing > > things in 1.3.. 2.0-stable maintenance right now is for the > > relatively few who try 2.x before the hoped-for avalanche, and > > fixing their problems is going to prevent a world of hurt later on > > (1.3 clearly works well-enough for almost anybody) > > > > . 2.1... just like what has happened with 2.0 thus far... > > > > This has nothing to do with C-T-R vs. R-T-C; that is just a choice of > > which crude tool can best be used to achieve a goal. > > > > One of the useful properties of R-T-C is that if you don't have enough > > interest to keep a tree maintained in a healthy manner it becomes > > painfully obvious almost immediately. > > > > -- > > Jeff Trawick | [EMAIL PROTECTED] > > Born in Roswell... married an alien... > > > >
Re: binbuild.sh favors GNU tar
+1 from me. david - Original Message - From: "Wilfredo Sánchez" <[EMAIL PROTECTED]> To: "Apache HTTPD Developers" <[EMAIL PROTECTED]> Sent: Sunday, November 24, 2002 8:18 PM Subject: binbuild.sh favors GNU tar >binbuild.sh seems to prefer gtar to tar for archiving. This doesn't > actually happen on Mac OS X because on Darwin, it's 'gnutar', not > 'gtar'. > >This is trivial to fix, except that I'd rather not use GNU tar if I > don't have to. The reason being that GNU tar generates > non-POSIX-compliant tar archives, which when unpacked with POSIX tar > potentially gives you a bogus @LongLink directory. I'd rather use a > POSIX tar program which both POSIX tar and GNU tar can unpack properly. > The only drawback there is if we have really long path names, POSIX > tar craps out where GNU tar doesn't. I don't think we have really long > path names, though. > >So does anyone object if I un-favor GNU tar? > >Looks like the real reason we favor it is to use the -z option > instead of having to run gzip after the fact. Running gzip in a pipe > chain would do as well, though. > > -wsv > >
Re: karma and cvs commit messages
Agreed. Didn't know we were in the business of screwing ourselves like this... david > > Since we renamed the repository to httpd from httpd-2.0 (there is > > a symlink for now), the CVSROOT/avail file doesn't match > > the repository name, and therefore I can't commit. Can we > > fix that so I can commit to the new "httpd" repository directly? > > Why the heck was that done? Too many things get screwed over > when you change a module name in cvs. > > -1 -- I am reverting that change to cvs. Don't screw with this stuff > without a clear plan in STATUS, and notify apmail and cvsadmin before > screwing with the filesystem. It would have been far more sensible > not to branch 2.0 and instead create a new module that doesn't suffer > from legacy versions. > > Roy
Re: cvs commit: httpd-2.0 STATUS ROADMAP
Given the recent behavior of some I'm actually now in favour of C-T-R for any stable tree... Treat adults as adults until they prove they can't be so treated. +1 for C_T_R for stable branches david - Original Message - From: "Jeff Trawick" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, November 24, 2002 2:20 PM Subject: Re: cvs commit: httpd-2.0 STATUS ROADMAP > "Bill Stoddard" <[EMAIL PROTECTED]> writes: > > > > I think that R-T-C is the most likely way we'll get good reviews of > > > code moved to the stable tree. > > > > Jeff is speaking from his experience with 2.0 development and I would have to > > agree with him in this regard. > > I believe that our experiences with 2.0 development (and recent 1.3 > maintenance) are indicative of what is going to happen with > 2.0-stable, or at least much more so than any experiences from several > years ago. > > Obviously the interpretation of that experience is subject to debate :) > > --/-- > > Everybody has their own vision and we have to find the greatest > commonality to decide how to work. Here are some aspects of mine: > > . 1.3 maintenance needs to be a bit healthier... more involvement of > people when somebody wants to fix something... right now it can be > hard to get anybody to give a shit when you want to fix > something... > > . 2.0-stable maintenance along the lines of 1.3, but I think that > fixing things in 2.0-stable is much more important than fixing > things in 1.3.. 2.0-stable maintenance right now is for the > relatively few who try 2.x before the hoped-for avalanche, and > fixing their problems is going to prevent a world of hurt later on > (1.3 clearly works well-enough for almost anybody) > > . 2.1... just like what has happened with 2.0 thus far... > > This has nothing to do with C-T-R vs. R-T-C; that is just a choice of > which crude tool can best be used to achieve a goal. > > One of the useful properties of R-T-C is that if you don't have enough > interest to keep a tree maintained in a healthy manner it becomes > painfully obvious almost immediately. > > -- > Jeff Trawick | [EMAIL PROTECTED] > Born in Roswell... married an alien... >
Re: karma and cvs commit messages
Agreed 100% This whole episode stinks... david > --On Saturday, November 23, 2002 3:32 PM -0800 "Roy T. Fielding" > <[EMAIL PROTECTED]> wrote: > > >> Since we renamed the repository to httpd from httpd-2.0 (there is > >> a symlink for now), the CVSROOT/avail file doesn't match > >> the repository name, and therefore I can't commit. Can we > >> fix that so I can commit to the new "httpd" repository directly? > > > > Why the heck was that done? Too many things get screwed over > > when you change a module name in cvs. > > Yeah, exactly. We had zero discussion on this change. And, it's a > bad change, IMHO. People shouldn't be making such drastic changes > without some sort of discussion! > > IMHO, httpd-2.0 must always be the definitive repository for Apache > HTTP Server 2.0. If we physically split the 2.1/(2.2/3.0) > repositories, we can then change the name (please discuss this > first). Note that 2.0 shouldn't be housed there, since it once > authoritatively lived in httpd-2.0. ISTR the big snafu when Ken > 'renamed' the httpd-docs repository. That should have warned us that > such moves are a horrible idea. > > I know Subversion has lots of drawbacks (I know of at least 2 > committers who will veto it outright), but remember that branches in > CVS kill performance (really due to the now anachronistic RCS format > and how it stores branches). It's going to be a PITA > performance-wise if we have a long-lived CVS repository. So, I think > there is a strong benefit to creating httpd-2.1 and then httpd-2.2 > and so on. I'm afraid by the time that we hit httpd 2.9 (say), we're > going to be in a world of hurt on the 'stable' branches due to CVS's > inability to scale with active branches. -- justin >
binbuild.sh favors GNU tar
binbuild.sh seems to prefer gtar to tar for archiving. This doesn't actually happen on Mac OS X because on Darwin, it's 'gnutar', not 'gtar'. This is trivial to fix, except that I'd rather not use GNU tar if I don't have to. The reason being that GNU tar generates non-POSIX-compliant tar archives, which when unpacked with POSIX tar potentially gives you a bogus @LongLink directory. I'd rather use a POSIX tar program which both POSIX tar and GNU tar can unpack properly. The only drawback there is if we have really long path names, POSIX tar craps out where GNU tar doesn't. I don't think we have really long path names, though. So does anyone object if I un-favor GNU tar? Looks like the real reason we favor it is to use the -z option instead of having to run gzip after the fact. Running gzip in a pipe chain would do as well, though. -wsv
Re: cvs commit: httpd-2.0 STATUS ROADMAP
"Bill Stoddard" <[EMAIL PROTECTED]> writes: > > I think that R-T-C is the most likely way we'll get good reviews of > > code moved to the stable tree. > > Jeff is speaking from his experience with 2.0 development and I would have to > agree with him in this regard. I believe that our experiences with 2.0 development (and recent 1.3 maintenance) are indicative of what is going to happen with 2.0-stable, or at least much more so than any experiences from several years ago. Obviously the interpretation of that experience is subject to debate :) --/-- Everybody has their own vision and we have to find the greatest commonality to decide how to work. Here are some aspects of mine: . 1.3 maintenance needs to be a bit healthier... more involvement of people when somebody wants to fix something... right now it can be hard to get anybody to give a shit when you want to fix something... . 2.0-stable maintenance along the lines of 1.3, but I think that fixing things in 2.0-stable is much more important than fixing things in 1.3.. 2.0-stable maintenance right now is for the relatively few who try 2.x before the hoped-for avalanche, and fixing their problems is going to prevent a world of hurt later on (1.3 clearly works well-enough for almost anybody) . 2.1... just like what has happened with 2.0 thus far... This has nothing to do with C-T-R vs. R-T-C; that is just a choice of which crude tool can best be used to achieve a goal. One of the useful properties of R-T-C is that if you don't have enough interest to keep a tree maintained in a healthy manner it becomes painfully obvious almost immediately. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: multiple protocols - Patch for listen.c
Date: 23 Nov 2002 08:07:09 -0500 From: Jeff Trawick <[EMAIL PROTECTED]> Martin Kutschker <[EMAIL PROTECTED]> writes: > > Date: Fri, 01 Nov 2002 10:58:04 -0600 > > From: Randall Stewart <[EMAIL PROTECTED]> > > > > > b) TCP and SCTP are both congestion controlled protocols so > > > there should be no threat to the stability of the Big I due > > > to the use of SCTP and http (unlike using http with UDP). > > > > I think that if Apache is to listen on several IPs on different > > ports and now supporting different (low-level) protocols, it is > > reasonable to provide mechanisms to permit certain ports and > > protocols on specific IPs. > > I could go for adding '/' to the end of the current > syntax. In other words, one listen statement continues to map to one > listen_rec and one listening socket. > > Listen 80/sctp > Listen [fe80::1]:80/sctp Looks ok to me. Do you intend to allow something like? Listen 80/tcp/sctp or Listen 80/tcp,sctp This would prohibit the suggest from of Listen 80/sctp [protocol-option ...] which I do happen to like. But I don't know if there are relevant options at all. What are your plans for plain 'Listen 80'? Listen on all protocols, just tcp or some configurable default protocols (eg 'ListenProtocols protocol [protocol ...]') Masi
Re: cvs commit: httpd-site/docs/dev anoncvs.txt devnotes.html how-to-release.html index.html
Sebastian Bergmann wrote: > cvs server: cannot find module `httpd' - ignored > cvs [checkout aborted]: cannot expand modules From http://cvs.apache.org/viewcvs.cgi/ (at the bottom): httpd - this entry is unreadable -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: cvs commit: httpd-site/docs/dev anoncvs.txt devnotes.html how-to-release.html index.html
[EMAIL PROTECTED] wrote: > + user@host:~$ cvs checkout -d httpd-2.0 -r APACHE_2_0_BRANCH httpd e:\home>cvs -z9 -d:pserver:[EMAIL PROTECTED]:/home/cvspublic co -AP -d httpd-2.0 -r APACHE_2_0_BRANCH httpd cvs server: cannot find module `httpd' - ignored cvs [checkout aborted]: cannot expand modules -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: karma and cvs commit messages
--On Saturday, November 23, 2002 3:32 PM -0800 "Roy T. Fielding" <[EMAIL PROTECTED]> wrote: Since we renamed the repository to httpd from httpd-2.0 (there is a symlink for now), the CVSROOT/avail file doesn't match the repository name, and therefore I can't commit. Can we fix that so I can commit to the new "httpd" repository directly? Why the heck was that done? Too many things get screwed over when you change a module name in cvs. Yeah, exactly. We had zero discussion on this change. And, it's a bad change, IMHO. People shouldn't be making such drastic changes without some sort of discussion! IMHO, httpd-2.0 must always be the definitive repository for Apache HTTP Server 2.0. If we physically split the 2.1/(2.2/3.0) repositories, we can then change the name (please discuss this first). Note that 2.0 shouldn't be housed there, since it once authoritatively lived in httpd-2.0. ISTR the big snafu when Ken 'renamed' the httpd-docs repository. That should have warned us that such moves are a horrible idea. I know Subversion has lots of drawbacks (I know of at least 2 committers who will veto it outright), but remember that branches in CVS kill performance (really due to the now anachronistic RCS format and how it stores branches). It's going to be a PITA performance-wise if we have a long-lived CVS repository. So, I think there is a strong benefit to creating httpd-2.1 and then httpd-2.2 and so on. I'm afraid by the time that we hit httpd 2.9 (say), we're going to be in a world of hurt on the 'stable' branches due to CVS's inability to scale with active branches. -- justin
Re: Loading mod_ldap as module fails to link
--On Monday, November 18, 2002 7:36 AM +0200 Graham Leggett <[EMAIL PROTECTED]> wrote: When compiling mod_ldap as a module on Linux, for some reason attempts to load mod_auth_ldap fails like so: [minfrin@jessica httpd-2.0]# /opt/local/apache/bin/apachectl configtest Syntax error on line 242 of /opt/local/apache/conf/httpd.conf: Cannot load /opt/local/apache/modules/mod_auth_ldap.so into server: /opt/local/apache/modules/mod_auth_ldap.so: undefined symbol: util_ldap_connection_close Anyone know why this happens...? As a wild guess, is the util_ldap module not loaded first? -- justin
Re: [PATCH] mod_deflate extensions
--On Friday, November 22, 2002 12:03 PM +0100 Henri Gomez <[EMAIL PROTECTED]> wrote: So we should use a copy of mod_gzip compression code in Apache 2.0. Also as someone involved in mod_jk/jk2, I'll need gzip compress/uncompress support in Apache 2.0 for a new ajp protocol I'm working on, so having compression/uncompression in Apache 2.0 will be mandatory for me. No, we shouldn't be including zlib code (or any variant) in our distribution. That's not our responsibility. It's also not important enough for us to further bloat our code just because an insignificant number of distributions haven't provided a good package of zlib. If it's that important, those administrators can build their own zlib or just not use any functionality requiring zlib. The point here is that no functionality is lost if zlib is missing. (And, if you are doing a mod_jk, zlib support should be optional not mandatory.) Ok, let be pragmatic. Did Apache HTTP developpers agree that compression should be added in Apache 2.0 by incorporating mod_gzip comp code in Apache 2.0 ? mod_deflate is already there and it uses an external zlib library, so I'm confused why we should also provide mod_gzip and/or its proprietary compression code. mod_gzip is freely available, and the ASF doesn't need to distribute it (Remote Communications evangelizes it enough). One of the main reasons for selecting mod_deflate was that it didn't unnecessarily duplicate code. Less code is better. We don't need to repackage zlib. I have no desire for us to compete with the zlib maintainers. We have enough work as-is. -- justin
Re: cvs commit: httpd-site/docs/dev anoncvs.txt devnotes.htmlhow-to-release.html
--On Saturday, November 23, 2002 7:28 PM + [EMAIL PROTECTED] wrote: wrowe 2002/11/23 11:28:42 Modified:docs/dev anoncvs.txt devnotes.html how-to-release.html Log: Reflect the commands for the APACHE_2_0_BRANCH split. Umm, shouldn't these changes have been committed to xdocs/dev not docs/dev? docs/dev is liable to be overriden at any time. -- justin
