Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote: > Paul Querna wrote: > > Vote Results: > >+1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson, > >+1: Gregg Smith > > +/-0: Rainer Jung > > -1: William A. Rowe, Jr. > > > > Vote passes. > > I'm sorry. I explicitly insisted on a vote on the -deps package seperately > from the 2.3.4 package, because it was entirely reasonable that Sander Temme, > Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the > httpd-2.3.4-alpha.tar.xx package alone. I've no issue at all with the -deps tarball containing a snapshot of APR: 1) the httpd project cannot force the APR project to commit to API stability by distributing a snapshot of the APR 1.4 branch. Why on earth would that be the case? The only time the APR project commits to API stability is by making a new .0 release itself. What other projects do is irrelevant to APR. 2) the httpd project isn't taking on any commitment to itself maintain API stability in the shipped APR snapshot because *this is an alpha*, so we're not guaranteeing API stability. Furthermore I don't think it's a good idea to set a precedent of requiring a separate vote on each file which makes up "the release". I certainly presumed that the vote Paul called was for all the files making up "the release". Regards, Joe
Re: [mod_fcgid] Feedback / Suggestions
Eric Covener wrote: On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fastcgi has supported this for many years: http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator It does not work or I'd have used it. And I tried to make it work. There is a lot of missing code, compare to mod_fcgid implementation of the same. Barry
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr. wrote: > Jeff Trawick wrote: >> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. >> wrote: >> >>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the >>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release >>> forwards. >> >> The APR versioning rules are hopelessly broken if a tarball snapshot >> of the 1.4.x branch before a GA release casts the API in stone. >> >> Surely I misunderstood you. > > Is there a README indicating that the MAJOR/MINOR version tests for this > particular tarball are not relevant/complete? No. > > This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release. > You surely don't misunderstand what I said. Why is something with version x.y.z-dev a release and not a snapshot? > As for broken versioning rules, please take that to APR. > > Perhaps in retrospect, APR would consider an even/odds approach as httpd > has for adding (even eliminating) interfaces during a development cycle. IMO the determination could be as simple as whether or not a release in the maj.min series has yet been declared GA.
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
William A. Rowe Jr. wrote: > The last I heard, the 'rpm' project is open source, free to be adopted by > any platform. Just because rpm is free to be adopted by any platform doesn't mean it has been. Rpm contains features that allow the spec file to tailor itself to its build environment, and I am confident those features would kick in if someone was to try and create an rpm package tailored for an environment other than a Redhat derivative. > As for the rest of your comments, if we solve the general problem, I'm all > for including it in the httpd tree. If we are solving specific packagers > problems, I'm ok with placing this in the httpd.a.o domain, but we should > move this nonsense outside of the development tree into a packaging tree. And in turn violate the principle of least surprise. The point behind support for packaging formats is to make the end user's life easier, not harder. Packagers that create weird, non standard, or unexpectedly complex packaging are not doing their users any favours. Regards, Graham --
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On Fri, Dec 4, 2009 at 12:59 AM, Graham Leggett wrote: > William A. Rowe Jr. wrote: > >> Ok, so they want to roll their own. Sounds like a maintainer issue. What >> does this say for using our httpd rpm for an Ubuntu or other distribution >> of linux? > > Ubuntu is Debian based, and uses the .deb packaging format, and startup > scripts derived from the Debian layout. If someone was to donate debian > packaging for httpd, I would expect one or two files to appear below > build/deb, and that would be all that would be needed. > >> IMHO, if it is fundamentally incompatible with apachectl and non-redhat >> distributions, let the the packagers tweak and take the zany customizations >> out from under our problem set. > > Apachectl is archaic and largely broken for most people - it made sense > ten years ago, it makes a lot less sense today. Really? It works perfectly on all boxes I use it on. What precisely has changed about reading a pid from a file, sending signals to a process, or spawning a process with specific arguments that has made apachectl 'archaic and largely broken', I am intrigued. > > The pattern followed by most modern unix based packaging is for an > application to drop a snippet of config contained in a discrete file in > a directory ending in ".d". So you have > /etc/httpd/conf.d/.conf, instead of a manual edit to > /etc/httpd/conf/httpd.conf, and your httpd startup goes within an > optional script called /etc/sysconfig/httpd instead of in a script file > in a bin directory as apachectl wants. I understand Debian has different > naming conventions, but otherwise the underlying principles are the same. Did you mean to say 'most Linux' there? The OSes that I regularly use do not display these redhatisms. > > In our case, we package up config files within standalone RPMs all of > their own (suitably tagged and versioned), or we generate the config > file using puppet. Editing a file in place is always painful and error > prone, it is far less painful to provide a discrete file that can be > dropped in and removed cleanly. Apachectl doesn't give us this - you > need to edit apachectl directly to modify the command line parameters > passed to httpd. > > As for the packagers tweaking and making zany customisations, that is > exactly what they do now. For us it makes the their packaging unsuitable > for our needs, simply because we tweak and make zany customisations for > needs of our own. It is far less painful to take a vanilla RPM published > by the ASF, and then tweak it for our needs, than it is to take a Fedora > RPM, untweak all their customisations, and then retweak it with ours. > Ah so now the crux of your argument: 1) I use Fedora/RHEL 2) I want customized packages to install 3) Fedora/RHEL package their RPMs in such a way that it makes it difficult for me to modify them. It's much easier when you just say this up front. Cheers Tom
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
Tom Evans wrote: > Really? It works perfectly on all boxes I use it on. What precisely > has changed about reading a pid from a file, sending signals to a > process, or spawning a process with specific arguments that has made > apachectl 'archaic and largely broken', I am intrigued. And if you have ten boxes? 50 boxes? A Google of boxes? Editing a file in place has long been shown to be a maintenance nightmare, which is why in addition to logrotate.conf you have logrotate.d, in addition to modprobe.conf you have modprobe.d, and so on. This is a pattern long since established in modern unix distributions, to solve the problem of the need to edit files during a software addition, and edit files again during software removal, all without making mistakes. Sure, if you are used to editing config files by hand on one or two boxes, apachectl will meet your needs, but if you do anything that requires a level of scale doing it this way won't. Regards, Graham --
Re: [mod_fcgid] Feedback / Suggestions
On 12/4/09, Barry Scott wrote: > Eric Covener wrote: > > > On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott > wrote: > > > > > > > Jeff Trawick wrote: > > > > > > > > > > On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank > wrote: > > > > > > > > In the interim, is mod_fastcgi really that bad? > > > > > > > > > > > > > > > mod_fastcgi is fine for handling GET/POST requests, but it fails to > > > implement > > > Authorization or Authenication. > > > > > > So yes mod_fastcgi is really bad. > > > > > > > > > > mod_fastcgi has supported this for many years: > > > > http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer > > > http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator > > > > > > > It does not work or I'd have used it. And I tried to make it work. > There is a lot of missing code, compare to mod_fcgid implementation > of the same. Simple tests work for me. -- Eric Covener cove...@gmail.com
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On Fri, Dec 4, 2009 at 12:37 PM, Graham Leggett wrote: > Tom Evans wrote: > >> Really? It works perfectly on all boxes I use it on. What precisely >> has changed about reading a pid from a file, sending signals to a >> process, or spawning a process with specific arguments that has made >> apachectl 'archaic and largely broken', I am intrigued. > > And if you have ten boxes? 50 boxes? A Google of boxes? > > Editing a file in place has long been shown to be a maintenance > nightmare, which is why in addition to logrotate.conf you have > logrotate.d, in addition to modprobe.conf you have modprobe.d, and so > on. This is a pattern long since established in modern unix > distributions, to solve the problem of the need to edit files during a > software addition, and edit files again during software removal, all > without making mistakes. > > Sure, if you are used to editing config files by hand on one or two > boxes, apachectl will meet your needs, but if you do anything that > requires a level of scale doing it this way won't. > > Regards, > Graham > -- > Sorry, what has apachectl got to do with editing files? What has using apachectl to stop/start a service got to do with scalability? You've completely lost me here. At $JOB we have 200+ servers, all deployed and configured via cfengine. apachectl is still used to stop/start the servers, via cfengine and other CM tools. Cheers Tom
Re: svn commit: r885606 - /httpd/httpd/trunk/build/rpm/httpd.init
On 12/4/09, Tom Evans wrote: > Sorry, what has apachectl got to do with editing files? What has using > apachectl to stop/start a service got to do with scalability? You've > completely lost me here. The only practical thing i can think of is OS vendors providing separate worker and prefork binaries. The standard apachectl has the binary name embedded in it, although there are a host of ways to accomodate that. -- Eric Covener cove...@gmail.com
Re: [mod_fcgid] Feedback / Suggestions
Eric Covener wrote: On 12/4/09, Barry Scott wrote: Eric Covener wrote: On Thu, Dec 3, 2009 at 5:57 AM, Barry Scott wrote: Jeff Trawick wrote: On Tue, Nov 24, 2009 at 10:05 AM, Edgar Frank wrote: In the interim, is mod_fastcgi really that bad? mod_fastcgi is fine for handling GET/POST requests, but it fails to implement Authorization or Authenication. So yes mod_fastcgi is really bad. mod_fastcgi has supported this for many years: http://www.fastcgi.com/drupal/node/25#FastCgiAuthorizer http://www.fastcgi.com/drupal/node/25#FastCgiAuthenticator It does not work or I'd have used it. And I tried to make it work. There is a lot of missing code, compare to mod_fcgid implementation of the same. Simple tests work for me. Hmm, Then I must have got something wrong when I tried to get this working, or you have patches I don't. When I looked at the sources and compared to mod_fcgid it looked like there was code missing. It's too long ago now for me to recall the details to discuss. Barry
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Jeff Trawick wrote: > On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr. > wrote: >> Jeff Trawick wrote: >>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. >>> wrote: >>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the apr-util 1.4.0 dev, and the API versioning rules will bind from that release forwards. >>> The APR versioning rules are hopelessly broken if a tarball snapshot >>> of the 1.4.x branch before a GA release casts the API in stone. >>> >>> Surely I misunderstood you. >> Is there a README indicating that the MAJOR/MINOR version tests for this >> particular tarball are not relevant/complete? No. >> >> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release. >> You surely don't misunderstand what I said. > > Why is something with version x.y.z-dev a release and not a snapshot? Because snapshots don't live at http://www.apache.org/dist/, those are releases. The trigger didn't occur until Paul svn mv'ed it into there. Snapshots reside at http://svn.apache.org/snapshots/ >> As for broken versioning rules, please take that to APR. >> >> Perhaps in retrospect, APR would consider an even/odds approach as httpd >> has for adding (even eliminating) interfaces during a development cycle. > > IMO the determination could be as simple as whether or not a release > in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Jeff Trawick wrote: > On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr. > >> As for broken versioning rules, please take that to APR. >> >> Perhaps in retrospect, APR would consider an even/odds approach as httpd >> has for adding (even eliminating) interfaces during a development cycle. > > IMO the determination could be as simple as whether or not a release > in the maj.min series has yet been declared GA. Not sufficient, IMHO, unless we add the appropriate indicators to allow feature tests in apr 2.0. E.g. the current test is VERSION_MAJOR >= 1 && VERSION_MINOR >= 4 and the APR versioning contract says that test is always sufficient. This dialog reads like folks may assume the httpd MMN feature tests work for APR functions, but there isn't such a feature test in APR.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Paul Querna wrote: > Vote Results: >+1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson, >+1: Gregg Smith > +/-0: Rainer Jung > -1: William A. Rowe, Jr. > > Vote passes. > > I'll push out the tarballs to start getting mirrors, and hack on an > announcement email for tomorrow. Oh - looking forward to the announce; the damage occured the moment you had pushed to /dist/httpd/, we don't un-release software, and any old arguments are over about the wisdom of releasing the -deps package. Except of course, we need to finish the discussion of *adding* PCRE, but that should never stop an alpha release. In the meantime I'm pushing forwards on apr-1.4.1 since testing for subversion 0 won't indicate if the APR_STATUS_IS_ENOTDIR had been fixed (for anyone looking for min revlevel checks), and once that is done, perhaps someone else wants to advocate for releasing apr-util-1.4.0. But AFAIK apr-util 1.4.0 is not a prerequisite for httpd 2.3 alphas just yet, it is an optional requirement for the scache module.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Joe Orton wrote: > On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote: >> Paul Querna wrote: >>> Vote Results: >>>+1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson, >>>+1: Gregg Smith >>> +/-0: Rainer Jung >>> -1: William A. Rowe, Jr. >>> >>> Vote passes. >> I'm sorry. I explicitly insisted on a vote on the -deps package seperately >> from the 2.3.4 package, because it was entirely reasonable that Sander Temme, >> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the >> httpd-2.3.4-alpha.tar.xx package alone. > > I've no issue at all with the -deps tarball containing a snapshot of > APR: > > 1) the httpd project cannot force the APR project to commit to API > stability by distributing a snapshot of the APR 1.4 branch. Why on > earth would that be the case? The only time the APR project commits to > API stability is by making a new .0 release itself. What other projects > do is irrelevant to APR. Joe, as I pointed out in another thread, httpd *does* commit apr the moment the mislabeled artifact hits www.apache.org/dist/ - where does that package suggest it is nothing but a snapshot? The answer is, it doesn't. When we did this previously in httpd 2.0 (never 2.1 to the best of my recollection) we actually did commit to that particular apr API. The rules in 0.9 just weren't so draconian. If you don't like any of these rules; * what is on /dist/ is a release * what is released apr >= 1.0 follows absolute versioning rules * what is a snapshot doesn't appear on /dist/ then take those issues to an infra/board level. We've had these discussions a thousand times on incubator lists, and this is a clear case of what is good for the goose... > 2) the httpd project isn't taking on any commitment to itself maintain > API stability in the shipped APR snapshot because *this is an alpha*, so > we're not guaranteeing API stability. Nope, much like broken ldap and crypto interfaces, it simply inflicts them upon apr and hopes for someone else to clean up the junk later, perhaps. But the apr project would be remiss in not voiding 1.4.x and moving on to 1.5.x for API additions since users can now be reasonably expected to have installed an apr 1.4.x major/minor with a specific feature set. > Furthermore I don't think it's a good idea to set a precedent of > requiring a separate vote on each file which makes up "the release". I > certainly presumed that the vote Paul called was for all the files > making up "the release". Nonsense. I post up httpd win32 binaries all the time to /dev/dist/. Do I really think everyone voting on the source code snapshot of httpd is paying any attention to that artifact (or this new -deps artifact, when all the deps are already provisioned on most voter's machines)?
Re: [VOTE] Release httpd 2.3.4-alpha
Niklas Edmundsson wrote: On Mon, 30 Nov 2009, William A. Rowe Jr. wrote: Look, PCRE is a mandatory component. APR is a mandatory component. Let's please start applying some rhyme to our reasoning again. +1 +1 a good write up. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
