You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2001/08/23 17:09:11 UTC
2.0.24 ready for beta?
With the last mod_include fix, can we bump the tag on mod_include and go beta?
Bill
Re: 2.0.24 ready for beta?
Posted by Ian Holsman <ia...@cnet.com>.
On Thu, 2001-08-23 at 09:33, Bill Stoddard wrote:
> What is the failure? And why was this not broken in Apache 1.3? The change seems
> reasonable but curious if there is a better way to fix this.
the failure happens in ap_escape_html as it always assumes a not-null
value being passed in.
to reproduce you need to have the main file R-Proxied and have it do
something like <!--#include virtual="/crash/penv.html"-->
and have "/crash/penv.html" have a <!--#printenv-->
I didn't put a patch through on ap_escape_html as if it checked for
null, we would probably not catch problems like this one.
>
> Bill
>
> > On Thu, 2001-08-23 at 08:09, Bill Stoddard wrote:
> > > With the last mod_include fix, can we bump the tag on mod_include and go beta?
> > >
> > I had 1 patch to mod_include I'd like to see included.
> > It deals with the case where the main page is not a file.
> >
> >
> > Index: mod_include.c
> > ===================================================================
> > RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
> > retrieving revision 1.125
> > diff -u -u -r1.125 mod_include.c
> > --- mod_include.c 2001/08/18 17:36:26 1.125
> > +++ mod_include.c 2001/08/23 15:45:43
> > @@ -113,7 +113,10 @@
> > apr_table_setn(e, "LAST_MODIFIED",
> > ap_ht_time(r->pool, r->finfo.mtime, timefmt, 0));
> > apr_table_setn(e, "DOCUMENT_URI", r->uri);
> > - apr_table_setn(e, "DOCUMENT_PATH_INFO", r->path_info);
> > + /* path info is not set if the pages has come from mod-proxy */
> > + if (r->path_info && *r->path_info ) {
> > + apr_table_setn(e, "DOCUMENT_PATH_INFO", r->path_info);
> > + }
> > if (apr_get_username(&pwname, r->finfo.user, r->pool) ==
> > APR_SUCCESS) {
> > apr_table_setn(e, "USER_NAME", pwname);
> > }
> >
> >
> > > Bill
> > --
> > Ian Holsman IanH@cnet.com
> > Performance Measurement & Analysis
> > CNET Networks - (415) 364-8608
> >
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: 2.0.24 ready for beta?
Posted by Bill Stoddard <bi...@wstoddard.com>.
What is the failure? And why was this not broken in Apache 1.3? The change seems
reasonable but curious if there is a better way to fix this.
Bill
> On Thu, 2001-08-23 at 08:09, Bill Stoddard wrote:
> > With the last mod_include fix, can we bump the tag on mod_include and go beta?
> >
> I had 1 patch to mod_include I'd like to see included.
> It deals with the case where the main page is not a file.
>
>
> Index: mod_include.c
> ===================================================================
> RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
> retrieving revision 1.125
> diff -u -u -r1.125 mod_include.c
> --- mod_include.c 2001/08/18 17:36:26 1.125
> +++ mod_include.c 2001/08/23 15:45:43
> @@ -113,7 +113,10 @@
> apr_table_setn(e, "LAST_MODIFIED",
> ap_ht_time(r->pool, r->finfo.mtime, timefmt, 0));
> apr_table_setn(e, "DOCUMENT_URI", r->uri);
> - apr_table_setn(e, "DOCUMENT_PATH_INFO", r->path_info);
> + /* path info is not set if the pages has come from mod-proxy */
> + if (r->path_info && *r->path_info ) {
> + apr_table_setn(e, "DOCUMENT_PATH_INFO", r->path_info);
> + }
> if (apr_get_username(&pwname, r->finfo.user, r->pool) ==
> APR_SUCCESS) {
> apr_table_setn(e, "USER_NAME", pwname);
> }
>
>
> > Bill
> --
> Ian Holsman IanH@cnet.com
> Performance Measurement & Analysis
> CNET Networks - (415) 364-8608
>
Re: 2.0.24 ready for beta?
Posted by Ian Holsman <ia...@cnet.com>.
On Thu, 2001-08-23 at 08:09, Bill Stoddard wrote:
> With the last mod_include fix, can we bump the tag on mod_include and go beta?
>
I had 1 patch to mod_include I'd like to see included.
It deals with the case where the main page is not a file.
Index: mod_include.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.125
diff -u -u -r1.125 mod_include.c
--- mod_include.c 2001/08/18 17:36:26 1.125
+++ mod_include.c 2001/08/23 15:45:43
@@ -113,7 +113,10 @@
apr_table_setn(e, "LAST_MODIFIED",
ap_ht_time(r->pool, r->finfo.mtime, timefmt, 0));
apr_table_setn(e, "DOCUMENT_URI", r->uri);
- apr_table_setn(e, "DOCUMENT_PATH_INFO", r->path_info);
+ /* path info is not set if the pages has come from mod-proxy */
+ if (r->path_info && *r->path_info ) {
+ apr_table_setn(e, "DOCUMENT_PATH_INFO", r->path_info);
+ }
if (apr_get_username(&pwname, r->finfo.user, r->pool) ==
APR_SUCCESS) {
apr_table_setn(e, "USER_NAME", pwname);
}
> Bill
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: 2.0.24 ready for beta?
Posted by Joshua Slive <sl...@commerce.ubc.ca>.
On Thu, 23 Aug 2001, Cliff Woolley wrote:
> Like I said before, I'm still +1 for 2.0.24 for beta on Unix. I don't
> much like the idea of calling it a beta only on Unix, but I won't veto the
> idea.
I'm +1 for a 2.0.24 beta as well. I'm +1 for beta for anything that
a) compiles
b) has no known security problems
c) has significantly less bugs than 2.0.16.
I think 2.0.24 qualifies.
Joshua.
Re: 2.0.24 ready for beta?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 23 Aug 2001, Bill Stoddard wrote:
> Just tried a new extract of HEAD and the server doesn't even build.
Yep, same here. I'll jump right in to that. <sigh>
> Which is pretty much what I expected. At some point, we need to make
> binaries available so the world can take a look at what we are working
> on. 2.0.24 is (was) there IMO. So when do we tag 2.0.25? When all the
> problems are fixed?
You know I'm just as keen to get a beta build out there as you are... and
have been for going on two months now. It's time.
Like I said before, I'm still +1 for 2.0.24 for beta on Unix. I don't
much like the idea of calling it a beta only on Unix, but I won't veto the
idea.
My only concern is that if people are going to veto 2.0.24 in favor of
2.0.25 (which has already been done by OtherBill for Win32 and a strong
"let's not go there" from Ryan all around due to the age of 2.0.24), then
2.0.25 needs to get ironed out and put up on daedalus ASAP for testing in
production. And it needs to be compilable. =-)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.24 ready for beta?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Thu, 23 Aug 2001, Bill Stoddard wrote:
>
> > > I don't think I am. Let's get this taken care of. :-/
> >
> > Why? Most serious Apache users run Unix/Linux. And thread support
> > under Unix/Linux is one of the main features of Apache 2.0. Obviously
> > we need to fix Win32 but it is wrong to delay the beta because of
> > Win32. IMHO.
>
> Mainly because OtherBill implied that the fixes for at least 90% of his
> issues were forthcoming (which I see now that they are
Just tried a new extract of HEAD and the server doesn't even build. Which is pretty much
what I expected. At some point, we need to make binaries available so the world can take a
look at what we are working on. 2.0.24 is (was) there IMO. So when do we tag 2.0.25? When
all the problems are fixed?
Bill
Re: 2.0.24 ready for beta?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Cliff Woolley" <cl...@yahoo.com>
Sent: Thursday, August 23, 2001 2:16 PM
> Besides, I just think it looks bad for us to constantly be swaying back
> and forth. Oh, this release is a beta for Unix but not Win32. Oh, this
> one is good on Win32 but only alpha-and-a-half for Unix.
Notice that os/foo is nearly depleted :)
Re: 2.0.24 ready for beta?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 23 Aug 2001, Bill Stoddard wrote:
> > I don't think I am. Let's get this taken care of. :-/
>
> Why? Most serious Apache users run Unix/Linux. And thread support
> under Unix/Linux is one of the main features of Apache 2.0. Obviously
> we need to fix Win32 but it is wrong to delay the beta because of
> Win32. IMHO.
Mainly because OtherBill implied that the fixes for at least 90% of his
issues were forthcoming (which I see now that they are).
Besides, I just think it looks bad for us to constantly be swaying back
and forth. Oh, this release is a beta for Unix but not Win32. Oh, this
one is good on Win32 but only alpha-and-a-half for Unix. Granted, we'd
probably never release code in the latter case because most of us are
Unix-inclined and Unix remains our major audience. But still I'd like us
to be able to continue to say that a big feature of 2.0 is that Win32 is
just as well supported as Unix, even though I'd never actually use Apache
(or any other service for that matter) off of a Windows box myself. IMO,
the appearance presented to the public if we were to release a beta on
Unix and not call it a beta on Win32 would be that Win32 is lagging far
behind, which I don't believe to be the case at all.
But that's just my $0.02. I won't veto a split release, but let's just
say I'm -0.75 on the idea.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.24 ready for beta?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Thu, 23 Aug 2001, Bill Stoddard wrote:
>
> > > I'm -1 on calling any Win32 release a beta without those eliminated
> >
> > I'm okay with only declaring beta on Unix/Linux.
>
> I don't think I am. Let's get this taken care of. :-/
>
Why? Most serious Apache users run Unix/Linux. And thread support under Unix/Linux is one
of the main features of Apache 2.0. Obviously we need to fix Win32 but it is wrong to
delay the beta because of Win32. IMHO.
Bill
Re: 2.0.24 ready for beta?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 23 Aug 2001, Bill Stoddard wrote:
> > I'm -1 on calling any Win32 release a beta without those eliminated
>
> I'm okay with only declaring beta on Unix/Linux.
I don't think I am. Let's get this taken care of. :-/
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.24 ready for beta?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> I'm -1 on calling any Win32 release a beta without those eliminated
I'm okay with only declaring beta on Unix/Linux.
Bill
Re: 2.0.24 ready for beta?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
We must (temporarily) disable the /error/ mapping section, until we can set
<Directory @@serverroot@@/error/>
ForceLanguagePreferences Full
because right now you can get a Not Acceptable [list of identical files] that
they can't decypher. I should be wrapped up tommorow, but I've been seriously
sidelined by bigger fish...
The filesystem is also still full of holes that I've (nearly) fixed in my
checked out tree. The patch I'm committing closes 90% up, and discovers
10% new ones we need to fix. It eliminates reliance on os/foo/os.c for the
is_absolute and canonical stuff that's broken on non-unix.
I'm -1 on calling any Win32 release a beta without those eliminated. Hold
on while I summon up the commits.
Bill
----- Original Message -----
From: "Bill Stoddard" <bi...@wstoddard.com>
To: <de...@httpd.apache.org>
Sent: Thursday, August 23, 2001 10:09 AM
Subject: 2.0.24 ready for beta?
> With the last mod_include fix, can we bump the tag on mod_include and go beta?
>
> Bill
>
>
Re: 2.0.24 ready for beta?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Thu, Aug 23, 2001 at 02:53:03PM -0400, Greg Ames wrote:
> >...
> > However, the bugs are getting more subtle and take longer to debug and
> > fix. With our current process, a great deal of new code can be
> > committed while the gnarly problem in last tarball is being debugged.
> > Why would we think that the new code is any less likely to contain
> > serious bugs than the previous set of changes? How do we get off this
> > treadmill?
>
> We got "off the treadmill" by stopping this silly business of holding up
> tarballs.
>
> Snap a tarball. Give it a once over. Release it as an alpha. Bam. Done.
>
> Come back a week later and upgrade it to a beta. Not so hard.
>
>
> We are right back where we were last year: releases take forever. We have
> completely lost the "snap. release." routine. Releases of *any* quality
> can be happening every couple weeks or even faster. But since everybody is
> "oh no, it *MUST* be a beta" we're waiting forever. It's silly.
Then we should make binaries available for alphas. I don't give a flying *** whether we
label a release alpha or beta. If it is decent, we need to make binaries available.
Bill
Re: 2.0.24 ready for beta?
Posted by Jeff Trawick <tr...@attglobal.net>.
Greg Stein <gs...@lyra.org> writes:
> On Thu, Aug 23, 2001 at 02:53:03PM -0400, Greg Ames wrote:
> >...
> > However, the bugs are getting more subtle and take longer to debug and
> > fix. With our current process, a great deal of new code can be
> > committed while the gnarly problem in last tarball is being debugged.
> > Why would we think that the new code is any less likely to contain
> > serious bugs than the previous set of changes? How do we get off this
> > treadmill?
>
> We got "off the treadmill" by stopping this silly business of holding up
> tarballs.
>
> Snap a tarball. Give it a once over. Release it as an alpha. Bam. Done.
>
> Come back a week later and upgrade it to a beta. Not so hard.
I don't think you can accurately equate the desire by some people to
put together a tarball which they expect will be of beta quality with
"holding up tarballs." Anybody that wants an alpha is free to do so.
As it stands, it seems that the only folks that are interested in a
tarball only want it if they think it is beta quality. Somebody who
isn't so picky is free to follow the process you outline above. As
long as those who want a beta tarball are helping the code base I
think they should be allowed to deviate from that process (e.g.,
re-tag files later when necessary fixes are applied, in effect
maintaining a virtual tarball until it is ready).
As I see it from the frontlines of debugging the current code, the
test/debug cycle, and its overlap with lots of activity in HEAD, is
what is delaying a beta tarball. I don't see how the process you
outlined is going to change that, unless there are some different
psychological motivations in play which will reduce the amount of
activity in HEAD and/or apply additional effort to the test/debug
cycle.
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.24 ready for beta?
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 23, 2001 at 02:53:03PM -0400, Greg Ames wrote:
>...
> However, the bugs are getting more subtle and take longer to debug and
> fix. With our current process, a great deal of new code can be
> committed while the gnarly problem in last tarball is being debugged.
> Why would we think that the new code is any less likely to contain
> serious bugs than the previous set of changes? How do we get off this
> treadmill?
We got "off the treadmill" by stopping this silly business of holding up
tarballs.
Snap a tarball. Give it a once over. Release it as an alpha. Bam. Done.
Come back a week later and upgrade it to a beta. Not so hard.
We are right back where we were last year: releases take forever. We have
completely lost the "snap. release." routine. Releases of *any* quality
can be happening every couple weeks or even faster. But since everybody is
"oh no, it *MUST* be a beta" we're waiting forever. It's silly.
If you want a release, then make a release. Label it as beta or gold or
whatever later. Nobody said we can't change the quality level over time.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: 2.0.24 ready for beta?
Posted by Greg Ames <gr...@remulak.net>.
Ryan Bloom wrote:
>
> I disagree quite strongly. Take a look at the CHANGES file for 2.0.25.
> We have fixed at least on seg fault in mod_mime, a memory leak in
> mod_mime_magic, and two major fixes to the build system.
>
> 2.0.25 is far better than 2.0.24,
It may be better, but that remains to be proven. Sure, I like the
concept of the changes, but the implementation details sometimes bite
us.
> and I have very little confidence in re-tagging
> a week after the original tag.
I have a great deal of confidence in the code currently running on
daedalus. We could easily produce tarballs and binaries that match it.
Lately, we haven't been breaking the build as often as we used to, and
most of the time you can just grab the current HEAD and serve static
pages and much more. Thanks to everybody for making that happen...this
is progress.
However, the bugs are getting more subtle and take longer to debug and
fix. With our current process, a great deal of new code can be
committed while the gnarly problem in last tarball is being debugged.
Why would we think that the new code is any less likely to contain
serious bugs than the previous set of changes? How do we get off this
treadmill?
Greg
Re: 2.0.24 ready for beta?
Posted by Ryan Bloom <rb...@covalent.net>.
I disagree quite strongly. Take a look at the CHANGES file for 2.0.25.
We have fixed at least on seg fault in mod_mime, a memory leak in
mod_mime_magic, and two major fixes to the build system.
2.0.25 is far better than 2.0.24, and I have very little confidence in re-tagging
a week after the original tag.
The whole point of the current build system, is that we can re-tag every
week if we have to, or want to. The re-tagging is meant to be a way to
allow us to get a release out immediately after the original tag. It should not
be a way to use older trees IMO.
Ryan
On Thursday 23 August 2001 08:40, Bill Stoddard wrote:
> Lets get all the mod_include patches in then bump mod_include's tag to
> 2.0.24. That will clear us for a 2.0.24 beta should we decide that's what
> we want to do. Then tag 2.0.25 and see if it compiles everywhere and runs
> on daedalus. I have a lot of confidence that 2.0.24 will fly now but no
> confidence in 2.0.25.
>
> Bill
>
> > I have been thinking about this a lot, and I would personally prefer to
> > re-tag to 2.0.25, and go beta. There have been a LOT of improvements in
> > other sections of the code, and re-tagging after this long is just asking
> > for trouble.
> >
> > Ryan
> >
> > On Thursday 23 August 2001 08:09, Bill Stoddard wrote:
> > > With the last mod_include fix, can we bump the tag on mod_include and
> > > go beta?
> > >
> > > Bill
> >
> > --
> >
> > ______________________________________________________________
> > Ryan Bloom rbb@apache.org
> > Covalent Technologies rbb@covalent.net
> > --------------------------------------------------------------
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.24 ready for beta?
Posted by Bill Stoddard <bi...@wstoddard.com>.
Lets get all the mod_include patches in then bump mod_include's tag to 2.0.24. That will
clear us for a 2.0.24 beta should we decide that's what we want to do. Then tag 2.0.25 and
see if it compiles everywhere and runs on daedalus. I have a lot of confidence that 2.0.24
will fly now but no confidence in 2.0.25.
Bill
>
> I have been thinking about this a lot, and I would personally prefer to re-tag
> to 2.0.25, and go beta. There have been a LOT of improvements in other
> sections of the code, and re-tagging after this long is just asking for trouble.
>
> Ryan
>
> On Thursday 23 August 2001 08:09, Bill Stoddard wrote:
> > With the last mod_include fix, can we bump the tag on mod_include and go
> > beta?
> >
> > Bill
>
> --
>
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
>
Re: 2.0.24 ready for beta?
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 23 August 2001 08:35, Cliff Woolley wrote:
> On Thu, 23 Aug 2001, Ryan Bloom wrote:
> > I have been thinking about this a lot, and I would personally prefer
> > to re-tag to 2.0.25, and go beta. There have been a LOT of
> > improvements in other sections of the code, and re-tagging after this
> > long is just asking for trouble.
>
> I'm game for that as well, assuming those other things I mentioned before
> get committed. However, if we're going to do this, let's get daedalus
> running 2.0.25 right away after the tag, since that seems to be one of the
> only steadily-flowing sources of real world bug-finding information we
> have right now. If 2.0.25 starts to show problems when it gets put up on
> daedalus, I'm still +1 for beta on 2.0.24 (with the mod_include fixes).
The biggest problem I have with 2.0.24, is the build system. Libtool 1.4 is
getting more common. Our build system was broken for shared modules with
libtool 1.4 until two days ago. I still want to fix APXS, but that is going to take
a bit more time. :-)
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.24 ready for beta?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 23 Aug 2001, Ryan Bloom wrote:
> I have been thinking about this a lot, and I would personally prefer
> to re-tag to 2.0.25, and go beta. There have been a LOT of
> improvements in other sections of the code, and re-tagging after this
> long is just asking for trouble.
I'm game for that as well, assuming those other things I mentioned before
get committed. However, if we're going to do this, let's get daedalus
running 2.0.25 right away after the tag, since that seems to be one of the
only steadily-flowing sources of real world bug-finding information we
have right now. If 2.0.25 starts to show problems when it gets put up on
daedalus, I'm still +1 for beta on 2.0.24 (with the mod_include fixes).
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: 2.0.24 ready for beta?
Posted by Ryan Bloom <rb...@covalent.net>.
I have been thinking about this a lot, and I would personally prefer to re-tag
to 2.0.25, and go beta. There have been a LOT of improvements in other
sections of the code, and re-tagging after this long is just asking for trouble.
Ryan
On Thursday 23 August 2001 08:09, Bill Stoddard wrote:
> With the last mod_include fix, can we bump the tag on mod_include and go
> beta?
>
> Bill
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: 2.0.24 ready for beta?
Posted by Jeff Trawick <tr...@attglobal.net>.
Cliff Woolley <cl...@yahoo.com> writes:
> On Thu, 23 Aug 2001, Bill Stoddard wrote:
>
> > With the last mod_include fix, can we bump the tag on mod_include and
> > go beta?
>
> After Greg puts back in the two other fixes he accidentally reverted in
> his last commit and commits whatever fix it is that is running on
> Daedalus for the sentinel-as-a-bucket thing, then ++1, let's get this bad
> boy out the door. :-)
ditto for me
As far as HEAD/2.0.25/whatever:
I need to spend some time with HEAD on various platforms to make sure
DSOs and static builds are both working fine. I was getting screwy
failures related to the build changes for a while; not 100% sure
everything is working yet.
Now I'm getting some disturbing warnings in mod_include and mod_cgid
(the fun never ends!).
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: 2.0.24 ready for beta?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 23 Aug 2001, Bill Stoddard wrote:
> With the last mod_include fix, can we bump the tag on mod_include and
> go beta?
After Greg puts back in the two other fixes he accidentally reverted in
his last commit and commits whatever fix it is that is running on
Daedalus for the sentinel-as-a-bucket thing, then ++1, let's get this bad
boy out the door. :-)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA