You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sander Striker <st...@apache.org> on 2002/04/29 10:47:29 UTC
Bumping tags
Hi,
I am bumping tags today. There have been a number of commits since
the tag that should make it to release IMO. Actually, most of them
should go in. Files marked with a [T] will have their tag bumped.
Files marked with [-] won't. I have included the logs of the changes
for your convenience. Lines marked RM: are lines with my commentary.
It would be nice if we could bump daedalus to the new tag and give
this another 1-2 days on there. I am aiming for release on wednesday.
By then it should be possible to have made a decission/have a solution
on the atomics issue.
Sander
=====================================================================
httpd-2.0
=====================================================================
[T] CHANGES
RM: Will be updated prior to retagging.
---------------------------------------------------------------------
[T] Makefile.in (1.107)
aaron
Log:
Don't install *.in config files.
---------------------------------------------------------------------
[T] STATUS
RM: Quite a few updates. I see no harm in bumping the tag on this.
---------------------------------------------------------------------
[T] build/install-bindist.sh.in (1.7)
trawick
Log:
get closer to having apxs work from a binary distribution
we need to copy libtool and instdso.sh verbatim, and we
need to edit config_vars.mk and apxs
still broken: "httpd -l" as invoked by apxs can fail since
support libraries (apr, aprutil, etc.) are probably not
findable
---------------------------------------------------------------------
[T] docs/manual/howto/ssi.html.en (1.11)
[T] docs/manual/mod/mod_alias.xml (1.5)
[T] docs/manual/vhosts/examples.html (1.10)
RM: documentation changes always have to go in IMO.
---------------------------------------------------------------------
[T] include/http_config.h (1.97)
aaron
Log:
Style cleanup (remove tabs, fix alignment).
---------------------------------------------------------------------
[T] modules/aaa/mod_auth_digest.c (1.62)
fielding
Log:
kill a warning on Darwin for NONCE_LEN becoming a long int by math.
---------------------------------------------------------------------
[T] modules/arch/win32/mod_isapi.c (1.64)
wrowe
Log:
After review and testing against all of the PSDK examples (see
http://www.apache.org/~wrowe/ for commentary on building the
examples and making them work) ... this disable-optimization
should no longer be required.
---------------------------------------------------------------------
[T] modules/experimental/mod_ext_filter.c (1.27)
wrowe
Log:
Trade one signedness mismatch for another, but choose the one that is
known to be a positive value.
---------------------------------------------------------------------
[T] modules/http/http_request.c (1.141)
jerenkrantz
Log:
If a subreq added a filter (say INCLUDES) and the subreq was promoted via
fast_redirect, the filter would still point at the subreq - rather than
the original r. So, we must update any filters pointing at rr to be r.
This would cause lots of problems with mod_include with mod_dir requests
such as seen in PR 7966. mod_include would be unsetting the headers_out
of rr instead of r. But, we disassociate rr->headers_out and r->headers_out.
Therefore, the C-L header in r->headers_out would remain - even though it
bears no relation to what we will be outputting - causing problems.
This also now permits chunked-encoding of mod_dir/mod_include requests
which could never happen before and fixes the content-length problem
seen in PR 7966.
As hinted at in PR 7966, there is a race condition - if for some reason
the server stalls reading an included file (or even better, placing a
sleep in the cgi-bin script!), the invalid C-L may get propogated to the
client.
(Note that internal_internal_redirect has this same code fragment.)
PR: 7966
---------------------------------------------------------------------
[T] modules/mappers/mod_imap.c (1.39)
stoddard
Log:
Fix spelling/typo
brianp
Log:
Because mod_imap's handler runs on every request in the default
configuration, rearrange the code to keep it from allocating a few
pages worth of local variables on the stack on requests that don't
use imagemaps
---------------------------------------------------------------------
[T] modules/mappers/mod_userdir.c (1.46)
brianp
Log:
Short-circuit out of mod_userdir's translation handler faster on
non "/~*" requests
---------------------------------------------------------------------
[T] modules/metadata/mod_unique_id.c (1.37)
trawick
Log:
Allow mod_unique_id to work on systems with no IPv4 address
corresponding to their host name.
trawick
Log:
fix a compiler error with picky compilers that (correctly) don't let
you add to void *
---------------------------------------------------------------------
[T] modules/proxy/mod_proxy.h (1.81)
[T] modules/proxy/proxy_ftp.c (1.119)
[T] modules/proxy/proxy_http.c (1.148)
[T] modules/proxy/proxy_util.c (1.90)
trawick
Log:
get mod_proxy to build on EBCDIC machines
trawick
Log:
get basic HTTP proxy working on EBCDIC machines
(I would bet that there is more work to do throughout proxy, but at least
it can serve some pages now)
trawick
Log:
fix a compile break on EBCDIC machines
---------------------------------------------------------------------
[T] server/core.c (1.172)
gregames
Log:
remove a goto
---------------------------------------------------------------------
[T] server/protocol.c (1.97)
jerenkrantz
Log:
Simplify this little chunk of code since r is set to f->r earlier.
---------------------------------------------------------------------
[T] server/util.c (1.127)
bnicholes
Log:
Added a check to make sure that h_aliases is not NULL before we try to
dereference it in the for(...) loop. Attempting to dereference a NULL pointer
was causing a fault if there were no aliases found.
brianp
Log:
Updated ap_getword_white() to use the same coding style
(and optimizations) as ap_getword()
---------------------------------------------------------------------
[T] server/mpm/experimental/leader/leader.c (1.15)
brianp
Log:
Switch back from atomic_cas to mutexes, based on all the current
portability challenges with atomics
brianp
Log:
Fixed the creation of the worker threads' data structures
brianp
Log:
Removed creation of unused struct
---------------------------------------------------------------------
[T] server/mpm/experimental/threadpool/threadpool.c (1.7)
aaron
Log:
When we signal a condition variable, we need to own the lock that
is associated with that condition variable. This isn't necessary
for Solaris, but for Posix it is.
aaron
Log:
Some threadpool fixes:
- We don't need the listener_blocked flag, just check if the element
we're adding makes the stack non-empty.
- When we are terminated, return APR_EOF; catch this event in the
worker thread and the listener thread.
- When shutting down, always signal a potential listener thread.
- Wait to signal the listener thread until after we add the worker
element to the stack.
aaron
Log:
Clarify an incorrect statement about why we're purposfully putting
the signal inside of a mutex.
aaron
Log:
Some more threadpool MPM changes:
- Add a "state" variable to the worker_wakeup_info struct. This is
used to make sure that we act on the correct signal, and to know when
to shut down a worker thread.
- Fix the call when the worker thread waits for a connection to use
the new state variable and use mutexes around the cond_wait() call.
- Change the interrupt_all() call to set the WORKER_TERMINATED state.
- Add two AP_DEBUG_ASSERT() to make sure that we aren't waking up
a worker thread before it is idle.
aaron
Log:
Remove unused variable.
aaron
Log:
Rename the worker_stack_interrupt_all() function as worker_stack_terminate().
Also, broadcast a signal after we set the terminate flag on the worker stack.
---------------------------------------------------------------------
[T] server/mpm/winnt/mpm_winnt.c (1.268)
stoddard
Log:
my_generation is in the shared scoreboard now.
stoddard
Log:
Fix a bug in the mod_status display caused by some uninitialized fields.
Prep for taking mpm_winnt to multi-process...
---------------------------------------------------------------------
[T] server/mpm/worker/fdqueue.c (1.22)
[T] server/mpm/worker/fdqueue.h (1.19)
[T] server/mpm/worker/worker.c (1.120)
aaron
Log:
Convert the worker MPM's fdqueue from a LIFO back into a FIFO. Since
elements in the queue represent accept()ed connections, we want them
to be processed in the order that they were received. (I erroneously
converted it to a LIFO quite awhile ago in the hopes that it would
improve cache efficiency.)
Remember to perform a make clean in the worker directory after this patch,
since this patch changes the size of the fd_queue_t object (which is
allocated in worker.c).
aaron
Log:
Add a "queue_info" structure to the worker MPM. This is used to prevent
the listener thread from accept()ing more connections than there are
available workers. This prevents long-running requests from starving
connections that have been accepted but not yet processed.
The queue_info is a simple counter, mutex, and condition variable. Only
the listener thread blocks on the condition, and only when there are no
idle workers. In the fast path there is a mutex lock, integer decrement,
and and unlock (among a few conditionals). The worker threads each notify
the queue_info when they are about to block on the normal worker_queue
waiting for some connection to process, which wakes up any sleeping
listener thread to go perform another accept() in parallel.
jerenkrantz
Log:
Preserve the original error, or if the unlock fails then use that
error instead.
brianp
Log:
Move a potentially expensive pool cleanup operation outside
the mutex-protected critical path of ap_queue_pop()
brianp
Log:
Added a missing pool deletion case and simplified the conditionals
for the error-case return (thanks to Justin for suggesting the
latter)
brianp
Log:
Moved the recycled pool list from the queue to the queue_info structure.
The advantage of doing this is that it enables us to guarantee that the
number of ptrans pools in existence at once is no greater than the
number of worker threads, and that we'll never have to delete ptrans
pools.
brianp
Log:
Removed the "not_full" condition variable and associated conditional
logic from the file descriptor queue, now that we can rely on the
idle worker reference count to keep the listener from trying to
push connections into a full queue
brianp
Log:
Removed some code from the mutex-protected block in ap_queue_pop().
If the worker thread synchronization is working properly, it's not
necessary to set these fields to NULL after removing an element from
the queue, and it's IMO more important to have a shorter code path
leading up to the mutex_unlock. I left in support for NULLing the
fields when debugging, though.
aaron
Log:
Detect APR_EINTR from ap_queue_pop() and avoid calling
ap_queue_info_set_idle() more than once at a time per worker thread.
This fixes an assert coredump.
=====================================================================
apr
=====================================================================
[T] srclib/apr/CHANGES
RM: Will be updated prior to retagging.
---------------------------------------------------------------------
[T] srclib/apr/STATUS
RM: No harm in retagging this one.
---------------------------------------------------------------------
[-] srclib/apr/configure.in (1.436)
jerenkrantz
Log:
Not all platforms can mmap /dev/zero, so we need to do an explicit check
for that. If that were to fail, then make it appear as /dev/zero never
existed in the first place.
PR: 8537
RM: Justin adviced against including this in the tag. See:
<20...@apache.org>
---------------------------------------------------------------------
[T] srclib/apr/include/apr_signal.h (1.11)
fielding
Log:
Avoid warnings on Darwin by working around a bug in sys/include.h.
---------------------------------------------------------------------
[T] srclib/apr/locks/unix/thread_mutex.c (1.10)
brianp
Log:
Optimization: rearranged the mutex lock/unlock code to
eliminate a conditional branch on platforms where PTHREAD_SETS_ERRNO
is not defined (at present, this means everything except OS/390)
---------------------------------------------------------------------
[T] srclib/apr/network_io/unix/sendrecv.c (1.267)
trawick
Log:
Reduce the number of apr_sendfile calls on AIX and OS/390 by
remembering when the kernel tells us the next one will block.
---------------------------------------------------------------------
[T] srclib/apr/network_io/win32/sendrecv.c (1.47)
stoddard
Log:
A read with 0 bytes is an APR_EOF. Found this running ab.
=====================================================================
apr-util
=====================================================================
[T] srclib/apr-util/xml/expat/buildconf.sh
jerenkrantz
Log:
Bring over change from APR to allow cleaning of the libtool files on
each invocation of buildconf.sh. This allows switching from 1.3 to 1.4
series libtool possible without intervention.
Re: Bumping tags
Posted by Greg Ames <gr...@apache.org>.
Sander Striker wrote:
>
> Hi,
>
> I am bumping tags today. There have been a number of commits since
> the tag that should make it to release IMO. Actually, most of them
> should go in.
[...]
> It would be nice if we could bump daedalus to the new tag and give
> this another 1-2 days on there.
OK. I'll assume the tag is reasonable stable, and start building it.
Greg
Re: Bumping tags
Posted by Jeff Trawick <tr...@attglobal.net>.
Thom May <th...@planetarytramp.net> writes:
> * Jeff Trawick (trawick@attglobal.net) wrote :
> > "Sander Striker" <st...@apache.org> writes:
> >
> > > I am bumping tags today. There have been a number of commits since
> > > the tag that should make it to release IMO.
> >
> > I hope to finish testing and commit a change to apxs.in (patch posted
> > Friday) to finish up a set of fixes to allow apxs to work from a
> > binary build. It would be nice if that works in the next release.
> > I may not be done until 1600GMT.
> >
> Could you possibly have a look at the patch that Pier and I sent to the list
> a few times for apxs? I think it ought to fix most of what you are looking
> at...
I don't see the connection, other than that our patches probably
conflict :) Your patch looks reasonable at first glance, but I
haven't played with it enough to feel comfortable committing it. All
I can promise at the moment is that I'll defer committing mine until I
or somebody else has a chance to review and commit your patch.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Bumping tags
Posted by Thom May <th...@planetarytramp.net>.
* Jeff Trawick (trawick@attglobal.net) wrote :
> Thom May <th...@planetarytramp.net> writes:
>
> > * Jeff Trawick (trawick@attglobal.net) wrote :
> > > I hope to finish testing and commit a change to apxs.in (patch posted
> > > Friday) to finish up a set of fixes to allow apxs to work from a
> > > binary build. It would be nice if that works in the next release.
> > > I may not be done until 1600GMT.
> > >
> > Could you possibly have a look at the patch that Pier and I sent to the list
> > a few times for apxs? I think it ought to fix most of what you are looking
> > at...
>
> I think I see what you meant by your suggestion that the patch would
> fix what I was looking at... I'm playing with the one Pier posted
> (April 27), but it doesn't seem to have a fix to make "httpd -l" work
> with a binary distribution install. I see an earlier patch you posted
> (April 9) that set LD_LIBRARY_PATH, but LD_LIBRARY_PATH isn't portable
> (the envvars file owns that problem, so it is best to source the
> envvars file). Also, I don't see the need to set the
> LD_LIBRARY_PATH-type variable unless it is a binbuild. Did you
> encounter another situation where it is needed?
>
We were needing LD_LIBRARY_PATH to allow httpd to run when it had been
relocated.
cheers,
-Thom
--
Thom May -> thom@planetarytramp.net
US elections:
For those of you fearing that the rest of the world might be making fun
of the US because of this: Rest assured, we are.
Re: Bumping tags
Posted by Jeff Trawick <tr...@attglobal.net>.
Thom May <th...@planetarytramp.net> writes:
> * Jeff Trawick (trawick@attglobal.net) wrote :
> > I hope to finish testing and commit a change to apxs.in (patch posted
> > Friday) to finish up a set of fixes to allow apxs to work from a
> > binary build. It would be nice if that works in the next release.
> > I may not be done until 1600GMT.
> >
> Could you possibly have a look at the patch that Pier and I sent to the list
> a few times for apxs? I think it ought to fix most of what you are looking
> at...
I think I see what you meant by your suggestion that the patch would
fix what I was looking at... I'm playing with the one Pier posted
(April 27), but it doesn't seem to have a fix to make "httpd -l" work
with a binary distribution install. I see an earlier patch you posted
(April 9) that set LD_LIBRARY_PATH, but LD_LIBRARY_PATH isn't portable
(the envvars file owns that problem, so it is best to source the
envvars file). Also, I don't see the need to set the
LD_LIBRARY_PATH-type variable unless it is a binbuild. Did you
encounter another situation where it is needed?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Bumping tags
Posted by Thom May <th...@planetarytramp.net>.
* Jeff Trawick (trawick@attglobal.net) wrote :
> "Sander Striker" <st...@apache.org> writes:
>
> > I am bumping tags today. There have been a number of commits since
> > the tag that should make it to release IMO.
>
> I hope to finish testing and commit a change to apxs.in (patch posted
> Friday) to finish up a set of fixes to allow apxs to work from a
> binary build. It would be nice if that works in the next release.
> I may not be done until 1600GMT.
>
Could you possibly have a look at the patch that Pier and I sent to the list
a few times for apxs? I think it ought to fix most of what you are looking
at...
Cheers,
-Thom
--
Thom May -> thom@planetarytramp.net
* edward just installed gbuffy
<edward> (mail notifier)
<infinity> Dang.
<infinity> How disappointing.
<Hydroxide> not the GNU Vampire Slayer?
<infinity> I was hoping for some sort of Sarah Michelle Gellar
thing. :)
<thom> infinity: you wanted a vampire slayer on your desktop?
<Hydroxide> (female version of gblade I guess)
<joeyh> shouldn't gbuffy deal with zombie processes or something?
<Hydroxide> ok joey you beat us all :P
Re: Bumping tags
Posted by Jeff Trawick <tr...@attglobal.net>.
"Sander Striker" <st...@apache.org> writes:
> > From: trawick@rdu88-250-035.nc.rr.com
> > [mailto:trawick@rdu88-250-035.nc.rr.com]On Behalf Of Jeff Trawick
> > Sent: 29 April 2002 13:23
>
> > "Sander Striker" <st...@apache.org> writes:
> >
> > > I am bumping tags today. There have been a number of commits since
> > > the tag that should make it to release IMO.
> >
> > I hope to finish testing and commit a change to apxs.in (patch posted
> > Friday) to finish up a set of fixes to allow apxs to work from a
> > binary build. It would be nice if that works in the next release.
> > I may not be done until 1600GMT.
>
> Drop me a line when it is in place.
Right now it looks like my apxs.in patch is queued up behind Thom
Mays' & Pier's patch. I withdraw my previous time target :)
> > It looks like you picked up practically all the changes. Why not just
> > retag 2.0.37?
>
> You mean, tag HEAD as 2.0.37?
yes
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: Bumping tags
Posted by Bill Stoddard <bi...@wstoddard.com>.
> >> Well then why are the patches in the tree??? I'm not sure I like the
> >> idea of
> >> tagging and then tagging just some files. Seems like if we haven't got a
> >> stable HEAD we shouldn't be tagging. We got into this whole business of
> >> tagging often as a way of avoiding having this sort of thing. Ifw e
> >> tagged
> >> and it wasn't stable, who cares. Just retag when it is and move on...
> >>
> >> This seems to be a growing trend and one I think we should stop.
> >
> > I disagree. I see a lot of value in managing a release by tagging then
> > selectively
> > picking up showstopper fixes. And the RM should make the decision if this
> > is the way he
> > wants to get the release out.
>
> I strongly dislike the action of tagging the tree with a version number
> and then moving that tag. If we aren't sure about the version, then the
> RM should use a personal tag and only replace it with the real version tag
> when we are sure.
+1
Running up the version number is not the issue (al least for me). Getting a stable release
tagged and rolled is. Enabling the RM to tag then selectively bump the tag to fix
showstoppers is proving to be an effective way to get good releases out.
Bill
RE: Bumping tags
Posted by Sander Striker <st...@apache.org>.
> From: Roy T. Fielding [mailto:fielding@apache.org]
> Sent: 01 May 2002 00:09
> >> Well then why are the patches in the tree??? I'm not sure I like the
> >> idea of
> >> tagging and then tagging just some files. Seems like if we haven't got a
> >> stable HEAD we shouldn't be tagging. We got into this whole business of
> >> tagging often as a way of avoiding having this sort of thing. Ifw e
> >> tagged
> >> and it wasn't stable, who cares. Just retag when it is and move on...
> >>
> >> This seems to be a growing trend and one I think we should stop.
> >
> > I disagree. I see a lot of value in managing a release by tagging then
> > selectively
> > picking up showstopper fixes. And the RM should make the decision if this
> > is the way he
> > wants to get the release out.
>
> I strongly dislike the action of tagging the tree with a version number
> and then moving that tag. If we aren't sure about the version, then the
> RM should use a personal tag and only replace it with the real version tag
Should we invent an RM prerelease tag which will be removed after the final
tag with the version number?
> when we are sure. If people aren't willing to run up the version numbers,
> then they shouldn't tag them as such until the version is ready for
> tarball.
>
> Justin already showed that an RM can do it this way effectively.
Point taken. I'll remember that for my next RM adventure. For this release
I'd like to continue like I started (one last bump), so we can get 2.0.36 out
the door. And yes, I liked justins method aswell.
/me slaps himself for not tagging with STRIKER first...
> .....Roy
Sander
Re: Bumping tags
Posted by "Roy T. Fielding" <fi...@apache.org>.
>> Well then why are the patches in the tree??? I'm not sure I like the
>> idea of
>> tagging and then tagging just some files. Seems like if we haven't got a
>> stable HEAD we shouldn't be tagging. We got into this whole business of
>> tagging often as a way of avoiding having this sort of thing. Ifw e
>> tagged
>> and it wasn't stable, who cares. Just retag when it is and move on...
>>
>> This seems to be a growing trend and one I think we should stop.
>
> I disagree. I see a lot of value in managing a release by tagging then
> selectively
> picking up showstopper fixes. And the RM should make the decision if this
> is the way he
> wants to get the release out.
I strongly dislike the action of tagging the tree with a version number
and then moving that tag. If we aren't sure about the version, then the
RM should use a personal tag and only replace it with the real version tag
when we are sure. If people aren't willing to run up the version numbers,
then they shouldn't tag them as such until the version is ready for
tarball.
Justin already showed that an RM can do it this way effectively.
....Roy
Re: Bumping tags
Posted by Bill Stoddard <bi...@wstoddard.com>.
> > > It looks like you picked up practically all the changes. Why not just
> > > retag 2.0.37?
>
> I'm +1 for this...
>
> > You mean, tag HEAD as 2.0.37?
> > I didn't want to do that since there were changes I didn't want in there.
> > Practically all the changes is just about right ;)
>
> Well then why are the patches in the tree??? I'm not sure I like the idea of
> tagging and then tagging just some files. Seems like if we haven't got a
> stable HEAD we shouldn't be tagging. We got into this whole business of
> tagging often as a way of avoiding having this sort of thing. Ifw e tagged
> and it wasn't stable, who cares. Just retag when it is and move on...
>
> This seems to be a growing trend and one I think we should stop.
I disagree. I see a lot of value in managing a release by tagging then selectively
picking up showstopper fixes. And the RM should make the decision if this is the way he
wants to get the release out.
Bill
>
> david
>
>
RE: Bumping tags
Posted by Sander Striker <st...@apache.org>.
> From: David Reid [mailto:dreid@jetnet.co.uk]
> Sent: 30 April 2002 10:31
>>> It looks like you picked up practically all the changes. Why not just
>>> retag 2.0.37?
>
> I'm +1 for this...
>
>> You mean, tag HEAD as 2.0.37?
>> I didn't want to do that since there were changes I didn't want in there.
>> Practically all the changes is just about right ;)
>
> Well then why are the patches in the tree???
Because someone committed them. The group hasn't come around dealing with
it (which we see all the time).
> I'm not sure I like the idea of
> tagging and then tagging just some files. Seems like if we haven't got a
> stable HEAD we shouldn't be tagging. We got into this whole business of
> tagging often as a way of avoiding having this sort of thing. Ifw e tagged
> and it wasn't stable, who cares. Just retag when it is and move on...
This is exactly why there is an RM IMO. If the HEAD were always stable we
wouldn't even need a RM, just running the httpd_roll_release script would be
enough then.
> This seems to be a growing trend and one I think we should stop.
There are only 2 files that have changes since the tag that haven't gone in.
One is because the committer advised against including it (apr/configure.in).
The second is because there hasn't been group concensus on it, but a flag was
raised. In the latter (the ab versioning thing), I thought it better not to
burden the public with changing version schemes twice, if that should happen.
> david
Sander
Re: Bumping tags
Posted by David Reid <dr...@jetnet.co.uk>.
> > It looks like you picked up practically all the changes. Why not just
> > retag 2.0.37?
I'm +1 for this...
> You mean, tag HEAD as 2.0.37?
> I didn't want to do that since there were changes I didn't want in there.
> Practically all the changes is just about right ;)
Well then why are the patches in the tree??? I'm not sure I like the idea of
tagging and then tagging just some files. Seems like if we haven't got a
stable HEAD we shouldn't be tagging. We got into this whole business of
tagging often as a way of avoiding having this sort of thing. Ifw e tagged
and it wasn't stable, who cares. Just retag when it is and move on...
This seems to be a growing trend and one I think we should stop.
david
RE: Bumping tags
Posted by Sander Striker <st...@apache.org>.
> From: trawick@rdu88-250-035.nc.rr.com
> [mailto:trawick@rdu88-250-035.nc.rr.com]On Behalf Of Jeff Trawick
> Sent: 29 April 2002 13:23
> "Sander Striker" <st...@apache.org> writes:
>
> > I am bumping tags today. There have been a number of commits since
> > the tag that should make it to release IMO.
>
> I hope to finish testing and commit a change to apxs.in (patch posted
> Friday) to finish up a set of fixes to allow apxs to work from a
> binary build. It would be nice if that works in the next release.
> I may not be done until 1600GMT.
Drop me a line when it is in place.
> It looks like you picked up practically all the changes. Why not just
> retag 2.0.37?
You mean, tag HEAD as 2.0.37?
I didn't want to do that since there were changes I didn't want in there.
Practically all the changes is just about right ;)
Sander
Re: Bumping tags
Posted by Jeff Trawick <tr...@attglobal.net>.
"Sander Striker" <st...@apache.org> writes:
> I am bumping tags today. There have been a number of commits since
> the tag that should make it to release IMO.
I hope to finish testing and commit a change to apxs.in (patch posted
Friday) to finish up a set of fixes to allow apxs to work from a
binary build. It would be nice if that works in the next release.
I may not be done until 1600GMT.
It looks like you picked up practically all the changes. Why not just
retag 2.0.37?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...