At 12:40 PM 3/29/2005, Justin Erenkrantz wrote: >--On Tuesday, March 29, 2005 11:22 AM -0700 Brad Nicholes <[EMAIL PROTECTED]> >wrote: > >>Are we BETA yet or not? I am assuming that the true status is: > >OtherBill has consistently repeated that he will -1 anything entering beta. >So, until he resolves his issues, we're at a standstill.
Well, this beta/nobeta decision is a non-technical vote. So no, not a standstill, per say. Yes my vote was -1 on 2.1.3, both as a tarball, and a beta candidate. >My current understanding is that OtherBill's -1 has some thing >to do with APR-iconv and nothing at all with httpd. Yes, iconv is the final significant issue I have with a beta in principal. However... I also had a -host- of issues with 2.1.3, especially pcre changes, which I have fixed on svn trunk. So I was -1 for 2.1.3, period. If 2.1.3 included the old pcre, why release it? If it included those pcre changes, they needed to actually build. As of my last test, httpd trunk + apr 1.1.x trunk built clean. Note that there were other apr / apr-util issues, but I believe all of the remaining bullets except apr-iconv are closed. I'll take action today on the apr list to ensure we have some resolution by Friday, such that another tarball could be created, voted, and perhaps, voted to beta. Technical question; did we decide it's 2.1.x-beta, or 2.2.0-beta? >As such, there's absolutely nothing [EMAIL PROTECTED] can do httpd has been doing fine... > to remove his -1. Every time I have tried to remove his stated >arguments against going beta (I lost count at 4 different rationales >against beta), OtherBill suddenly presents more arguments as to why >httpd can't enter beta. Justin, your answer was, with several specific problems to solve, to shove a tarball down our throats. Screw that. Good way to ensure my -1 your every attempt. But that's not my purpose, the only rational for my voting is, is the candidate for beta the best version of httpd available. I think we made some missteps, that the first httpd 2.0 beta and release could and should have been a bit more robust. I think we lost face with 2.0's early release, and have succeeded in regaining it. I want to avoid repeating that misstep and increase our users' confidence. Yes, I believe the candidate today falls short. I believe that we have several fundamental 2.0-specific issues to address. And like you, I've given up, only I've given up that these will make it into 2.2. Such things as more specific filtering semantics to order filter behavior, etc. So my only remaining objections are on specifics, and only those that should -not- change after beta. That includes the API and which apr we build from. One, is the use of iconv. I'm frankly ready to propose we dump it; it's widely supported only under the GPL, the FreeBSD port that GNU 'borrowed' is close to death. I'm hoping to change that. And I think there is a better proposal to be offered, which I'm tossing to apr this afternoon. Two, are two Win32 mechanical questions, which I'll toss at the list under a separate note. Would be a 15 minute project. >I still maintain that the current state of trunk is sufficient to branch off >2.2.x (keeping the branch version at 2.1.x until we go GA with 2.2.0) and >consequently bump trunk to 2.3.x today. -- justin And I still see no reason to do that until we vote 2.2.0-beta, until the day you want to commit something for the 2.4 (or even for the 3.0 track). Just as soon as you have anything that fits that criteria, seems perfectly rational to just jump into svn and create the new branch. Copies are cheap, no? Seems the biggest sticking point is the existence of /trunk, and what it means. I'd have no objection to getting rid of that stale concept entirely :) By all means, fork branches/2.3 today.
