You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brad Nicholes <BN...@novell.com> on 2005/03/29 20:22:59 UTC

So what is the real status of 2.1.x...

The STATUS file says:

    2.1.4   : in development
    2.1.3   : Released on  2/22/2005 as alpha.

The ap_release.h header file says:

   2.1.5-dev

The distribution page /dist/httpd says:

   httpd-2.1.3-beta.tar.gz


Are we BETA yet or not?  I am assuming that the true status is:

- httpd-2.1.3-beta.tar.gz - should really be ALPHA
- STATUS file needs to be updated to 
    2.1.5   : in development
    2.1.4   : pending BETA released
    2.1.3   : Released on  2/22/2005 as alpha.
- ap_release.h - no change.

Am I missing something?

Brad



Re: So what is the real status of 2.1.x...

Posted by "Roy T. Fielding" <fi...@gbiv.com>.
>>     2.1.3   : Released on  2/22/2005 as alpha.
>
> It had enough votes for beta, but I am not sure on the RM's decision.

It isn't the RM's decision.  A majority vote of the PMC is a decision
to release provided there are at least three +1s.  The RM is just the
person doing the heavy lifting.

....Roy


Re: So what is the real status of 2.1.x...

Posted by Paul Querna <ch...@force-elite.com>.
Brad Nicholes wrote:
> The STATUS file says:
> 
>     2.1.4   : in development

I was tagged as alpha.  It sort of died, because of problems in 
apr-iconv.  The Status file should be updated.

>     2.1.3   : Released on  2/22/2005 as alpha.

It had enough votes for beta, but I am not sure on the RM's decision. 
Either way, the Status file should be updated.

> 
> The ap_release.h header file says:
> 
>    2.1.5-dev

This is correct. Look at:

http://svn.apache.org/repos/asf/httpd/httpd/tags/

Once Tagged, you should bump the ap_release.h to the next revision for 
/trunk/.


Re: So what is the real status of 2.1.x...

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:32 AM 3/30/2005, Jeff Trawick wrote:
>On Tue, 29 Mar 2005 17:41:31 -0600, William A. Rowe, Jr.
><wr...@rowe-clan.net> wrote:
>
>> I would also propose we drop apr_xlate and mod_charset_lite if the
>> only way to support this is GNU iconv, which incompatible with the
>> ASL.
>
>Various platforms have non-GNU iconv() which is suitiable for use by
>this apr and httpd code.  Most of my original testing was done with
>native, non-GNU iconv() on z/OS and Solaris.

Yes.  The issue is, there (was) no maintainer for that code for some
years.  It was rather DOA.  There has been traction by Alexander 
(bland at freebsd) to re-support the Konstantin code.  The newlib folk
ported Konstantin's 2.0 code as well.  Konstantin's mirror is now down
and his code is no longer (directly) available.  So we end up with 
three groups using the same implementation, but no common ground yet.  
I hope this will change (very shortly.)

>Just curious: Suppose we're talking about Linux, which provides GNU
>strcpy() and GNU iconv().  What is the difference with using one vs.
>the other?  Is your concern limited to those platforms which don't
>provide iconv() out of the box, and where users may feel inclined to
>install GNU iconv() in order to use the APR and/or Apache feature?

Nothing.  strcpy() is part of ANSI, C99 etc so we trust it's there.
iconv() is a new gcc addition (at least, to clib) and while good,
we don't have a non-GNU solution.

We don't object to users plugging in GNU libiconv.  Nor should we.
But we won't distribute it, and should not require it.  Therefore
we have an issue when no alternative exists.

As the introduction of the Euro symbol demonstrates, code pages 
-do- change over time, so an orphaned solution is no solution.

Bill 


Re: So what is the real status of 2.1.x...

Posted by Jeff Trawick <tr...@gmail.com>.
On Tue, 29 Mar 2005 17:41:31 -0600, William A. Rowe, Jr.
<wr...@rowe-clan.net> wrote:

> I would also propose we drop apr_xlate and mod_charset_lite if the
> only way to support this is GNU iconv, which incompatible with the
> ASL.

Various platforms have non-GNU iconv() which is suitiable for use by
this apr and httpd code.  Most of my original testing was done with
native, non-GNU iconv() on z/OS and Solaris.

Just curious: Suppose we're talking about Linux, which provides GNU
strcpy() and GNU iconv().  What is the difference with using one vs.
the other?  Is your concern limited to those platforms which don't
provide iconv() out of the box, and where users may feel inclined to
install GNU iconv() in order to use the APR and/or Apache feature?

Re: So what is the real status of 2.1.x...

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:08 PM 3/29/2005, Roy T.Fielding wrote:
>On Mar 29, 2005, at 1:36 PM, William A. Rowe, Jr. wrote
>
>Bill, why don't you just fix whatever it is that you think of as
>broken rather than send negative votes?

The last release simply came to quickly between announce of the
intent and the tarball.  As I say they most *all* are fixed now,
and were fixed the evening before the tarball was expected to have
been rolled.

except for apr-iconv which the few commentors are at disagreement.
I stopped to explain the right solution to the apr@ list, which 
I will then commit tomorrow barring any reasonable objections.

So plan is patch Wednesday afternoon, tar and vote on apr for the
apr-iconv release.  Release as early as Thursday if we have 3+1's
and httpd will have a new release to roll into 2.1.(5?)

>If you think this is a showstopper, then I have no problem removing
>win32 from the list of supported platforms for Apache httpd -- in my
>opinion, that community of users is too lazy to support their own
>platform and we (as a project) cannot continue to rely on one person
>to do all of the necessary work to keep it up to date.

Little disagreement here but perhaps overreacting.  If this is your
wish propose it for a vote.

>I see no reason to treat Win32 as any more significant than Irix, 
>at least not until we have a group of dedicated developers who care 
>enough about that platform to keep up with its never-ending baggage 
>of broken system libraries and compilers.

Wholeheartedly agree.  While I see enough traffic to know that many
build on Win32 (for ssl, or module development, or whatever), but
we know we don't see traffic to this list of other Win32 folks
contributing.  I can count on one hand how many Win32-centric
contributors there are to httpd + apr, and on two hands how many 
have become proficient at 'stubbing in' new modules into the win32 
build.

I was pleasantly shocked and amazed in the cli-dev community to find
a user who pointed out an issue, and then, proposed the fix!  This
is reassuring, perhaps the developers on the mod_aspdotnet side will
find it productive to offer httpd code fixes back to our project
when they discover httpd bugs.  There are now about three not-Bill's 
contribute some diagnostics of the source code along with their problem 
reports.  I hope several will stick around to become project members 
over the next few months.

I just wonder if, as a % of users, are the Win32 users really that
less contributing than, say linux users?  Count the total number 
of folks running a linux server, divide by the number who have 
posted some code contribution to dev@httpd.  Do the same for Win32.
I'd suspect the difference isn't as great as you might imagine.

>It terms of technical issues, APR has no business shipping an
>implementation of iconv and I don't care if whatever is in that
>directory can't compile -- if it isn't supported, then delete iconv
>from APR and let people install it separately.

I agree, and propose we remove pcre (from 2.0), regex (from 1.3)
and expat (from apr).  It doesn't mean we can't/won't provide the
binary builds, built from the current stable release provided by 
those projects, when appropriate.  Just as we do today for zlib 
(on win32, we ship the library built from zlib 1.1.4 src.)

But these don't belong in our tree.  Any disagreement?

I would also propose we drop apr_xlate and mod_charset_lite if the 
only way to support this is GNU iconv, which incompatible with the 
ASL.  However, as I mention I'm looking for some traction for
a supported BSD-licensed version.  FreeBSD has a new platform
maintainer for that package, the newlib folks adopted it, so I'm
hoping a community can be reformed around that code.

Bill


Re: So what is the real status of 2.1.x...

Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Mar 29, 2005, at 1:36 PM, William A. Rowe, Jr. wrote:
>> 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.

Bill, why don't you just fix whatever it is that you think of as
broken rather than send negative votes?  It can't possibly take
as long as this to patch a bug, so maybe there is no bug to be
patched, or the patch requires too much effort to consider, or
you are simply too busy arguing about it to supply a fix?  Pick
one and solve it -- nobody here is going to stop you from fixing
a bug in APR.

If you think this is a showstopper, then I have no problem removing
win32 from the list of supported platforms for Apache httpd -- in my
opinion, that community of users is too lazy to support their own
platform and we (as a project) cannot continue to rely on one person
to do all of the necessary work to keep it up to date.  I see no
reason to treat Win32 as any more significant than Irix, at least not
until we have a group of dedicated developers who care enough about
that platform to keep up with its never-ending baggage of broken
system libraries and compilers.

It terms of technical issues, APR has no business shipping an
implementation of iconv and I don't care if whatever is in that
directory can't compile -- if it isn't supported, then delete iconv
from APR and let people install it separately.

Meanwhile, please end the paranoid crap you keep shoveling
about Justin doing this or Justin doing that.  He is following
the guidelines and trying to make progress while at the same
time trying to make sense of your cryptic problem reports and
not step on any toes.  At some point we have to stop trying to
reach consensus on every platform and just make progress on
those platforms with bodies to support them.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>


Re: So what is the real status of 2.1.x...

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:40 PM 3/29/2005, Justin Erenkrantz wrote:
>--On Tuesday, March 29, 2005 11:22 AM -0700 Brad Nicholes <BN...@novell.com> 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 dev@httpd 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.


Re: So what is the real status of 2.1.x...

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, March 29, 2005 11:22 AM -0700 Brad Nicholes 
<BN...@novell.com> 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.

My current understanding is that OtherBill's -1 has some thing to do with 
APR-iconv and nothing at all with httpd.  As such, there's absolutely 
nothing dev@httpd can do 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.

I'm frankly very tired of shooting at moving targets and trying to persuade 
folks that we should have entered beta when we have committers looking for 
excuses to prevent us from making forward progress.  Hence, any desire that 
I had to see 2.2 start the release cycle is diminished because I don't have 
time for more arguments as to why we should start the beta cycle.

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