You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/07/18 18:58:21 UTC
Re: svn commit: r219520 - /httpd/httpd/branches/2.2.x/
Thanks Paul, you just collided with the refactoring of 2.1.x proxy.
Thank you for not announcing this first.
Thank you for ignoring the entire user community in your zeal
to move forward with ... what?
Thank you for helping the entire dev community begin refactoring
httpd 2.3 long before there is a 2.2 release to begin committing
... what?
I see nothing going on in trunk that jeopardizes 2.2, I see alot
of things that are unstable in 2.1-dev, and 2.1-dev is NOT BETA.
The simplest thing I guess, going forward, since we all have the
right to branch and copy as we will on dev, is to simply svn cp
over your old work every time we feel like it. There is no way
you are declaring httpd-2.2 C-T-R yet, although that's what 2.2
should be once branched.
Bill
At 10:50 AM 7/18/2005, pquerna@apache.org wrote:
>Author: pquerna
>Date: Mon Jul 18 08:50:36 2005
>New Revision: 219520
>
>URL: http://svn.apache.org/viewcvs?rev=219520&view=rev
>Log:
>Branch 2.2.x from trunk.
>
>Added:
> httpd/httpd/branches/2.2.x/
> - copied from r219519, httpd/httpd/trunk/
Re: svn commit: r219520 - /httpd/httpd/branches/2.2.x/
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:43 AM 7/20/2005, Joe Orton wrote:
>Is this refactoring complete? Apart from the compiler warnings, a bunch
>of the t/ssl/proxy.t tests have started failing with the trunk code.
>With worker, the server is dumping core:
>
>(this seems to be a regression since 2005-07-15, when all the tests were
>passing with both prefork and worker)
Hmmm. The perl-framework doesn't generate any cores against
2.0.x with my proposed patches (backport of this refactoring)...
I'm guessing it's a subtle bug in the bucket or brigade allocation
if this is specific to the patch. But because only this single
case actually segfaults for you, I'm concerned we might have found
an edge case elsewhere in the code.
>#2 apr_pool_clear (pool=0x0) at memory/unix/apr_pools.c:332
> freelist = (apr_memnode_t *) 0x0
> max_index = 2
> max_free_index = 0
> next = (apr_memnode_t *) 0x56a3e8
> index = 0
> current_free_index = 4294967295
Evidently an allocation issue... since we don't touch the issue
until we hit the cleanups.
>#4 0x0000002a97de95a6 in ap_proxy_release_connection (proxy_function=0x56a3e8 "\001", conn=0x809cd8, s=0x0) at
>proxy_util.c:1714
>No locals.
>#5 0x0000002a980fd6c8 in ap_proxy_http_cleanup (scheme=0x0, r=0x89e4d8,
> backend=0x809cd8) at mod_proxy_http.c:1525
>No locals.
>#6 0x0000002a980fe910 in proxy_http_handler (r=0x89e4d8,
>worker=0x5a0328,
> conf=0x878b88, url=0x891168 "/require-ssl-cgi/env.pl", proxyname=0x0,
> proxyport=0) at mod_proxy_http.c:1162
> here = (struct apr_bucket *) 0x0
> status = 0
> server_portstr = ":8541\000\000\000Húj\225*\000\000\000ÿÿÿÿ\000\000\000\000\210\213\207\000\000\000\000"
> scheme = 0x0
> proxy_function = 0x2a980fee00 "HTTPS"
> u = 0x0
> backend = (proxy_conn_rec *) 0x809cd8
> is_ssl = 1
> p = (apr_pool_t *) 0x8903f8
> uri = (apr_uri_t *) 0x8910a8
I'm going to spend some time this afternoon in the perl-framework,
see what I can come up with.
Bill
Re: svn commit: r219520 - /httpd/httpd/branches/2.2.x/
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Jul 18, 2005 at 11:58:21AM -0500, William Rowe wrote:
> Thanks Paul, you just collided with the refactoring of 2.1.x proxy.
Is this refactoring complete? Apart from the compiler warnings, a bunch
of the t/ssl/proxy.t tests have started failing with the trunk code.
With worker, the server is dumping core:
(this seems to be a regression since 2005-07-15, when all the tests were
passing with both prefork and worker)
Core was generated by `/tmp/regressk13532/trunk-worker-root/bin/httpd -d
/tmp/regressk13532/pf-trunk-w'.
Program terminated with signal 11, Segmentation fault.
[...omitting other threads...]
#0 0x00000032e452e989 in kill () from /lib64/tls/libc.so.6
No symbol table info available.
#1 <signal handler called>
No symbol table info available.
#2 apr_pool_clear (pool=0x0) at memory/unix/apr_pools.c:332
freelist = (apr_memnode_t *) 0x0
max_index = 2
max_free_index = 0
next = (apr_memnode_t *) 0x56a3e8
index = 0
current_free_index = 4294967295
#3 0x0000002a97de8e31 in connection_cleanup (theconn=0x56a3e8) at proxy_util.c:1456
p = (apr_pool_t *) 0x80db08
conn = (proxy_conn_rec *) 0x809cd8
worker = (proxy_worker *) 0x5a0328
#4 0x0000002a97de95a6 in ap_proxy_release_connection (proxy_function=0x56a3e8 "\001", conn=0x809cd8, s=0x0) at
proxy_util.c:1714
No locals.
#5 0x0000002a980fd6c8 in ap_proxy_http_cleanup (scheme=0x0, r=0x89e4d8,
backend=0x809cd8) at mod_proxy_http.c:1525
No locals.
#6 0x0000002a980fe910 in proxy_http_handler (r=0x89e4d8,
worker=0x5a0328,
conf=0x878b88, url=0x891168 "/require-ssl-cgi/env.pl", proxyname=0x0,
proxyport=0) at mod_proxy_http.c:1162
here = (struct apr_bucket *) 0x0
status = 0
server_portstr = ":8541\000\000\000Húj\225*\000\000\000ÿÿÿÿ\000\000\000\000\210\213\207\000\000\000\000"
scheme = 0x0
proxy_function = 0x2a980fee00 "HTTPS"
u = 0x0
backend = (proxy_conn_rec *) 0x809cd8
is_ssl = 1
p = (apr_pool_t *) 0x8903f8
uri = (apr_uri_t *) 0x8910a8
#7 0x0000002a97de3786 in proxy_run_scheme_handler (r=0x89e4d8,
worker=0x5a0328, conf=0x878b88,
url=0x8a0066
"https://localhost.localdomain:8532/require-ssl-cgi/env.pl",
proxyhost=0x0, proxyport=0) at mod_proxy.c:1890
pHook = (proxy_LINK_scheme_handler_t *) 0x589448
n = 0
rv = 0
Re: [vote] Revoke R-T-C [was: svn commit: r219520]
Posted by Sander Striker <st...@apache.org>.
William A. Rowe, Jr. wrote:
> At 12:51 PM 7/18/2005, Roy T. Fielding wrote:
>
>
>>Or you could simply keep working on trunk like everyone else
>>and let releases be made when a tarball gets three +1s.
>>Version numbers are cheap. Telling the entire group to stop while
>>you work on the next big patch is extremely expensive.
>
>
> Ok, so we are now three levels deep?
>
> /trunk
>
> C-T-R
>
> /branches/2.2.x [misnomer, we don't have a beta yet]
>
> R-T-C ? If not now, when?
>
> /branches/2.0.x
>
> R-T-C
There should be natural migration to 2.2.x. 2.0.x should be
considered closed for new features, that's what the development
line is for.
> Triple commits to fix one, one-line segfault? Well, this isn't
> workable. I think lack of progress shows it's not workable.
The lack of progress is not due to having to commit to multiple
branches.
> Some of us, trawick, orton and myself come to mind, are still up
> for supporting our current users.
You make it sound like everybody else is dissing our current users.
This broad characterization is not exactly productive.
> As it is, backports aren't
> reviewed, or committed once they are (I even split STATUS just to
> call out approved-yet-not-backported patches :-).
The person who proposed the backport is expected to perform the
backport when it has enough votes. The person casting the 3rd
vote sometimes does the backport. And there are cases when a
friendly RM clears the slate when it comes to approved proposed
backports.
> Some were working on the stable release of 2.2.x, pquerna comes
> firstmost to mind.
It isn't just Paul who wants to see 2.2.x finally materialize.
We've been trying to get 2.2.x out for quite a while. We've come
very close a couple of times, and because we like consensus we've
not pushed too hard. I for one don't want to sit here again next
year and still discuss what needs to be fixed/refactored/whatever
before 2.2.x can be released. Let's just move on. 2.2.x is already
a lot better than 2.0.x; our users deserve a release.
> Great progress is afoot, I see that release
> going beta very soon, the number of issues has dropped quite
> significantly. [Although we have 29 PatchAvailable issues, not
> sure how many correspond to 2.2 commits not backported.]
> And others are yet working on 2.4.x.
2.3.x, leading up to 2.4.x. As of the branch you are one of the
people working on that, what's the issue with that?
> So, I call a vote that we drop R-T-C altogether. It's pretty clear
> to me that those interested in current / near-future / far-future
> users are almost three distinct groups. It will be up to those
> small groups to call out and vote on changes within our individual
> domains.
Define current, near-future, far-future.
current == 1.3?
near-future == 2.0?
far-future == 2.x?
As it stands, only trunk should be C-T-R IMO. Stability on the
_stable_ branches needs to be ensured.
> The question is; would we rather be saturated by commits we feel
> need review, or exhausted waiting for commits to be approved?
The latter, but again, it's a broad characterization.
> This means code might be committed to 2.0.x and never fixed in head,
> it might mean code is fixed in head and never considered for backport
> to our current users, but all in all, it beats the situation today.
No it doesn't. trunk needs to be the branch that has the latest
code, and is most complete.
> I'm not suggesting that the 2.0.x users would entertain a break to
> ABI compatibility. But I'm suggesting that parallel development
> doesn't work when most folks are focused on tangential development.
Sander
Re: [vote] Revoke R-T-C [was: svn commit: r219520]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On July 18, 2005 1:19:54 PM -0500 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
> Some of us, trawick, orton and myself come to mind, are still up
> for supporting our current users. As it is, backports aren't
> reviewed, or committed once they are (I even split STATUS just to
> call out approved-yet-not-backported patches :-).
Well, why haven't you backported them then? Why are you looking for someone
else to do the work?
> So, I call a vote that we drop R-T-C altogether. It's pretty clear
> to me that those interested in current / near-future / far-future
> users are almost three distinct groups. It will be up to those
> small groups to call out and vote on changes within our individual
> domains.
-1. R-T-C is the crux of our stability pact with our users. -- justin
Re: [vote] Revoke R-T-C [was: svn commit: r219520]
Posted by David Reid <da...@jetnet.co.uk>.
-1
Re: [vote] Revoke R-T-C [was: svn commit: r219520]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:19 PM 7/18/2005, William A. Rowe, Jr. wrote:
>So, I call a vote that we drop R-T-C altogether. It's pretty clear
>to me that those interested in current / near-future / far-future
>users are almost three distinct groups. It will be up to those
>small groups to call out and vote on changes within our individual
>domains.
+1
just my own 2c.
Bill
[vote] Revoke R-T-C [was: svn commit: r219520]
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:51 PM 7/18/2005, Roy T. Fielding wrote:
>Or you could simply keep working on trunk like everyone else
>and let releases be made when a tarball gets three +1s.
>Version numbers are cheap. Telling the entire group to stop while
>you work on the next big patch is extremely expensive.
Ok, so we are now three levels deep?
/trunk
C-T-R
/branches/2.2.x [misnomer, we don't have a beta yet]
R-T-C ? If not now, when?
/branches/2.0.x
R-T-C
Triple commits to fix one, one-line segfault? Well, this isn't
workable. I think lack of progress shows it's not workable.
Some of us, trawick, orton and myself come to mind, are still up
for supporting our current users. As it is, backports aren't
reviewed, or committed once they are (I even split STATUS just to
call out approved-yet-not-backported patches :-).
Some were working on the stable release of 2.2.x, pquerna comes
firstmost to mind. Great progress is afoot, I see that release
going beta very soon, the number of issues has dropped quite
significantly. [Although we have 29 PatchAvailable issues, not
sure how many correspond to 2.2 commits not backported.]
And others are yet working on 2.4.x.
So, I call a vote that we drop R-T-C altogether. It's pretty clear
to me that those interested in current / near-future / far-future
users are almost three distinct groups. It will be up to those
small groups to call out and vote on changes within our individual
domains.
The question is; would we rather be saturated by commits we feel
need review, or exhausted waiting for commits to be approved?
This means code might be committed to 2.0.x and never fixed in head,
it might mean code is fixed in head and never considered for backport
to our current users, but all in all, it beats the situation today.
I'm not suggesting that the 2.0.x users would entertain a break to
ABI compatibility. But I'm suggesting that parallel development
doesn't work when most folks are focused on tangential development.
Bill
Re: svn commit: r219520 - /httpd/httpd/branches/2.2.x/
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> Thanks Paul, you just collided with the refactoring of 2.1.x proxy.
That isn't possible. Trunk is still trunk.
> Thank you for not announcing this first.
That isn't necessary.
> Thank you for ignoring the entire user community in your zeal
> to move forward with ... what?
Preparing a tarball for later vote, as requested.
> Thank you for helping the entire dev community begin refactoring
> httpd 2.3 long before there is a 2.2 release to begin committing
> ... what?
Fuck refactoring. You can refactor the code after it is released.
And after that we can create a 2.4 release if necessary.
> I see nothing going on in trunk that jeopardizes 2.2, I see alot
> of things that are unstable in 2.1-dev, and 2.1-dev is NOT BETA.
It isn't much of anything at the moment, nor is that relevant.
> The simplest thing I guess, going forward, since we all have the
> right to branch and copy as we will on dev, is to simply svn cp
> over your old work every time we feel like it. There is no way
> you are declaring httpd-2.2 C-T-R yet, although that's what 2.2
> should be once branched.
Or you could simply keep working on trunk like everyone else
and let releases be made when a tarball gets three +1s.
Version numbers are cheap. Telling the entire group to stop while
you work on the next big patch is extremely expensive.
....Roy