Re: adopt www.apache.org site design
On Wed, Apr 23, 2008 at 1:04 PM, Joshua Slive [EMAIL PROTECTED] wrote: Any objections to adopting the new www.apache.org site design? The httpd site is looking a little dated, in my opinion. +1 to switching. Those who are complaining know where the source is and they can improve upon it themselves if they so desire. Until then, sure, this design is, IMO, more accessible than what's there now. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conference banners on http://httpd.apache.org/ ?
On 10/17/07, Rich Bowen [EMAIL PROTECTED] wrote: What's the necessary approval chain to make a change to http://httpd.apache.org/ ? In particular, I'd like to add banners for us.apachecon.com and ossummit.com I'm not clear if I should just go ahead and do it, or if I have to have the approval of a certain number of people. Just do it. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_proxy_balancer
On 6/18/07, Rich Bowen [EMAIL PROTECTED] wrote: Can someone set me straight? I have some functional examples from various tutorials, but it would be really nice to have working examples in the documentation, rather than vague allusions to cool functionality. This is a wonderful module, and we need to help people use it. Who should I be speaking with, and is he/she on this list? If it's helpful, my slides from last years' OSCON talk on mod_proxy are on my site: http://www.erenkrantz.com/oscon/OSCON%202006%20Apache%20mod_proxy.pdf Feel free to borrow whatever you'd like from there or link to it or whatever. Go crazy. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changes/commits to httpd.apache.org
On 6/18/07, Jason Lingohr [EMAIL PROTECTED] wrote: I'm a little confused. A while back, one would commit the xdocs changes to the repos, and the site would hourly rebuild the HTML and populate our website. That's never been automatic - you have to commit the output of the HTML generation and then run svn up on the people.a.o checkout. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: search engine in apache docs
On 6/13/07, Sander Temme [EMAIL PROTECTED] wrote: browser. While we'd obviously not be flying that high, would the ASF be entitled to any such revenue from our own search box, or the individual who happens to own the account? FWIW, we don't want to be involved with any such ad-sharing from Google (or anyone else for that matter) - there are deep tax implications involved for our non-profit status. So, turning off ads is just fine... -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Linking to Rich's book
On 5/31/07, Vincent Bray [EMAIL PROTECTED] wrote: Or another option could be to update the httpd books page and link to that. http://httpd.apache.org/info/apache_books.html I'd prefer to use the Apache Bookstore wiki off: http://www.apachebookstore.com/ - just because links off that site help the ASF and its 'officially' sanctioned. Plus, it's more of a 'central' resource than maintaining something off our website or on our own wiki. However, I'll note that some smart aleck renamed the httpd page. I'll poke Ted about fixing that. Thanks. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Linking to Rich's book
On 5/31/07, Vincent Bray [EMAIL PROTECTED] wrote: Perhaps you'd remind him to add Nick Kew's modules book and Rich Bowen's rewrite book too? Well, it's a wiki - you can add it. =P (I just fixed the page name and some other minor tweaks.) Whom should I poke to get this page updated (the link to atlassian is wrong)? http://httpd.apache.org/info/apache_books.html The source file is here: http://svn.apache.org/repos/asf/httpd/site/trunk/xdocs/info/apache_books.html Feel free to submit a patch - someone will commit it. Thanks! -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rewrite wiki
On 5/30/07, Vincent Bray [EMAIL PROTECTED] wrote: There seems to be a consensus that the wiki should be used for guides and cookbook oriented material whereas the official docs are for the technical details of rewrite's operation. I'm biased towards this idea as it's hard to get stuff looked at for non-committers on this list at the moment (the archives have several ignored patches). Well, uh, we're working on that front too. Just wait. =) Looking at Rich's older rewrite wiki, it seems to be geared more towards explaining the behaviour of rewrite's various directives and flags than towards being a cookbook. There's a lot of good stuff in there, but I'd like to restructure it and extract the recipe related material for the wiki. Makes sense. As Joshua once said, This is docs land. Don't wait for consensus, just do it (paraphrasing badly). So, I'm going to carry on along these lines unless anyone thinks this isn't the right approach. Any help would be appreciated of course :-) Go for it! -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Issue] External links @ the wiki, aka pagechange wars
On 5/24/07, Jim Jagielski [EMAIL PROTECTED] wrote: On May 24, 2007, at 8:50 AM, Colm MacCarthaigh wrote: On Thu, May 24, 2007 at 08:05:30AM -0400, Joshua Slive wrote: External links are encouraged where they add substantial value, but you may not link to your own pages or otherwise seek private benefits from external links. I like the elegance of this rule, because if it's your page and you words, well you can just add the content to the wiki anyway. But at the same time it may invite even more awkward and inappropriate behaviour, e.g. paying someone else to add the links on your behalf. I think this problem is always going to fall into the We know abuse when we see it category, it requires a vague kind of rule-making which only humans can apply. I'm in favour of banning these links in this instance, though not all external links. +1 aol / -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Issue] External links @ the wiki, aka pagechange wars
On 5/24/07, Jorge Schrauwen [EMAIL PROTECTED] wrote:
Maybe one rule that states that {INSERT AUTHERIZED PEOPLE HERE} can
make a decision on a dispute. Example: some external link that provide
bad/false or not prefured information.
If that person/persons decide the link needs to go it should.
Optionally these decision can be posted to [EMAIL PROTECTED] for comunity
input.
That group should be the members of the HTTP Server PMC. We don't
need to create yet another group for wiki oversight - the current
oversight is working well (more or less) - this is an instance of that
oversight kicking in.
(I am all for people who help with documentation to be on the PMC.
Those PMC members who are following such activity should feel free to
nominate worthy folks to the PMC!) -- justin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r332958 - /httpd/httpd/branches/2.2.x/docs/manual/style/build.properties
On Sun, Nov 13, 2005 at 11:58:09AM +0100, Andr Malo wrote: Good point. I haven't figured out yet a way to unify the code and docs trees in this regard (docco folks typically have only the docs tree checked out). I honestly don't care if it is unified. A single value to change in the docs tree would be sufficient. If we can unify that lone value at a later date with the code tree, cool, but not as important as getting a single value in the docs directory, IMHO. Thanks for the prop fixes. I didn't get any error about the empty tags being invalid - I wonder why you did. -- justin `build validate-xml` :-) [1] It might be questionable to reject empty lists, though. We can change the DTDs if we want to. *nod* [1] `build -projecthelp` shows all possible targets FWIW, I tried 'build help' and it didn't do anything. So, I gave up trying to get help. =( -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: document location using SVN
--On Wednesday, January 5, 2005 1:53 PM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: I'm guessing that somebody forgot the snafu in cvs where 1.3 docs were separate from 1.3 code, resulting in the 1.3 docs being accidentally omitted from svn. Partially right: the 1.3 docs weren't separate at one point, so they have overlapping branch info with the 1.3 code. Furthermore, the 2.0 docs were *copied* from the RCS files. (The httpd-2.0 code repository was a clean import rather than a copy.) So, the 2.0 docs had the same branch info for everything up until the 1.3/2.0 branch point. Hence, you can't import both of them cleanly. About every single mistake possible with copying in CVS is illustrated in the httpd-docs-1.3 module. Sigh. Personally I have no idea how to get the 1.3 docs into the 1.3 svn branch and maintain old revision history. Doable, but it's a significant amount of effort. The two easiest solutions would be: 1) abandon the docs entirely (see Rich's post), or 2) ditch the history (they will be available with CVS) and just import the latest docs into the 1.3 branch. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: document location using SVN
--On Wednesday, January 5, 2005 11:38 PM +0100 Sander Striker [EMAIL PROTECTED] wrote: or 2) ditch the history (they will be available with CVS) and just import the latest docs into the 1.3 branch. works for me Yeah, given the effort/return ratio here, I'll put my +1 here. Okay, so it seems we have a consensus for #2. However, httpd-docs-1.3 contains more than was checked out with apache-1.3: http://cvs.apache.org/viewcvs.cgi/httpd-docs-1.3/ The htdocs dir was automagically checked out into apache-1.3. I will import that shortly. But, where should the rest of it go? apidoc/ and the top-level directory hasn't been changed in roughly 3 or 4 years! So, the fact that there's no obvious home leads me to believe they might just be skipped... Anyone? -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web site translation
--On Monday, November 29, 2004 6:33 PM -0700 Paul Querna [EMAIL PROTECTED] wrote: Do other developers have objections to moving the website to XSLT (like the manual) instead of the current Velocity/Anakia? I would recommend that any initial XSLT source transforms be kept as close to the Anakia templates as possible. (i.e. keep section, etc.) Otherwise, we're only going to change it to change it and we shouldn't have to force ourselves to learn something new just because one or two think it's cool - and that's bad. My secondary goal is that we should ensure the build process and file layout is as simple as it is now with httpd-site. If it doesn't work or is confusing, people will tend to ignore the site. IMHO, this is probably why some developers don't touch the docs as they might otherwise. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web site translation
--On Monday, November 29, 2004 11:44 AM +0900 Yoshiki Hayashi [EMAIL PROTECTED] wrote: More than a year after I proposed web site translation, I finally sat down for a while and did necessary coding to add translation support. BTW, this might need to be discussed on [EMAIL PROTECTED] as well. This is going to affect all developers who touch the site. Does anyone object to the direction we are going? i.e., having translation of web site at all? No, not really. However, I'm concerned about how long the translations could stay out of sync. There's going to be times when we try to post an urgent notice and if the translator is asleep (or AWOL for a few weeks), then that's troublesome. One idea: perhaps when we change the English version of a page, we pull all translations until the individual translation is sync'd up? Now that we have true version control software, I think the way to go is to create a branch like Paul did. I'm going to create https://svn.apache.org/repos/asf/httpd/site/branches/translation unless someone objects. Is there any policy on how to create and use branch? That's fine, I guess. However, if we have two branches going: one for css deployment and translation, that could end up being nasty to merge back together I extended Anakia to do some new things like providing context to get available languages and getting the destination filename. I'd like to put the source code somewhere in Subversion repository. Where shoud I put it? https://svn.apache.org/repos/asf/httpd/site-build looks like a good candidate to me. First, you should post the source code changes either to here or [EMAIL PROTECTED] so that we can review it. I'm not sure what exactly you changed. Did you change Velocity? Or, just the Velocity templates that we used? -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web site translation
--On Monday, November 29, 2004 1:10 PM +0100 André Malo [EMAIL PROTECTED] wrote: (And when I see the output of the forrest using projects, I don't like it). You aren't the only one. Forrest frequently produces non XHTML pages. Plus, forrest is a disaster to run. No way we're going to use Forrest. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: moving docs build tools to httpd
--On Friday, November 26, 2004 8:06 AM +0100 André Malo [EMAIL PROTECTED] wrote: Did you already mv them, nd? Nope. Justin...? :-) Done. =) -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
program tag a la module tag?
While I don't know how to do this, I think it'd be nice if we had a tag that acted similarly to module for programs. For example programhtcacheclean/program would act similarly to modulemod_cache/module. I don't profess to know what it'd take to do this, but it'd be nice. If it's too much, feel free to ignore me. =) -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: program tag a la module tag?
--On Saturday, November 27, 2004 10:27 PM +0100 André Malo [EMAIL PROTECTED] wrote: Actually I've thought about it from time to time, too, so +1. How should it look? Any idea? Just blue, monospace? Blue, monospace is fine. I'm just interested in not having to remember where the programs/ directory is - and to make our references consistent. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: program tag a la module tag?
--On Saturday, November 27, 2004 10:44 PM +0100 Astrid Keßler [EMAIL PROTECTED] wrote: I'm not sure whether we need a program tag. module indicates a special case of link. It is a shortcut for a href=.../moduledir/... class=module. What would program indicate? Are all program documentations saved in the same directory (tree)? Do we want to use a special layout for those links? What is your intention? Well, it looks like all the support programs docs are in ../programs/..., so if it were essentially the same as modules but were for programs, that'd be ideal. It's not very much effort to add a program element. The biggest work would be, to change all existing programm links. :) I'd volunteer to help change them, of course. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: httpd-2.0/docs/manual new_features_2_2.html new_features_2_2.html.en new_features_2_2.xml new_features_2_2.xml.meta
* [EMAIL PROTECTED] wrote: pquerna 2004/11/06 22:01:50 Added: docs/manual new_features_2_2.html new_features_2_2.html.en new_features_2_2.xml new_features_2_2.xml.meta Log: First Swing at a 2.0 - 2.2 New Features Document. As long as we just have 2.1, wouldn't it be better to have a new_features_2_1 document? We use the 2.1 version number all over the docs. (and I don't see 2.2 tomorrow ;) IMHO, no. 2.1 will never be a 'public' release by our versioning definition. Only 2.2 will be something that we'd recommend to the general public. 2.1 could only be at best beta. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: don't distribute docs with source?
--On Tuesday, June 3, 2003 10:52 PM +0200 Mads Toftum [EMAIL PROTECTED] wrote: Some of your concerns could probably be solved by moving the docs out of httpd-2.0 in cvs, like src and docs are seperate in 1.3. As an advisory, I'd be *really* against separating them out like 1.3. I've been really aggravated by that separation. Yes, the 2.x docs and source now have two separate build systems, but I honestly don't think it is a big deal for developers - it enforces that the docs and code represent the 'same' version. As a question, how would we deal with the branches to represent stable/unstable if we have separate source repositories for the doc and source? By keeping them in the same repository, it's trivial. I'd also say that separating out the docs into language packs doesn't seem right either as there should only be one release tarball. Having to sign and produce 20 or 30 'releases' (even if some are merely snapshots of the docs) would be confusing to both users and the poor RMs. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MPM installation example
--On Thursday, February 13, 2003 10:52 AM -0500 Joshua Slive [EMAIL PROTECTED] wrote: Ah okay. The big warning box overwhelmed me and I missed the example. Another suggestion: why not do an example with a non-existant mpm name (as in to active an mpm called varmpm_name/var use --with-varmpm_name/var. This would make sure nobody screwed themselves up with a copy-paste. Don't you mean: --with-mpm=varmpm_name/var ? -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commenting Manpages
[ Moving to [EMAIL PROTECTED] ] --On Tuesday, January 28, 2003 8:10 AM -0800 Ian Holsman [EMAIL PROTECTED] wrote: has anyone considering doing something similiar to the comment system that php does with their man pages? Rich brought this point up on the community@ list when we discussed the merits of a wiki. Rather than put words into Rich's mouth, I'll shut up and let him speak. (Or, let others have a chance to comment.) But, this discussion definitely belongs on [EMAIL PROTECTED] -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: /support
--On Saturday, December 28, 2002 4:25 AM +0100 Astrid Keßler [EMAIL PROTECTED] wrote: A lot of utilities compiled by default are mentioned to be found in the directory /support. Wouldn't it be better to point to the default installation directory /bin (in most cases) in the docs? Sure. +1. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Review] mod_deflate.xml (Revision)
--On Wednesday, November 27, 2002 6:38 AM +0100 André Malo [EMAIL PROTECTED] wrote: Good point. I read (again ;-) some sections in RFC 2616 and found: 14.11 Content-Encoding The Content-Encoding entity-header field is used as a modifier to themedia-type. [...] The content-coding is a characteristic of the entity identified bythe Request-URI. [...] *kaboom*. If I understand that correctly, it's *wrong* to serve compressed content under the same URI (and the same *entity*-tag-header). It seems, dynamic compression should be noted in Transfer-Encoding. And... I guess in that case it must not (or should not?) be noted in Vary:. hmm...??? Nah, ISTR, we have had this discussion before and we said that the ETag should remain the same even when mod_deflate is invovled. The content (barring corruption) should be identical. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion: add revision number to docs
On Sun, Sep 15, 2002 at 01:28:41AM +0200, Astrid Keßler wrote: This could be done by writing $Revision$ into the file. The CVS will replace it to $Revision: x.y $, where x.y is the revision number. As long as this string exists, revision number will automatically be updated. I think this is a bad idea. -0. There are much better ways to get the revision of the file - such as cvs stat, watching commit logs, etc. - without polluting the original file. Commit early and often if you are worried about getting out-of-sync. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review: AddOutputFilterByType (was: no doc for MaxMemFree or AddOutputFilterByType)
On Sun, Sep 15, 2002 at 02:08:45AM +0200, André Malo wrote: +pIf you want the content to be processed by more than one filter, you +have to use one directiveAddOutputFilterByType/directive +directive for each of them. Filters of the same type are processed in +strongreversed/strong order they appear in your configuration, +but see also a href=../sections.html#merginin which order +configuration sections are merged/a./p Hmm, we should be able to support DEFLATE;INCLUDES. For example: AddOutputFilterByType DEFLATE;INCLUDES text/html Err, yeah, the code doesn't like that. I'll try to fix that up today if I get a chance. Otherwise, +1. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on install.xml/install.html.en
On Sun, Sep 15, 2002 at 02:53:06AM +0200, Astrid Keßler wrote: For some of the support scripts like apxs or dbmmanage (which are written in Perl) the Perl 5 interpreter is required (versions 5.003 and 5.004 are sufficient) 5.003 or newer are sufficient. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docs for auth rewrite
On Thu, Sep 12, 2002 at 02:08:47PM -0700, Joshua Slive wrote: If we are staying with the auth rewrite, I think we need to get some docs for it right away. There was already a posting on the [EMAIL PROTECTED] list from someone who needed to run bleeding-edge cvs (for subversion) but couldn't get auth to work. The only thing I could tell him was to back up to STRIKER_2_0_41_PRE2. I'd prefer to get it finalized and people using it somewhat before we start documenting it. The code really needs to get tried out by the developers first as I'm not entirely sold on some of the directives yet. It's a chicken and egg problem, I know. =( If I have time this weekend, I may take a pass at writing some docs, but no promises. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: env.xml validation problem
On Fri, Aug 23, 2002 at 07:41:59PM -0400, Joshua Slive wrote: Sorry Justin. It seems I'm always picking on you lately ;-) Heh. No offense intended or taken. If we agreed on everything, this world would be a boring place... (In all honesty, I was going to bring up the issue of renaming it before you posted; once you posted, I just replied to your message.) I certainly don't recommend changing the actual env variable. I wouldn't have chosen that name myself, but it's done now and I'm fine with it. Which is precisely my point. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updated transformations...
ezmlm bounced the commit message, but I did this. -- justin --- jerenkrantz02/05/15 23:53:49 Modified:docs/manual/mod core.html directives.html index.html mod_access.html mod_actions.html mod_alias.html mod_asis.html mod_auth.html mod_auth_anon.html mod_auth_dbm.html mod_auth_digest.html mod_autoindex.html mod_cache.html mod_cern_meta.html mod_cgi.html mod_cgid.html mod_charset_lite.html mod_dav.html mod_deflate.html mod_dir.html mod_env.html mod_example.html mod_expires.html mod_ext_filter.html mod_file_cache.html mod_headers.html mod_imap.html mod_include.html mod_info.html mod_isapi.html mod_log_config.html mod_mime.html mod_mime_magic.html mod_negotiation.html mod_proxy.html mod_rewrite.html mod_setenvif.html mod_so.html mod_speling.html mod_ssl.html mod_status.html mod_suexec.html mod_suexec.ja.html mod_unique_id.html mod_userdir.html mod_usertrack.html mod_vhost_alias.html mpm_common.html mpm_netware.html mpm_winnt.html perchild.html prefork.html worker.html Log: Transformations done with Xalan-J. (No one could reproduce the transformations that were in CVS, so regenerate the entire shabang.) - transforms deleted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xml build system
On Wed, May 08, 2002 at 07:28:37AM -0400, Rich Bowen wrote: Agreed, but if most of the developers were to use an XML browser, the conversion could be done, say, once a week, by someone with the know-how, rather than having to have all of the individuals involved know how to do it. The rationale for standardizing on a specific XML toolset is so that the conversions in the repository don't consistently flip-flop. Right now, if everyone were to use their own transformation tools and versions, the diffs in the repository would be horrendous. I would back the rationale for updating the HTML at the same time as the XML so that our website could be properly updated when the docs change. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: German translation
On Sat, Mar 02, 2002 at 07:37:47PM -0500, Cliff Woolley wrote: The documentation is covered under the Apache Software License same as everything else I believe, so nothing's stopping anybody from taking the documentation, doing whatever they want to it, and publishing it. :) What a dry book that'd be! -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New website...
On Thu, Nov 08, 2001 at 01:14:29PM -0800, Justin Erenkrantz wrote: Converted the contributors page to Anakia format, so that is the last major page on httpd.apache.org that needs to be converted... http://httpd.apache.org/~jerenkrantz/httpd-site/ http://httpd.apache.org/~jerenkrantz/httpd-site/contributors/ http://httpd.apache.org/~jerenkrantz/httpd-site/info/ Anyone have a problem if I check in what I have now to httpd-site? (Not necessarily make it live just yet though...) Should I cvs delete the old files, or should I move the ,v files over? -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
