Auto-office responders who don't respect bulk headers
That's an interesting idea; let's include infrastructure in this discussion. Bill Lilianne E. Blaze wrote: Hello, All or almost all of such messages have their subject ending with "is out of the office." or "ist außer Haus.". Wouldn't it be possible to just set up a list-server filter rejecting everything matching that pattern? Greetings, Lilianne E. Blaze Lyndon Tiu wrote: Some ass-hole in Belgium is flooding the list, can the list administrator block this email address please. Thanks. -- Lyndon Tiu On Thu, 13 Oct 2005 02:44:00 0200 dev@tomcat.apache.org wrote: I will be out of the office starting 13/10/2005 and will not return until 14/10/2005. For urgent matters please contact Valerie Wydooghe, Luc Hoste, Marieke Lemey, Daikin Europe N.V. Zandvoordestraat 300 8400 Oostende Belgium BTW BE 0412.120.336 RPR Oostende Tel: (+32)59/55 81 11 Fax: (+32)59/55 88 99 http://www.daikineurope.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JK] Status -- was [VOTE] JK 1.2.15
Mladen Turk wrote: Hi, Do you guys find something that would prevent 1.2.15 to be declared as stable that I'm missing? I'll try to find cycles to test myself, next week. I know I'm having alot of trouble with the apache 1.3 build on odd architectures, probably because the clash of a libtool-based mod_jk.so.1.2 v.s. non-libtool based httpd 1.3. I'm working on cleaner autoconf against httpd-2.0 already for building mod_ftp, which will probably apply very cleanly here as well. If not, please, let's vote that since it's the latest release from CVS, so we can move to the SVN releases and create a JK 1.3 branch we spoke so many times about. Lesson learned in httpd-land, don't let this stop you. One thing we had learned, if you don't have a sandbox/new dev branch ready, then lots of good 'new ideas' get forgotton months later when the new branch is finally created. Go ahead and branch already, if you don't place the files in the http://www.apache.org/dist/jakarta/ tree till they are truly ready, users won't be confused. Creating http://tomcat.apache.org/dev/dist/ is a good convention for such snapshots and pre-alpha tarballs, so the bleeding-edge users can begin to play in that playground. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [JK] Status -- was [VOTE] JK 1.2.15
Jean-frederic Clere wrote: Mladen Turk wrote: Anyhow, what should I do, since I've volunteer for a RM? Good questions... I mean, I don't expect to see the 1.3 branch for couple of months from now, well, that's neither here nor there w.r.t. 1.2.x - whoever needs to do new development (if 1.2 is feature-frozen) should simply branch already. Since I believe we are ready on the svn side, this is nothing more than an svn cp .../trunk .../branches/1.2.x but let's leave 1.3 out of this immediate discussion and the 1.2.14 is unusable on Solaris, so we need some action. The 1.2.15 (bugfix) release is the only thing that is implementable right now, thought. Agreed, it's time to release a 1.2.15, but this is where the RM's job is very frustrated, working independently, as opposed to working with the dev list. I don't remember much chatter before 1.2.15 suddenly appeared, but when most of the dev@'ers are on different pages, it can take a while to all get back in sync. (FWIW - 1.2.15 is going to my QA folks tonight. You probably are aware that I had almost every free hour invested in the last few weeks getting out new apr and httpd versions. Sorry that my focus was elsewhere.) There are 10 open bug, what about trying to close them before the release? That's also irrelevant - is 1.2.15 the best available version? If so, let's release (and if you want to squish 10 bugs in a week, jf, feel free to RM yet another release then!) The issue (not a problem, unless you are a user who makes no contribution) is that nobody 'schedules' Apache fixes, each contributor scratches their own itch. When everything is healthy, this means that -someone- is likely to see a significant bug squished, or a competent user steps up to squish it themself and offer a patch. Since there was no reactions to the VOTE either pro or contra for more then a mont, seems to me we are in a serious problem, Howso? ... because the developers/commiter interest is blocking the release. That's not a problem, that's a symptom. But you presume it's an unhealthy symptom... The final solution is either to bring that to the tomcat pmc, and if there is really zero interest on maintaining mod_jk, among the current commiters, it should be either shut down, or proposed as a new project with a different set of maintainers. Mladen, this is a bit over-the-top :) You know full well... * you can fork and call your code base mod_jk_mt - nothing wrong with that, it's under the Apache License. Don't call it mod_jk/Apache Tomcat Connector and don't host it on apache.org. Don't feel put-upon if such an effort is not warmly embraced by your fellow contributors, here. * you can discuss 'why isn't 1.2.15 ready?' on list. Perhaps, as jfclere observes, that some contributors have an issue with it (note no negative vote was offered, only a reason why one contributor isn't testing it.) Discussion is healthy. * you can employ patience, and ping for more testers. They will likely come along in due time. Especially Solaris testers. Recent instability may have scared some off for the time being from testing this, now very solid, newer code. * finally, you can consider that, in large measure, mod_jk is 'baked', it's been stable for years (well, 1.2.6 was), and many have little motivation to develop/test/deploy a new flavor, if they are happy with their current installation. This simply means that new releases will take a bit longer to test, and a bit longer to get feedback 'from the field'. Believe me, you aren't the first frustrated RM. But a couple-week delay is hardly cause to sound the klaxons and drop the halon :) As long as jk serves a purpose, suggesting that it be abandoned isn't the right answer. Obviously jrun was ditched because it wasn't supported, but it also was hopelessly outdated by jk. Obviously jk2 was scuttled because it just didn't measure up to jk, it didn't serve a useful need. But mod_jk serves a need, has maintainers/committers/reviewers. It's only a matter of 'sheparding cats' at this point :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Status/Authority of AJP/1.5
Questions since some interesting ideas have popped up with respect to the next flavor of AJP... firstoff, who holds the AJP standard; is it the ASF? Second, what is the status of AJP/1.5 and where is it discussed? I would like to float some various questions to not only introduce some 'flush' signal, to inform the outward facing server to stop caching (if it was) and push out a partial response; and I'd like to explore other information that could be captured with respect to balancing. Thanks! Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status/Authority of AJP/1.5
Costin Manolache wrote: I tought some time ago AJP was 'deprecated' - to be replaced with plain HTTP and mod_proxy ? Why? It turns out that mod_proxy_ajp v.s. mod_proxy_http does prove the validity of optimizing the backend connection. I don't think anyone forsees mod_jk being deprecated (at least, not insofar as it supports IIS/Netscape/Sun http servers), but from an Apache perspective, hopefully mod_proxy_ajp will make mod_jk/Apache a footnote in history :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status/Authority of AJP/1.5
Mladen Turk wrote: Henri Gomez wrote: AJP 1.5 should support automatic discovery of tomcat backend, new systems and new webapps. That's the current need for many of us when adding tomcats / webapp behind Apache 2 webservers. In such case we need to restart them and it's sad. How could it be accomplished, may be via a master tomcat who will give the tomcat farm topology to Apache HTTP2. What do you think ? Although I was evangelizing the new protocol for a long time... Looking more deeply on the subject IMHO there is no much purpose for developing such stuff unless the HTTPD offers the dynamic reconfiguration, and I doubt something like that will be considered before Apache 3.0 (as I understood). You can trigger a restart inside of httpd2 (a graceful)... which is an optimal solution. Even if mod_proxy_ajp doesn't immediately support it, why not start with mod_jk? We play lots of twisted games in mod_snmp to cause dynamic configuration, recycle within the child, etc. It -can- be done. In any case, 2.4 is the next window, seeing the door close rather quickly here on 2.2 httpd. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status/Authority of AJP/1.5
Costin Manolache wrote: Security ( i.e. authentication ) might be the only reason to extend AJP - but even this can be done on top of the existing protocol, using a custom header and connection initiation. Only partly true. Let's take the HTTPS state, for example... if tomcat looks for X-PROTOCOL=HTTPS, for example, passing this from the proxy as a typical header is simply wrong for security reasons. It's too trivial to fake, and it's too expensive to guard against. The safe way is to have two header-types, one, a client HTTP-type header. The other, proxy metadata such as the protocol, SSL keys and other server variables. These wouldn't be relayed as HTTP-style headers, so therefore all sorts of proxy to backend data can be trusted. (FYI - w.r.t. the client/server certs, I don't suggest a full blown mod_ssl type of decomposition. If they want to tear apart the certificates, it sure makes sense to introspect them through jsse, no?) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JK 1.2.15
Linux, Win32 test out fine. Solaris/HP builds fine (not tested just yet), while AIX 1.3 still refuses to build properly, but that's not a new issue. +1 to release as stable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sloppy, Lazy Tomcat Developers (Was: Persistent "xmlValidation" Problem)
Remy Maucherat wrote: Bob Bronson wrote: Another lazy copout!! Even the web.xml that is distributed w/Tomcat does not validate! Did you even test this before you replied to my note or did you just assume the user was at fault??? When someone criticizes the poor state of an open sores project (as I am doing now), the typical response from the open sores programmer is to shift responsibility to the user Damned straight. Because open source is a community of users, the devs are users, users are expected to contribute - not demand, and if the end users see a problem and can fix it (I'm guessing from the brilliance of your post that it would take you but 2 minutes to fix web.xml) then post a patch for crissakes and get over it! Bob - yes, open source is not for you. Go bitch at someone who is paid to bend over for you, you haven't earned any such privilage here. Didn't your momma teach you any manners whatsoever? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.5.12 and SSL - https doesn't work, was ok with 5.5.9
Jean-Pierre Pelletier wrote: https is fixed either by removing the native-1.dll file or by replacing it by the AMD 64 bit version. It looks like there is a bug in the Windows installer that installs the 32 bit version instead of the 64 bit version on a 64 PC. I am surprise that the 32 bit version of native-1.dll wouldn't run on my AMD 64 Athlon 3400+ cpu albeit slower than the 64 bit version? Just speculation - do you have a 64 bit java running? Microsoft has never been very kind in the side effects of thunking 32 and 64 bit modules, so if you are loading the .dll into a 64 bit java, it really must be a 64 bit build. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: failure notice ????
Bovy, Stephen J wrote: <[EMAIL PROTECTED]>: Sorry, no mailbox here by that name. (#5.1.1) Notice the message text below; between the message you were looking at this month, the list was renamed (tomcat.apache.org is now a top level project.) Sorry for the confusion, use the unsubscribe address listed below. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release 5.5.14 or retag 5.5.13
Mladen Turk wrote: Hi, I know, it's been only couple of days, but the 5.5.13 build is broken because we did not tag the tomcat-native (APR) to 1.1.1 version, that is required because of extra API. Numbers are cheap, burn another. Once it's tagged and rolled, even if it's not released, it's better to simply create a new tag. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tomcat 5.8.0 - weird response on HTTP OPTIONS method
Costin Manolache wrote: I'm curious - why would you need the options method ? Obviously, as you found, tomcat does not support it ( and many other servers ), and I never heard of any use of it, even if it is in the spec. Well, in theory servlets could respond to 'options' method if they choose to - and so could the default servlet. Whoa!!! Most clients rely on this to determine if, for example, the server supports DAV. OPTIONS absolutely must be supported, per spec, and it's absense breaks, for example, some of the download managers which will use DAV retrieval using PROPGET of a given document when available, and simple GET when not. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MOD_JK2 connector for HP-UX 11i
[EMAIL PROTECTED] wrote: Hello all, Is it possible to get a MOD_JK2 connector for a Hewlett-Packard HP-UX 11i system. I'm trying to install a web app war file. The install for a Linux platform says that I would need a MOD_JK2 connector, therefor I'm assuming it's the same for HP-UX. mod_jk2 is deprecated, and has not been updated for quite some time. Please refer to mod_jk and build that connector. The configuration syntax differs slightly. Sorry to confuse you, yes mod_jk -had- be deprecated for jk2, but since the app war file in your hands was published, the project developers have abandonded jk2 as a dead end, and turned instead back to the original jk. You want mod_jk 1.2.14 or later. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using APR with tomcat leaves port 8009 bound when tomcat is terminated?
Jim Jagielski wrote: On Feb 23, 2006, at 11:53 AM, Remy Maucherat wrote: Jim Jagielski wrote: I agree that the change is a big benefit, and for most OSs we care about, SO_REUSEADDR is available. The APR call should gracefully fail... I'll plug this in later on today after some edge-case tests. In AprEndpoint, there are a lot of Socket.optSet(serverSock, Socket.APR_SO_REUSEADDR, 1); Yes, the only rub is that for reasons I'm trying to remind myself why, we do the setting before the bind under non-Windows, and afterwards on Windows... If you SO_REUSEADDR before on win32, you will share any existing port that's previously opened by any other application. Not cool :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: never say never...
Glen Mazza wrote: Haroon Rafique wrote: On Tuesday at 12:54pm, JB=>Jay Burgess <[EMAIL PROTECTED]> wrote: JB> The following comments are not intended to be a personal attack on JB> anyone. However, I can't stand by and watch George speak my mind for JB> me, word for word, and not chime in and say "I agree!". Plus, I think JB> if you took a poll, you'd find he speaks for a large number of list JB> subcribers. Yes Jay, other members have that feeling too. If we take a look at the recent past, there are various examples of rudeness, impropriety and lack of respect. Well, my sympathies are more with the Tomcat developer team, given the abuse they incur from certain unfortunate individuals in the user community. You mean by the same unfortunate individuals who like to abuse their checkout clerk, bank teller and doctor's receptionist? Odd, they tend to excuse themselves that they are paying for that privilage; Funny I don't recall seeing a donation check from them to the ASF. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using APR with tomcat leaves port 8009 bound when tomcat is terminated?
D'OH!!! Why doesn't this become an apr_sockattr element to the apr_socket_create or apr_socket_bind call, so that APR determines the before/after thingy? One side note, you setopt *after* the bind if you want to know you are the absolute owner of the socket. you setopt *before* the bind on win32 if you know your app owns the socket and now you want to add additional listeners (processes) to pay attention to it. Dunno how we could map this all that cleanly. Bill William A. Rowe, Jr. wrote: Jim Jagielski wrote: On Feb 23, 2006, at 11:53 AM, Remy Maucherat wrote: Jim Jagielski wrote: I agree that the change is a big benefit, and for most OSs we care about, SO_REUSEADDR is available. The APR call should gracefully fail... I'll plug this in later on today after some edge-case tests. In AprEndpoint, there are a lot of Socket.optSet(serverSock, Socket.APR_SO_REUSEADDR, 1); Yes, the only rub is that for reasons I'm trying to remind myself why, we do the setting before the bind under non-Windows, and afterwards on Windows... If you SO_REUSEADDR before on win32, you will share any existing port that's previously opened by any other application. Not cool :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Native Question
Fenlason, Josh wrote: I should have checked this before the vote for 5.5.16 was closed, but I just realized that in 5.5.16 the native connector is still at 1.1.1. Question, does TC-Native 1.1.1 share the same flaw as mod_jk, mod_proxy_ajp? We would need to repack the 5.5.16 or release 5.5.17 If this flaw is present, clearly 5.5.17 is called for. If the flaw is not present, or irrelevant due to the fixes in Tomcat connectors themselves, then I'd agree with that noop alternative and let folks obtain 1.1.2 on their own if there is a bug fix that affects them. No matter which, 5.5.17 will be along someday soon enough to encourage folks to try out tcnative, and those following the dicussion closely are probably already obtaining it independently. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Native Question
Mladen Turk wrote: It's irrelevant. 5.5.16 will not work with 1.1.1 Then I'd think there are two solutions; 1. repackage 5.5.16 -without- jknative. 2. roll 5.5.17 with jknative 1.1.2 It sounds like the 5.5.16 package is fundementally flawed. Retracting a component to avoid confusion amoung users doesn't change the essential nature of the package, does it? jknative clearly isn't quite at the same stability as Tomcat 5.5 as a whole, or well proven connector technology like mod_jk. jknative is getting there, for sure :) But is it there yet? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Native Question
William A. Rowe, Jr. wrote: Mladen Turk wrote: It's irrelevant. 5.5.16 will not work with 1.1.1 jknative is getting there, for sure :) But is it there yet? I should have asked the question this way instead... "Is jknative a faster moving target than the Tomcat 5.5 releases themselves?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk [STATUS]
Chris Lamprecht wrote: Mladen, Thanks for applying the busyness patch (and the other fixes)! Once 1.2.16 is tagged, I'll try to test it on our setup. We're still running our lb-busyness-patched version with 1.2.14. If there's any hope of waiting a day or few, I'd like to ensure this can be configured and built to both 2.0 and 2.2 on windows and unix. At one point I thought I had started the effort, but had invested no energy at that time on the unix build. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk [STATUS]
Mladen Turk wrote:
William A. Rowe, Jr. wrote:
If there's any hope of waiting a day or few, I'd like to ensure this can
be configured and built to both 2.0 and 2.2 on windows and unix.
Sure, no problem.
I wish that we have at least a stable release as 1.2.15 was,
so what ever it takes :)
It looks like all the glue is there. From jk/native/, running ./configure
--with-apxs={some 2.2/2.3-ish apxs} works fine (although it's reinventing
it's own preference for gcc when apache/apr is built with cc on Solaris).
However, invoking make does -not- work in that directory. I don't know;
is this expected to work? Changing to the apache2.0/ subdirectory and
invoking make; make install works just fine against apache 2.2 (yeay!)
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk [STATUS]
Mladen Turk wrote: Sure, no problem. I wish that we have at least a stable release as 1.2.15 was, so what ever it takes :) Quirks; ../common/jk_ajp_common(1627) warning: loop not entered at top. Build is invoking cc (as apxs declared) using the wrong cflags (detected from ./configure finding gcc.) Explicitly setting CC=cc solves it. Finally, my earlier comments about it 'not working' when you invoked make from the top level jk/native, as opposed to jk/native/apache2.0/ might be tied to this gcc/cc fluxor, because i don't see the problem now. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk trunk: wrong version in configure.in?
If you run automake, it's still brought in, so necessary to keep it in sync. Mladen Turk wrote: Rainer Jung wrote: While playing around with svn checkout of mod_jk trunk (1.2.16-dev) I saw, that in jk/native/configure.in there is still a line VERSION=1.2.14 Right, but it's irrelevant. We have jk_version.h. I think this was meant to be used for packaging tasks that BTW doesn't exist. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: configurable AJP Buffer Size
Mladen Turk wrote: Henri Gomez wrote: well client and server should be in phase about the buffer size and the better way to accomplish that will be via AJP13 extensions (ie AJP14), with connect time negociation datas like packet buffer size :) Right. Extensions could contain packet size. The problem is that even with the custom size that size would be limited to 32K, and again someone will complain about that limitation ;) AJP14 should have by default both connect and disconnect packets in a CPING/CPONG fashion. +1 - anything from 1536 to just under 64k might be useful depending on the pipe architecture and hardware in between. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: "Critical poller failure" when using tcnative
Jean-frederic Clere wrote: Remy Maucherat wrote: Mladen Turk wrote: Right. I was hoping to have the native release by the end of the week also. Since installer depends on outside natives, the native should be out before the 5.5.17. FWIW apr is on the cusp of that next release; tarballs being voted on for release on the [EMAIL PROTECTED] channel are available for test @ apr.apache.org/dev/dist/. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat v5.5.17-beta Now Available
Whoa :) I don't see a vote thread? alpha, beta, gamma, gold, it doesn't matter... any "tarball release" from the Apache Software Foundation must be preceeded by a vote. Bill Yoav Shapira wrote: The Apache Tomcat team is proud to announce the immediate availability of Tomcat v5.5.17-beta. This release contains dozens of bug fixes and a number of other updates. Please consult the change log below for more details. Release Notes: http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES Change Log: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-55.cgi Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat v5.5.17-beta Now Available
Bill Barker wrote:
"William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Whoa :) I don't see a vote thread?
alpha, beta, gamma, gold, it doesn't matter... any "tarball release" from
the
Apache Software Foundation must be preceeded by a vote. explanation>
Long established practice in Tomcat-land: The 5.5.17 release is currently
nothing but a tarball (and, so we call it Alpha). Yoav will probably call a
vote later in the week, or next. At that point it will get a GA/Beta/Still
Alpha rating.
Aye I understand that - I'm stating it's not valid at the ASF to push something
at Announce@ anylist until dev@ makes a (initial) decision, e.g. you could do
the first vote for alpha, second vote for beta, third vote for GA, or ballot all
three choices (choosing the 'best' rating with 3 +1 and more + than -, or what
have you). How you vote is up to the project. Not voting isn't a choice within
the foundation. Essentially, the RM personally hangs their ass out to dry by
posting such an announcement, because the ASF protection ("It's -our- code, not
a specific individuals - yell at -us-, we'll duke it out in court etc") only
kicks in once the voting process is followed.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat v5.5.17-beta Now Available
Remy Maucherat wrote: Yoav Shapira wrote: Hola, I don't mind changing the process, but as the other Bill noted, what we've been doing for a while is: The process never changed: originally, I was releasing builds (= alpha equivalents) that were then voted as "alpha, beta or stable" in a single subsequent vote. This AFAIK is compliant with the ASF releases rules. Yes, as long as it is not announced as the release, but announced as the candidate, tarball, what have you. I noted specifically that Yoav sent this to announce@ which is definately verboten, pre vote. We vote on tarballs, fwiw, we don't vote on tree-stability. I've been slammed for trying to do just that by the original policy authors :) Not trying to create waves here, but just make everyone aware (as I did about a year ago on one of Mladen's candidates) what the policy is, for the protection of whomever voulenteers to RM a release! The process of voting is the action the ASF board designated for the project/ASF to collectively assume responsibility for what goes 'out the door'. Once those three +1's (more +1 than -1) are collected, the project *assumes* responsibility for the end result, and it's no longer the RM's result, it's an ASF result. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat v5.5.17-beta Now Available
Yoav Shapira wrote: Bill, Yes, as long as it is not announced as the release, but announced as the candidate, tarball, what have you. I noted specifically that Yoav sent this to announce@ which is definately verboten, pre vote. This might be a nitpick, but I believe I sent it to [EMAIL PROTECTED], [EMAIL PROTECTED], and [EMAIL PROTECTED], NOT [EMAIL PROTECTED] apache.org address. The apachenews.org site, as you know, is a sort of news site for Apache events (not just final releases), operated by Tetsuya who's an ASF member. Its audience and purpose are quite different from [EMAIL PROTECTED] I wonder if that caused some confusion? Yes (I misread it) and no, it must not be broadcast to users@, or any external list, until the PMC approves it... rereading from apachenews. April 15, 2006 15 April 2006 - Apache Tomcat v5.5.17-beta Now Available The Apache Tomcat team is proud to announce the immediate availability of Tomcat v5.5.17-beta. I would say the team did not announce this (there was no vote) but YS announced this. I know this seems like a longwinded thread over a silly nit, but there is most definately a legal difference, and I just want to ensure all of our members and committers protect themselves :) (The rest of your message is understood, agreed) :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat v5.5.17-beta Now Available
Yoav Shapira wrote: Hi, OK, no problem. So what's our consensus process going forward? Same as before but with a formal vote to cut the release, and same announcements but calling it a "release candidate" instead of a "release" ? 0. usual banter asking 'suppose trunk|branch x is good to go?' 1. roll a tarball 2. post to dev voting to release the package (as alpha/beta/final if you like). 3. tally, -then- post to users, announce'es etc (calling for an upgraded beta/final designation if you want the public to comment, nonbinding). 4. if you like, vote as a pmc to accept the new designation (or count pmc's votes on the thread 3. above), choosing it's 'final designation'. Almost exactly what you do now, but the vote preceeds the 'team announces the release of' post. W.r.t. 5.5.17, get the vote done, I wouldn't bother with any special handling at this point :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Shipping tomcat[5|6].exe binaries with .zip distribution
Mladen Turk wrote: > > Right now we are only shipping windows 32-bit binaries > inside .zip distro. Can we modify the build so the > zip contains windows 64-bit amd64/emt64 and ia64 > binaries as well. I just question how widely deployed ia64 is - it appears mostly abandoned. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
Guenter Knauf wrote: > 3) where do the older versions go? Trivial answer; http://archive.apache.org/dist/ is a complete historical record of http://www.apache.org/dist/ - all automated. So delete stale flavors at will. Rainer Jung wrote: > > I had no permissions to delete them, I'll write to the owners directly > to remove them. You can often find someone with root perms hanging out on #asfinfra on irc.freenode.net, or can email [EMAIL PROTECTED] to ask for perms to be reset to 664 as they were -supposed- to be in the first place. Do email the owners to beg them to fix their umask. I recommend that instead of your .profile/.bash_profile, you fix them in your .bashrc and .cshrc files, so that scp picks them up by default when depositing files via scp. umask 002 is all you are looking for to ensure 664 ownership. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk build: threading detection broken
Rainer Jung wrote: > > I checked installed Apache httpd to find out, how we could detect the > threading model of the apache httpd against we compile. Unfortunately we > can only find out the name of the MPM, but not (at least not in a robust > way) if it is threaded or not. ap_mpm_query (ap_mpm.h) is what you want. Yes - you can ask AP_MPMQ_IS_THREADED on win32, netware, unix, etc etc. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r544137 - /tomcat/connectors/trunk/jk/native/common/jk_uri_worker_map.c
[EMAIL PROTECTED] wrote: > Author: mturk > Date: Mon Jun 4 05:08:33 2007 > New Revision: 544137 > > URL: http://svn.apache.org/viewvc?view=rev&rev=544137 > Log: > Add simple URI normalizer that can deal with things like %252e%252e. This is > mostly copy/paste from the IIS module You have me way confused ;-) The uri you are processing in the httpd connector has already been unfolded. So your desire is to double-unfold the uri? This has some very ugly side effects for legitimately escaped paths, and if it is a security precaution, don't you just leave yet-a-new-hole for triply-folded uris? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Removing the examples (JSP/servlet) in TC Binaries
Rainer Jung wrote: > I'm not sure. They provide an easy entry point for people using Tomcat > because it is so simple to just use them. There are a couple of choices: > > - leave the examples in the download and take their security serious. > This is what we do now. good choice... > - leave the examples in the download, but don't bother about their > security, as long as they don't compromise the container security (e.g. > don't bother about XSS issues for the example webapps). good choice, *if* you set up only a localhost endpoint and clearly document that the examples are only that, and open to XSS and other issues. Actually... > - move the examples into a separate directory, so that they are not > active by default. Add a note about how to activate them. Also a better > production setup, but we'll get a lot of questions, why the examples do > not work. I guess thats what I was thinking of above. > I think the real question is, should we still take security serious for > the example webapps. If no, then we should decide, which way we disable > them. I don't have a very strong opinion, because I don't feel fine by > delivering insecure example webapps, even if they are disabled. How > should people be made aware of security in webapps, if even our example > webapps are unsafe. The arguement is that some authors start with the examples. If they are riddled with XSS exploits, their derivative code will also be abusable. It's nice if *someone* provides good reference examples; consider the mess in PHP development-by-example that's left the web in a half-usable state. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Boy, what an absurd thread... jean-frederic clere wrote: > > I would also propose that we take an handling of releases similar to httpd. > See http://svn.apache.org/repos/asf/httpd/httpd/ I just want to make sure you aren't confusing the above ^^^ with below vvv > branches contains the productions branches and the experimental > developpemnt branches. > > trunk contains the place where the commmun developement and the new > agreed features and bugs fixes are going. > To move something from the "experimental developpement branches" to > trunk (or to a production branche) we vote it. (in a file named STATUS) > once accepted (no -1) the stuff enters the production or trunk. If > someone starts something in trunk and gets a -1 he should create a new > branche with the new code and propose a vote to get it back in trunk. This isn't how httpd works. Any committer can commit new features or code to trunk. Any committer can veto a commit, as well, at which point it has to leave trunk unless the author can convince the veto'er of their plan, or they agree to work together to fix the committed code to everyone's satisfaction. Or (and this is rare) there's no *technical* justification for the veto, and the rest of the committers agree it isn't valid. Now on the subject of sandboxes, they don't exist to shove off committers. They are tools for committers to use to develop their own proof of their concept. Let's face it, on radical changes, it's almost impossible to keep the development branch building until the change is complete. But it's not a purgatory to which you can shove another committers' code into. They either agree their work needs to be refined, or reverted. Revert the trunk code on a case by case basis the code that you cannot agree on, and let the author move it to a sandbox if that is their choice. That is how the httpd project handles svn. Any suggestion to "push aside" the current trunk contents shows some incredibly poor respect for fellow committers and certainly reflects badly on the state of the community and project. All of this is to say slow down, agree to back out offending patches from trunk, and just move forward to 6.5 or 7.0 or whatever it is, IMHO. You are using SVN to bully each other into agreement, which is worthless if your goal is to build back up the tomcat community. If you seek to destroy it, there is really a quicker and more efficient way to go about it. All of which I point out as simply an observer and user of Tomcat, and from years of similar debates at httpd. So take this for what it's worth. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Filip Hanik - Dev Lists wrote:
> for those not following the entire non existent revolution, here is the
> veto that was being debated
Thanks, I have a question below...
> [EMAIL PROTECTED] wrote:
>> Author: fhanik
>> Date: Tue May 29 15:23:36 2007
>> New Revision: 542678
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=542678
>> Log:
>> setup default operation
>>
>> Modified:
>> tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
>>
>> Modified:
>> tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
>> URL:
>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java?view=diff&rev=542678&r1=542677&r2=542678
>>
>> ==
>>
>> ---
>> tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
>> (original)
>> +++
>> tomcat/trunk/java/org/apache/catalina/connector/CometEventImpl.java
>> Tue May 29 15:23:36 2007
>> @@ -41,6 +41,11 @@
>> public CometEventImpl(Request request, Response response) {
>> this.request = request;
>> this.response = response;
>> +try {
>> +this.register(CometOperation.OP_READ);
>> +}catch ( IOException x ) {
>> +throw new IllegalStateException(x.getMessage(),x);
>> +}
>> }
>
> To keep with the proper commit handling procedures of the ASF, I think I
> have to veto all these changes, so that they are not considered as
> having been accepted inside an official branch. They have to be
> considered a proposal (even though the branch they live in sounds
> official), but of course, no need to revert them.
>
> Rémy
I'm confused. I see the veto, I don't see the justification in that
veto message.
What "proper commit handling procedures"? You don't vote first
on C-T-R branches like trunk. You vote against the code you don't
like with a justification of why you don't like it (and what the author
can do to help you like it.) Or you vote for it just to show moral
support.
Then you vote up or down on a release, someday in the future, when
there is an RM who wants to release it.
The rules were very deliberately designed to prevent any one person
from hijacking a project, either in releasing software the project
isn't satisfied with, or in being an obstacle to releasing software
the project is satisfied with.
Bill
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Remy Maucherat wrote: > > Since the community is a bit small, it could be useful to precise that a > single +1 (from the committer who proposes the commit) is enough for a > commit to go through, rather than the usual 3 +1s. That would be C-T-R, aye? E.g. you are -1 to adopting R-T-C on any branches if we understand you correctly. Just be aware that R-T-C on released branches is not entirely popular on httpd. It certainly is an obstacle to momentum. Nobody argues that it isn't a painful discipline. It was adopted to try to move focus to the development trunk, because without that change, Apache 1.3 would have grown forever sapping the energy of developers to actually improve upon 2.0. And to try to find a more stable, happy medium in a code base that had as many regressions as it had fixes with new releases. Jeff Trawick proposed a maintenance branch of 2.0.42 that would have been maintained for some time into perpetuity. (E.g. 2.0.42.2, .3 etc). R-T-C was adopted to try to find that middle ground between folks who wanted to package a trustworthy httpd v.s. folks who wanted to continue to innovate. /trunk/ was selected for innovation (and a sandbox when the changes would make trunk unstable for a significant period of time.) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Send trunk to the sandbox
Remy Maucherat wrote: > > Development in "trunk" is not done properly at the moment. Back up 1 step; define "proper", with pointers to the http://tomcat.apache.org/dev/ documents, if they exist. Otherwise you are doing a good job of showing the entire vote is really nothing but ad hominem attacks between a few developers, and has much less to do with code than personalities. > There's a large thread on these issues. At the time, the API design was > downright bad. It did improve to some extent (without further debate), > but this was all done in trunk without any collaboration. You just said you improved it; ergo you collaborated. You don't need dev@ mails to discuss commits until someone disagrees, just as you did. Your veto in that example said "leave it on trunk". If you now disagree that it can be improved to satisfy your original veto, restate your technical veto and just ask for the revisions to be reverted. It's project history, even if it was a failed attempt at concensus. So it belongs on svn trunk, if only in the attic. Of course all code is written without collaboration, unless you are all trying to reach a consensus character-by-character on how the source code is created. How it's integrated, or if it is at all, is a matter for the project to determine together. > I wish to move out the current trunk and use stricter commit policies to > avoid these sort of issues, and force agreement before commit. > > Rémy So you are saying trunk was used according to the project policy and you would now like to change the commit policy for trunk? That's fine, but comments that people are abusing trunk doesn't jive with what you just said that you want to change policy. Beyond withdrawing the silly vote, asking for the code you veto to be removed, and moving forward, don't you think you should hold a vote to make trunk R-T-C first? I've actually glanced through the various earlier messages and really see only two points of view expressed on the list about any of the actual code. Yours, and Filips. Which leads me to read the whole debate as a turf war over Tomcat. I can't believe this project would already be at the melt-down point again, but here we are. It's not your personal playground, nor is it Filip's personal playground. Feel free to contradict my opinion with a pointer or two at some technical input from other project members, of course. But I become concerned when only two people in a project even grok the technical implications of what is in their repository. Some backstory, As a frame of reference, the same thing happened at APR/HTTPD over the entire concept of buckets and brigades. Ryan and Greg were at odds over the implications. As svn was properly managed with commits/vetos/reverts, the projects were at an impasse with no movement to the next generation server. So, all the committers were invited to a f2f powwow for Greg and Ryan to duke it out and thoroughly explain their plan and justification. We treated it as a non-vetoable situation. Neither design was technically invalid, it was a preference. So they had their shootout, and (gasp) even came to agreement on the appropriate solution (to the nods of dozens of attendees). More importantly, the other committers who were 'inflicted' with the design had a chance to thoroughly understand what it was and why it was done that way. Back to Tomcat, it sounds like this is an argument of preference over technical correctness. Perhaps November in Atlanta or Hong Kong would be a good time for you to sit down, fill in all the other interested committers in the exact merits of your preferences, and reach consensus? And maybe feathercast the debate highlights and decision :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571006 - /tomcat/connectors/trunk/ajp/
Mladen Turk wrote: > You could copy it to some sandbox or something, since there is > lots of usable code in there like console mode httpd API client > for testing modules, etc. It's trivial to svn cp -r 571005 https://svn.apache.org/repos/asf/tomcat/connectors/trunk/ajp/ to wherever you like, e.g. a sandbox at tomcat or httpd (or labs), or what have you. Or simply retrieve the pieces you find useful. Two forks of the same code on two trunks is problematic anyways if they don't stay in sync, so I'm sure Mark meant well, even if he didn't notice there were non-module utilities hiding within that tree. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r571006 - /tomcat/connectors/trunk/ajp/
Mladen Turk wrote: > > Right. Deleting entire trees from SVN should at least be > preceded by some note of intention. +1. A heads up is always a good idea ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Corrupted archive file?
I'm sure you ment to send this to the tomcat devs. Dan Schwartz wrote: > The file > > > http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.17/bin/apache-tomcat-5.5.17.exe > > appears to be corrupted. In fact it seems to be about half the size it > should be, as compared with other distributions of Tomcat. > > Could you please check this and let me know? > > I need this version because it is the only one that works with ESRI's ArcIMS > 9.2 (according to their documentation). > > Thanks, > > --Dan Schwartz > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.
Costin Manolache wrote: > > Regarding feedback on patch - I think I expressed my concerns: > - more analysis and understanding of security implications > - if possible to do it at a different (higher) level > - if it can be done in a modular fashion, i.e. keeping the default impl the > way it is, > without this feature, and adding a way to configure a different module with > this or > other features. ( bonus points if the add-on module is a separate release > and very easy > to add ) > > In other words - bloat ( same as Remy's concern I guess) and understanding > if this is the > best possible implementation if the bloat is deemed acceptable. You know the seperate modules, with CGI and SSI moved out and into that, would be a really terrific thing. Where all of these 'non-servlet/non-jsp' features are unwanted, it would be good to lighten the bloat. Props to the idea and anyone who decides to tackle it :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
jean-frederic clere wrote: > > Now for me that just makes another chapter in the "STATUS" file: > "PATCHES being discussed". After a week those patches should be accepted > or reverted. Reverted patches and corresponding discussions should stay > in the "STATUS" until a solution is found. I would keep a passing margin > of +3. A higher bar to add a feature than to release the software? Plainly absurd. Majority is more than sufficient for almost any decision (more + than -) so long as you have at least three affirmative votes. The only exception would be to undoing the decision of the PMC, such as booting a person from the project or 'unreleasing' a release (not that this would make any sense). Those sorts of decisions *need* a supermajority (60 - 75% or even unanimous decision, depending on what rules the committee follows) to undo what the majority had settled on before. That is unless you plan to shutter the project, which is what much of this discussion seems to be about. Set up as many obstacles to changing Tomcat, until Tomcat stagnates entirely, and surrenders to that Glassfish thing? If the project wants to remain relevant, it needs a healthy community, which means attracting instead of repulsing people, and it needs. And it needs to provide an opportunity for people to innovate, not many of the folks here suck on the corporate tit for their camping at Tomcat, and are "happy" to do allot of nothing. Creativity is the energy behind the success of ASF projects. Deny your contributors the opportunity to solve problems creatively, and you might as well hang out the "Closed" sign out on the http://tomcat.apache.org/ page already. All that said, the topic of "no more trunk" came up at the board meeting today. I gave a very brief background and suggested that some of the renewed interest by folks who had been silent throughout the Filip-Remy trunk war is a hopeful sign; with renewed interest the project is very likely to be able to manage itself successfully through these personal and stylistic disagreements; the board is satisfied to see the project try to work out these issues themselves as long as development once again is encouraged. But without reestablishing a method for the committers to innovate, or with continued/renewed territorial behaviors, this issue will likely be noticed again by the board a few months from now as an issue in need of a solution. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
Costin Manolache wrote: > > What I see as a problem is not involving the community in the decision > making about basic features. > > Let's make it clear - adding new features or replacing/improving any > component in tomcat > should stay CTR and should be encouraged and supported. Anyone can create > Valves, Connectors, > Jndi implementations, class loaders or almost anything else that can be > plugged into tomcat > via config file - and a change to add more hook points shouldn't be hard to > get in. > > However - for new features that want to be bundled with tomcat, or for > important or > controversial changes ( defined as 'no consensus' - and one person in > disagreement means > no consensus ) - a majority vote should resolve the question and avoid any > personal or one-on-one fights. > > Consensus is simple to determine - and so is lack of consensus for any > feature. If Remy and Filip > ( and all other committers who care about something ) are in consensus - > done. If there is > doubt - involving and asking more people seems the right solution. ++1 > I think it is a big mistake to use the sandbox as a way to avoid > confrontation - or to waste time > debating subjective things like what is better among 2 not-so-obviously bad > solutions ( which is > what causes most hurt feelings ). Implement any feature you want in a > module, pack it as a jar > with instructions on how to use it, get 3 +1s to release it - and after it > gets some testing and > traction - request it to be part of standard distro or the default > JNDI/Connector/ClassLoader/etc. > Easy, no conflicts needed, good for both tomcat and the feature itself. If > someone else can > implement it in a better way - new vote will get the other one. Well said, all the way around. Thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
Bill Barker wrote: > > Remy was being really nice to the community by not requiring a vetoed patch > to be withdrawn. Personally, I would go with j-f-c's position, and withdraw > a vetoed patch immediately (and have done so on several occations, even when > I got to re-apply it after enough discussion took place on the list). > However, I'll go with whatever the community consensus is on this point. But isn't that statement too broad (to apply to trunk, I agree that in a ready-to-release anytime sort of branch, disputed things should disappear for a while)... It's in the context. If Joe suggests "hey, -1 to the way you presented that, if you fix X you have my support" then it should stick a round a while and let them sort it out. If Joe says "this feature isn't going to be acceptable because Y", well then there isn't much to discuss at that point, and it probably should be backed out right away while the basic idea is debated. Clear A/B options sometimes aren't that effective. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
Remy Maucherat wrote: > William A. Rowe, Jr. wrote: >> jean-frederic clere wrote: >>> Now for me that just makes another chapter in the "STATUS" file: >>> "PATCHES being discussed". After a week those patches should be accepted >>> or reverted. Reverted patches and corresponding discussions should stay >>> in the "STATUS" until a solution is found. I would keep a passing margin >>> of +3. >> >> A higher bar to add a feature than to release the software? Plainly >> absurd. > > Features additions are not mentioned in my proposal. We also use a +3 > vote for releases. Maybe we are misusing words. A passing margin of +3 means three more +1's than -1's; that means if you had 2 -1's you would seek 5 +1's to keep going over the objection. That's what I referred to as absurd. If you are talking about at least 3 +1's, more + than -, then that's being realistic. JFC - did you really mean a margin? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
jean-frederic clere wrote: > William A. Rowe, Jr. wrote: > >> If you are talking about at least 3 +1's, more + than -, then that's being >> realistic. JFC - did you really mean a margin? > > Yep that was what I meant at that time. I'm really sorry I misunderstood you Jean-Frederic, I came from some financial coding where I learned margin/markup/profit aren't the same formula after all :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
Will f/w board since this follows from the 'no more trunk' comment which some officers questioned. Please don't cc per-say, but feel free to f/w a relevant response to [EMAIL PROTECTED] (it's bad form to crosspost a message with both public-and-private destinations). Bill Barker wrote: > "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote in message >> >> All that said, the topic of "no more trunk" came up at the board meeting >> today. I gave a very brief background and suggested that some of the >> renewed interest by folks who had been silent throughout the Filip-Remy >> trunk war is a hopeful sign; with renewed interest the project is very >> likely to be able to manage itself successfully through these personal >> and stylistic disagreements; the board is satisfied to see the project >> try to work out these issues themselves as long as development once again >> is encouraged. > > TC 4.1.x and TC 5.5.x represented major changes to the core API, and > resulted in much more stable Tomcat code. There is no such issue for TC > 6.0.x (just a disagreement on the comet API, which we have already dealt > with, and decided to let software-darwinism take it's course). Thus, there > is really no reason for a "trunk" at this time, at least until the Servlet > 3.0 spec comes out. If somebody wanted to make a [PROPOSAL] for major > changes to the core TC 6.0.x API, then I can see setting up a "trunk" again. > But there is no such animal lurking at this time. No doubt, these were significant departures from their previous code. But, are you suggesting that there is no need for trunk until there is an idea you happen to champion? Present you with an idea that you like and half the committee might decide to permit new development again? This is certainly turning the idea of "show me the code" on it's head. To give an example oft cited on this list, httpd maintains a trunk. It might be released some day as-is, it might never be released. But it's a staging ground to prove up an idea before injecting that idea into the shipping stable version. It appears there is no such wilderness at Tomcat. Sandboxes don't cut it. It's very clear sandboxes are one-man-shows at Tomcat. As such, they go against the concept of collaborative development and don't belong at the foundation. If I misunderstand, and sandboxes are shared spaces for proving concept-not-the-programmer, and everyone is welcome at each sandbox to improve the proof of concept themselves, then my objection is unfounded. It seems the list wants very tight control on the stable 6.0 branch, so your observation that trunk is irrelevant hasn't jived since I first read this post (and I considered it's implications for a good 12 hrs). It also brings up a real question of why was it so important to 'kill trunk' if trunk, admittedly, is not relevant? >> But without reestablishing a method for the committers to innovate, or >> with continued/renewed territorial behaviors, this issue will likely >> be noticed again by the board a few months from now as an issue in need >> of a solution. > > I maintain that there is currently a very small barrier to "innovating" on > Tomcat. We had one innovation that was shown to have a big whopping > security hole in it, so it was withdrawn until a better patch can be made > (i.e. the system worked). There were people (myself included) that would > have preferred a modular patch (e.g. with httpd, I can configure it so that > mod_alias isn't included with a few small edits, but the patch in question > didn't allow for that, which was the complaints). You are talking about one patch. Has Tomcat become so pathetic that there's only one example of innovation in the past /x/ months to hold up as the one true example? Let's hope the rule systems that Tomcat debates and settles on reflect the diversity of contributions, as opposed to a small handful of exceptions. The fact that the rule systems themselves are being debated points me to really wonder if there is any code debate here at all, or nothing more than a clash of personalities which "changing the rules" is the simplest solution to getting one's way? In any case, the list continues to ponder what the meaning of the branches, sandboxes etc all are, and I'll step out of this conversation (baring any truly insane proposals) while the TC core community comes to terms with how Tomcat can still prosper, and lose the perception of being a fiefdom of the chosen few. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Review model take 2
Jim Jagielski wrote: > > So how about this... this is something that has been done, and > is being done, in just about every ASF project. Why don't > we vote on this and give it a time-table at which point we > review how it's worked out over the last 3 months or so > and fine-tune if and as needed? > > Once we agree this is a workable implementation, we can > determine numbering aspects and initial code repo loads. There's a confusing aspect; what if the new proposed process/policies get dropping to a /dev/howitworks.html sort of document, and that entire document is voted on? It sounds (for the most part) that concensus is emerging anyways, so it shouldn't be hard to start writing it down, and limiting discussion to a couple of sentences of that doc that people want to discuss. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)
jean-frederic clere wrote: > Mark Thomas wrote: >> Jim Jagielski wrote: >> >> - There is only one dev branch. I am -1 for creating separate dev >> branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much >> overhead for branches that are in maintenance mode where 99% of the >> patches will be ported from 6.x > > Apache httpd works that way. In case a patch can't fit in mail use > people.apache.org to store the patch to review. What we typically do at httpd; 1. Patch trunk (CTR). 2. Prepare patches to desired release branches to which the trunk commit diff wouldn't apply cleanly, with a minimum of fuzz. 3. Propose a backport to current release branch(es) (e.g. to version n.n, n.n-1, n.n-2 etc). This happens in each released branches' STATUS file. 4. Wait to collect 3+1's. Compensate for any objections in the meantime. Sometimes, withdraw the backport proposal and jump back to step 1. above and proceed with a fresh patch. How far back that goes depends on how broad the bug was, if it represents a fix or new feature, how ABI neutral the change is, etc. There is one especially nice side effect. Rather than waiting for the release of the next version to review; the trunk changes which are proposed for backport get extra scrutiny while they are fresh in the contributors' mind. (How many of us have had to reconstruct why we choose to do something in a specific manner, months or years later, before +1'ing a suggested change to the code we wrote?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Export Notification Requirements
Hey folks, as you provide the bindings to the JSSE, even though you don't ship the JSSE .jars - we still need Tomcat in compliance with the federal export notification policies. I know you did some work on this in the past, but please see http://www.apache.org/dev/crypto.html for ASF policies, requirements, guidelines and help on getting things in sync, and note that presently Tomcat/mod_jk are missing below; http://www.apache.org/licenses/exports/#matrix I'm about to start an audit across the foundation, I'd appreciate that this was already in sync at Tomcat :) Note that ECCN numbers, etc are very frequently asked questions about tomcat etc in all the wrong forums, and it would be good to point them at the one correct place. Many thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
Mladen Turk wrote: > William A. Rowe, Jr. wrote: >> Hey folks, >> >> as you provide the bindings to the JSSE, even though you don't >> ship the JSSE .jars - we still need Tomcat in compliance with the >> federal export notification policies. I know you did some work on >> this in the past, but please see >> >> http://www.apache.org/dev/crypto.html > > I suppose we would need the same for Native connectors > that uses OpenSSL. Up till now we are using Irelands > Heanet to host the binaries. > > Please advice what's needed to be done to get the ECCN numbers. Read that page, please raise any questions that you have after you've covered it. You'll be glad to know once these notices are sent, you'll never need to check in again about openssl for mod_jk, the native jni connector or Tomcat+JSSE ever again. Think of the summary page http://www.apache.org/licenses/exports/ as documentation that all the steps are done for a specific software component, never to be repeated (whew!) The document is obviously evolving (only a half-dozen committers have followed the process yet, so we want to work out any wrinkles). Please point out problems :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
Yoav Shapira wrote: > Hey, > > On 9/26/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >>> Please advice what's needed to be done to get the ECCN numbers. >> Read that page, please raise any questions that you have after you've >> covered it. You'll be glad to know once these notices are sent, you'll >> never need to check in again about openssl for mod_jk, the native jni >> connector or Tomcat+JSSE ever again. Think of the summary page >> >> http://www.apache.org/licenses/exports/ > > So we should NOT add Tomcat to the exports matrix UNTIL the > notifications are sent to the government, right? Correct. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
Yoav Shapira wrote: > Hey, > > On 9/26/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >>> Please advice what's needed to be done to get the ECCN numbers. >> Read that page, please raise any questions that you have after you've >> covered it. You'll be glad to know once these notices are sent, you'll >> never need to check in again about openssl for mod_jk, the native jni >> connector or Tomcat+JSSE ever again. Think of the summary page >> >> http://www.apache.org/licenses/exports/ > > So we should NOT add Tomcat to the exports matrix UNTIL the > notifications are sent to the government, right? I hit send too fast. You do them concurrently. Add the notice to exports, and send out the notification email. Because the notice includes; NOTIFICATION: http://www.apache.org/licenses/exports/ it's sort of a closed loop problem. Update the info, allow the usual one hour after updating from minotaur to sync, and then shoot out the notice referencing the list of notices sent :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
Mladen Turk wrote: > William A. Rowe, Jr. wrote: >> >> it's sort of a closed loop problem. Update the info, allow the usual >> one hour after updating from minotaur to sync, and then shoot out the >> notice referencing the list of notices sent :) >> > > Can we get an example email that needs to be send and an email > address? The page you referred looks pretty confusing with lots > of links ;) > Think wee need to have both JSSE and OpenSSL referenced. Please review the section "Notify the U.S. Government of the Release" and let me know of any suggested changes, or ask about the confusing paragraph so I can rewrite it. These sorts of things never get fixed if everyone is walked through it one by one :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Export Notification Requirements
Mladen Turk wrote: > William A. Rowe, Jr. wrote: >> Mladen Turk wrote: >>> William A. Rowe, Jr. wrote: >>>> it's sort of a closed loop problem. Update the info, allow the usual >>>> one hour after updating from minotaur to sync, and then shoot out the >>>> notice referencing the list of notices sent :) >>>> >>> Can we get an example email that needs to be send and an email >>> address? The page you referred looks pretty confusing with lots >>> of links ;) >>> Think wee need to have both JSSE and OpenSSL referenced. >> >> Please review the section "Notify the U.S. Government of the Release" >> and let me know of any suggested changes, or ask about the confusing >> paragraph so I can rewrite it. > > Argh. I was looking at the wrong location. > I'll try running the tool. > > However, not sure what to do with JSSE and how to reference those. > > Is http://java.sun.com/javase/technologies/security/ > enough? They tend to change the uri often ;) It must be a link from which bis can get to the source code of the open source crypto provider. They provide a link on that page; "Archived JAAS, JCE, and JSSE Optional packages" - however following that link reveals version 1.0.3 of the JSSE alone, so this doesn't satisfy the requirements since there is no way to get to the specific sources. But *wait* - we don't ship the JSSE, we incorporate it but the user must obtain it themselves. The crypto code *we* ship is strictly at openssl or in our own svn repositories. So - incorporate by reference that it leverages JSSE (that link is fine) but since we don't ship it, we don't point them to that 'source code'. Only our own. c.f. derby and geronimo. So follow the geronimo example and the httpd example of openssl notice and I think that covers Tomcat. Now in the case of a few others where they've leveraged BouncyCastle (an IP minefield in it's own right), they have actually shipped those .jar's as I understand it. So their form of notice was correct. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to organise svn
Mark Thomas wrote: > In light of the recent vote, we need to make some changes to svn. In > short we need to add: > 6.2.x ? Where is 6.1.0, or in other words, why the skip? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to organise svn
Mark Thomas wrote: > William A. Rowe, Jr. wrote: >> Mark Thomas wrote: >>> In light of the recent vote, we need to make some changes to svn. In >>> short we need to add: >>> 6.2.x >> ? Where is 6.1.0, or in other words, why the skip? > > The idea was to use even numbers for stable releases, odd numbers for > alpha/beta. I would expect to see releases from trunk (if any) to be > 6.3.x. Actually, the way it typically works at httpd-space (which your new policy is based on) is that you would next create 6.1.0 as a forever development branch. Committers apply each patch they believe belongs to the 6.2.0 release, and things are removed and readded as various votes and discussions proceed. When the crowd is satisfied that tomcat 6.1.0 represents everything that is part of the next general release (by a vote, obviously), it's branched to 6.2.0 (ending the life of the 6.1.0 branch) and that API becomes the reference for the entire lifespan of 6.2.0. E.g. API changes all happen in branches/6.1.0 and never happen in branches/6.2.0 Of course tomcat can choose it's own way, but it seemed like you were skipping a step if you aimed to emulate the even's-odd's way of doing things. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to organise svn
Mark Thomas wrote: > William A. Rowe, Jr. wrote: >> Actually, the way it typically works at httpd-space (which your new >> policy is based on) is that you would next create 6.1.0 as a forever >> development branch. Committers apply each patch they believe belongs >> to the 6.2.0 release, and things are removed and readded as various >> votes and discussions proceed. > > OK. I think I have it now. Does the the following make more sense? > > svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > https://svn.apache.org/repos/asf/tomcat/tc6.1.x/trunk > > svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk > https://svn.apache.org/repos/asf/tomcat/trunk > > and then > - Make all changes in trunk (CTR) > - Port those API changes we want in 6.2.x from trunk to 6.1.x (RTC) > - A beta release of 6.1.x > - Once we are happy with 6.1.x, freeze it, create 6.2.x and do a > stable release > - Continue to port non-API modifying changes from trunk to 6.2.x as RTC > - At some point in the future, trunk is branched to form 6.3.x which > is used as the basis for 6.4.x or 7.0.x Yup, my only kibitz would be that you /might/ want to consider deferring the creation of trunk for a week to copy it from 6.1.x. in order to let people catch up with the backlog of patches, without having to apply them in /both/ places at once :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r589039 - /tomcat/site/tags/TOMCAT_5_0_27/
[EMAIL PROTECTED] wrote: Author: markt Date: Fri Oct 26 19:02:00 2007 New Revision: 589039 URL: http://svn.apache.org/viewvc?rev=589039&view=rev Log: Move site tag to archive Can we please beg that next time you do this atomically? If you ask nicely, someone in infra can momentarilly remove the restrictions on checking out entire trees, in order to reorganize them in one swoop. svn mv works locally as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to organise svn - Take 3
jean-frederic clere wrote: Mark Thomas wrote: Mark Thomas wrote: svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15 https://svn.apache.org/repos/asf/tomcat/tc6.1.0/trunk https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_15 https://svn.apache.org/repos/asf/tomcat/trunk Changes to .../trunk with be CTR Changes to .../6.1.x/trunk will be RTC As per the previously published plan, I will create tomcat/tc6.1.x/trunk and tomcat/trunk from the 6.0.15 tag. I plan to do this sometime on Friday afternoon GMT. Why Friday? Shouldn't we wait until 6.0.15 (or 6.0.15 + n) is voted stable? Contrawise, why wait, and why a tag? Usually most efforts (in order to preserve history) branch from trunk or branches, whereas tags/* reflect an endpoint (end of history). Simply branch from 6.0.x unless there are dirty secrets buried in there :) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to organise svn - Take 3
Mark Thomas wrote: William A. Rowe, Jr. wrote: Contrawise, why wait, and why a tag? Usually most efforts (in order to preserve history) branch from trunk or branches, whereas tags/* reflect an endpoint (end of history). Simply branch from 6.0.x unless there are dirty secrets buried in there :) Because 6.0.15 (assuming it is stable) is intended to be the end of the 6.0.x branch. It is expected that the tag 6.0.15 == 6.0.x trunk. Just to clear things up, I've made my share of svn mistakes, and using the tags/* result for anything other than and endpoint is one that I lived to regret (my doing, so my dogfood.) Assuming cp /branches/6.0.x /tags/6.0.15 happened at r678123, it's vastly still preferable to cp -r678123 /branches/6.0.x /trunk/ - that was my point, not what code y'all are agreeing to use, nor how many trunks and branches y'all want to struggle with :) Consider all the recent rearrangement of tags/ you made, this isn't something you want to have to struggle to unwind four years from now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r598587 - /tomcat/tc6.0.x/trunk/STATUS.txt
Guys - this isn't how you use voting ... if there is an incorrectly branded file in svn, it doesn't matter which branch it is on. It's commit then review; review r598412 already, and either justify it or revert the original change. It's not subject to a backport debate. Citation of whatever justification exists to remove a license/notice is absolutely mandatory in the svn commit history. [EMAIL PROTECTED] wrote: Author: billbarker Date: Tue Nov 27 02:54:45 2007 New Revision: 598587 URL: http://svn.apache.org/viewvc?rev=598587&view=rev Log: Adding my objection Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=598587&r1=598586&r2=598587&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Tue Nov 27 02:54:45 2007 @@ -50,7 +50,8 @@ * Fix another license issue http://svn.apache.org/viewvc?rev=598412&view=rev +1: markt, fhanik, pero - -1: + -1: billbarker It is clear that simply making a copy doesn't release you from the original license. + It is clear that Sun ownes the license on these files, and that will never change. * Add get/set methods for properties in the Tcp Failure detector http://people.apache.org/~fhanik/patches/tcpfaildet-getset.patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.1 alpha
Guys - something got broken again in your release process against ASF policy... I don't see three +1's for any of the recent postings to your downloads page. Please remedy this - even if it's a matter of 3 +1's for 'alpha'? Remy Maucherat wrote: > Hi, > > Tomcat 6.0.1 alpha is now available for testing: > http://tomcat.apache.org/download-60.cgi > > A stability vote will be done next week. > > Rémy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > . > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.1 alpha
Mladen Turk wrote: > William A. Rowe, Jr. wrote: >> Guys - something got broken again in your release process against ASF >> policy... >> I don't see three +1's for any of the recent postings to your >> downloads page. >> > > Nothing got broken. Actually it did, because I've followed the list for some 3 years although I don't have the cycles to be active (too many fingers in other dikes within and outside the ASF). I brought this up almost a year ago now and watched as the list started voting on all it's distribution packages (e.g. 'release' in whichever form, alpha beta or general availability). Things were following the ASF procedure :) > Tomcat is probably one of the latest remaining projects > where the developers and PMC still works on the > original ASF presumptions (CTR). CTR/RTC has nothing to do with voting on the final distribution package. It has to do with how the source code repository is handled, and I think (from following the discussion on dev@) that the current policies suit the project very well. > The vote itself is a minor thing compared with all > the work and communication that happened a long time before > the email stating: "I'll make the release". No, this is what the ASF is saying - yes all those micro decisions are great so that everyone is on the same page when you get to a release, but... the only vote that binds the board and the foundation to the package is your project's release vote after the distribution package is rolled, and... that's what makes this the ASF's release, and not Remy's personal liability. Believe me, we aren't nitpicking, I don't want Remy or any other committer to be hanging out there with liabilities for something distributed by any given project. > Anyone interested can monitor the developers list and > react promptly if he thinks there is a major outage. Trust, I do :) Things are working great, and other than this issue with 6.0.1/6.0.2 I haven't seen any issues. And belated congratulations on the new 6.0 baby! > One size doesn't fit all, and never will. On this, policy for handling a distribution package, there is only one size that ensures your collective work becomes the ASF's headache, should any 'bad thing' happen in the future with respect to intellectual property or liability. I'm just looking out for you guys, especially everyone with the gumption to handle the RM's job ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6.0.1 alpha
Yoav Shapira wrote: > > What did we miss? Was it a formal announcement to [EMAIL PROTECTED] > about 6.0.1 stability? Was it formally marking the 6.0.1 time/date > poll as a voting thread and posting its results? What you are missing is pretty straightforward. It's that you can't have a release vote of a package that isn't in your hands. Therefore any vote on the "future state" of the repository isn't a "release vote", but it's a decision to cut a release candidate. And in all this the committers are working really well and rowing in the same direction :) Once you have a tarball/jar in-hand, you have something you can vote to release (or not), and then post it on the general downloads page. Until there are 3 votes for somepackage-1.2.3.tar.gz, it still isn't an ASF release and doesn't, yet, belong on the downloads page. /dev/dist/ or somewhere the RM wants to put it for signoff works. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 6.0.3 alpha release
I don't mean to be a pest, but want to check that everyone is clear that this poll isn't a release vote; but it's a vote to start the process. The results of what Remy rolls into a tarball - is what gets voted on after its created. This is an example of 'voting on vapor' since that specific tarball doesn't exist yet, there's no 'release' to approve. I'm only asking that all are clear because I saw [VOTE] and "release" in a subject with nothing to vote on (yet :-) And this sounda like a great idea, Remy, and 6 looks like it's cooking right along. Thanks for offering to RM! Bill Remy Maucherat wrote: > Hi, > > In line with what Filip wanted to have, I propose releasing a new 6.0.3 > test build, which will incorporate the fixes that have been made since > 6.0.2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.6 as alpha
Don't tell me the .exe is in SVN :) PROVIDED that the tagged sources are identical it should not be an issue. I actually split httpd/win32-msi/ from the httpd/trunk for this very reason, easier that the installer is a post-release vote artifact. As Roy's pointed out recently elsewhere, we trust binary packagers to build the real sources we tagged and tarred. There's technically no real way to verify this, so 'artifacts' of packaging shouldn't become a showstopper. Q - is the source identical, and if so, retar and move on. If not, then reroll. Remy Maucherat wrote: > Mladen Turk wrote: >> Remy Maucherat wrote: >>> Hi, >>> >>> The vote is to release Apache Tomcat 6.0.6 as alpha. >>> The build is located here: >>> http://people.apache.org/~remm/tomcat-6/v6.0.6/ >>> >>> Votes ? >>> >> >> The .exe installer looks really weired due to my fault >> because I forget to rotate the left side image :( >> Can you just rebuild the exe without retaging? > > The build is supposed to correspond to the tag, so it's not possible to > fix it without a new tag. > > Rémy > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > . > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r493203 - in /tomcat/connectors/trunk: jk/tools/lineends.pl jni/native/build/lineends.pl
Hello Jakarta folks, the apr folks would appreciate if improvements were pushed back to repos/asf/apr/apr/build/win32 - even to the extent that those aren't strictly necessary for apr+httpd. Yours, Bill [EMAIL PROTECTED] wrote: > Author: rjung > Date: Fri Jan 5 13:57:03 2007 > New Revision: 493203 > > URL: http://svn.apache.org/viewvc?view=rev&rev=493203 > Log: > Carry over Mladen's lineends.pl improvements from jni to jk > (and kill one trailing space). > > Modified: > tomcat/connectors/trunk/jk/tools/lineends.pl > tomcat/connectors/trunk/jni/native/build/lineends.pl > > Modified: tomcat/connectors/trunk/jk/tools/lineends.pl > URL: > http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/tools/lineends.pl?view=diff&rev=493203&r1=493202&r2=493203 > == > --- tomcat/connectors/trunk/jk/tools/lineends.pl (original) > +++ tomcat/connectors/trunk/jk/tools/lineends.pl Fri Jan 5 13:57:03 2007 > @@ -23,7 +23,7 @@ > $ignore .= "gif-jpg-jpeg-png-ico-bmp-"; > > # Archive formats > -$ignore .= "tar-gz-z-zip-jar-war-"; > +$ignore .= "tar-gz-z-zip-jar-war-bz2-tgz-"; > > # Many document formats > $ignore .= "eps-psd-pdf-ai-"; > @@ -32,9 +32,9 @@ > $ignore .= "ucs2-ucs4-"; > > # Some binary objects > -$ignore .= "class-so-dll-exe-obj-"; > +$ignore .= "class-so-dll-exe-obj-a-o-lo-slo-sl-dylib-"; > > -# Some build env files in NW/Win32 > +# Some build env files > $ignore .= "mcp-xdc-ncb-opt-pdb-ilk-sbr-"; > > $preservedate = 1; > > Modified: tomcat/connectors/trunk/jni/native/build/lineends.pl > URL: > http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/build/lineends.pl?view=diff&rev=493203&r1=493202&r2=493203 > == > --- tomcat/connectors/trunk/jni/native/build/lineends.pl (original) > +++ tomcat/connectors/trunk/jni/native/build/lineends.pl Fri Jan 5 13:57:03 > 2007 > @@ -34,7 +34,7 @@ > # Some binary objects > $ignore .= "class-so-dll-exe-obj-a-o-lo-slo-sl-dylib-"; > > -# Some build env files > +# Some build env files > $ignore .= "mcp-xdc-ncb-opt-pdb-ilk-sbr-"; > > $preservedate = 1; > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r511252 - in /tomcat/connectors/trunk/jk/native/iis: Makefile.amd64 Makefile.vc isapi.dsp jk_isapi_plugin.c
GOOD GOD you can't be serious :) strncat strncpy exist for a reason, C's been safe for decades if only the correct functions are chosen :) It would be a -1, but I don't count myself amongst the voters here. [EMAIL PROTECTED] wrote: > Author: mturk > Date: Sat Feb 24 03:45:39 2007 > New Revision: 511252 > > URL: http://svn.apache.org/viewvc?view=rev&rev=511252 > Log: > Use Microsoft strsafe library for string operations. > > Modified: > tomcat/connectors/trunk/jk/native/iis/Makefile.amd64 > tomcat/connectors/trunk/jk/native/iis/Makefile.vc > tomcat/connectors/trunk/jk/native/iis/isapi.dsp > tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c > > Modified: tomcat/connectors/trunk/jk/native/iis/Makefile.amd64 > URL: > http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/Makefile.amd64?view=diff&rev=511252&r1=511251&r2=511252 > == > --- tomcat/connectors/trunk/jk/native/iis/Makefile.amd64 (original) > +++ tomcat/connectors/trunk/jk/native/iis/Makefile.amd64 Sat Feb 24 03:45:39 > 2007 > @@ -59,7 +59,7 @@ > BSC32_SBRS= \ > > LINK32=link.exe > -LINK32_FLAGS=kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > bufferoverflowu.lib /nologo /dll /incremental:no > /pdb:"$(OUTDIR)\isapi_redirect.pdb" /debug /machine:AMD64 /def:".\isapi.def" > /out:"$(OUTDIR)\isapi_redirect.dll" /implib:"$(OUTDIR)\isapi_redirect.lib" > +LINK32_FLAGS=kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > bufferoverflowu.lib strsafe.lib /nologo /dll /incremental:no > /pdb:"$(OUTDIR)\isapi_redirect.pdb" /debug /machine:AMD64 /def:".\isapi.def" > /out:"$(OUTDIR)\isapi_redirect.dll" /implib:"$(OUTDIR)\isapi_redirect.lib" > DEF_FILE= \ > ".\isapi.def" > LINK32_OBJS= \ > > Modified: tomcat/connectors/trunk/jk/native/iis/Makefile.vc > URL: > http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/Makefile.vc?view=diff&rev=511252&r1=511251&r2=511252 > == > --- tomcat/connectors/trunk/jk/native/iis/Makefile.vc (original) > +++ tomcat/connectors/trunk/jk/native/iis/Makefile.vc Sat Feb 24 03:45:39 2007 > @@ -74,7 +74,7 @@ > BSC32_SBRS= \ > > LINK32=link.exe > -LINK32_FLAGS=kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > /nologo /base:"0x6A6B" /dll /incremental:no > /pdb:"$(OUTDIR)\isapi_redirect.pdb" /debug /machine:I386 /def:".\isapi.def" > /out:"$(OUTDIR)\isapi_redirect.dll" /implib:"$(OUTDIR)\isapi_redirect.lib" > +LINK32_FLAGS=kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > strsafe.lib /nologo /base:"0x6A6B" /dll /incremental:no > /pdb:"$(OUTDIR)\isapi_redirect.pdb" /debug /machine:I386 /def:".\isapi.def" > /out:"$(OUTDIR)\isapi_redirect.dll" /implib:"$(OUTDIR)\isapi_redirect.lib" > DEF_FILE= \ > ".\isapi.def" > LINK32_OBJS= \ > > Modified: tomcat/connectors/trunk/jk/native/iis/isapi.dsp > URL: > http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/isapi.dsp?view=diff&rev=511252&r1=511251&r2=511252 > == > --- tomcat/connectors/trunk/jk/native/iis/isapi.dsp (original) > +++ tomcat/connectors/trunk/jk/native/iis/isapi.dsp Sat Feb 24 03:45:39 2007 > @@ -53,7 +53,7 @@ > # ADD BSC32 /nologo > LINK32=link.exe > # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib > comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib > odbc32.lib odbccp32.lib /nologo /dll /machine:I386 > -# ADD LINK32 kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > /nologo /base:"0x6A6B" /dll /debug /machine:I386 > /out:"Release\isapi_redirect.dll" > +# ADD LINK32 kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > strsafe.lib /nologo /base:"0x6A6B" /dll /debug /machine:I386 > /out:"Release\isapi_redirect.dll" > > !ELSEIF "$(CFG)" == "isapi - Win32 Debug" > > @@ -79,7 +79,7 @@ > # ADD BSC32 /nologo > LINK32=link.exe > # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib > comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib > odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept > -# ADD LINK32 kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > /nologo /base:"0x6A6B" /dll /incremental:no /debug /machine:I386 > /out:"Debug\isapi_redirect.dll" > +# ADD LINK32 kernel32.lib user32.lib advapi32.lib ws2_32.lib mswsock.lib > strsafe.lib /nologo /base:"0x6A6B" /dll /incremental:no /debug > /machine:I386 /out:"Debug\isapi_redirect.dll" > > !ENDIF > > > Modified: tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c > URL: > http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c?view=diff&rev=511252&r1=511251&r2=511252 > == > --- tomcat/c
Re: Let's get 5.5.21 out the door...
Mark Thomas wrote: > > Given that a -1 vote is not valid for a release vote, as soon as we > have 3 +1's from the PMC we can release. Small misunderstanding to clear up here; -1 is a legitimate vote There must be 3 more +1's than -1's (and at least 3 +1's as you say) A -1 is NOT a veto for releasing a tarball, which is probably what you ment to say, or where your confusion came from. Yours, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's get 5.5.21 out the door...
William A. Rowe, Jr. wrote: > > Small misunderstanding to clear up here; Mea culpa - glad this was clarified earlier, gotta catch up on archives from most-recent first I see :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r511252 - in /tomcat/connectors/trunk/jk/native/iis: Makefile.amd64 Makefile.vc isapi.dsp jk_isapi_plugin.c
Mladen Turk wrote: > William A. Rowe, Jr. wrote: >> GOOD GOD you can't be serious :) >> >> strncat strncpy exist for a reason, C's been safe for decades if >> only the correct functions are chosen :) >> > > Didn't say it's wrong or something like that, > but beside constantly fighting with hacking > and suppressing newest MS compilers security presumptions, > I see nothing wrong of using provided SDK functions > for MS only related code. My 2c - since MS doesn't want to play in C POSIX land and work with the appropriate spec bodies, but would rather invent their unique mindset (again) and work against the communities, I'm rather partial to ignoring their 'security overtures'. Fortunately I've seen some blog feedback to the effect that 'we made a mistake with this draconian change' or words to that effect, so hopefully VC 8.1 might see some course correction. FWIW there is some community source licensing and portable implementation around this MS Strings Lib, but that doesn't really change my opinion. The reason against this commit is that you break older ms clibs (which is precisely what they would like you to do.) Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposed new security pages
Great stuff Mark!!! Thanks :) Bill Mark Thomas wrote: > All, > > I have started to put together some additional security pages based on > httpd. I have only added text for a couple vulnerabilities but the > plan is to include all those in the CVE list plus any I can find in > the archives. > > The draft is currently on people.a.o at > http://people.apache.org/~markt/tomcat-security/security.html > > My plan is to commit as is and then work through the CVE list. Once I > have all the CVE entries I'll remove the work in progress comment at > the top of the first page and then start searching the archives and > other public vulnerability databases. > > Any comments before I commit these changes to the live site? > > Mark > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quality check mod_jk 1.2.21-dev
Will, this doesn't belong on Gentoo - it's a dev/quality check, no different than any other snapshot. (If you ship snaps on Gentoo, be our guest.) William L. Thomson Jr. wrote: > Packaged and available in a few hours for sync and emerge on Gentoo. > > Np with compiling or etc. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quality check mod_jk 1.2.21-dev
William L. Thomson Jr. wrote: > > These types of bumps are minor, and I like to test myself in my own > envs. So can't hurt to make it available for others to test etc. +1 on testing that the packages all build in advance of any release, just please don't represent these as releases. Until you see those 3 +1's and an announce, they are not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Covering official Tomcat 6 release
Yoav Shapira wrote: > Hi, > FYI, I just had an IM conversation with Rick. He's nice. He wants > someone to maybe do a screencast about Tomcat 6. I told him I > personally wasn't interested and don't have the spare bandwidth, but > that other Tomcat committers might be interested. If someone wants to > do it, just keep us in the loop please. I also told him to ask > questions, if any, on [EMAIL PROTECTED] C'est tout, Related venue - I'm certain Rich and David would love to podcast one of you at http://www.feathercast.org/ - please consider setting one up! Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JK2 confusion
Since JK2 is now off the map, does it make sense to update http://www.apache.org/dist/tomcat/tomcat-connectors/ and simply remove jk2? The user could still dig these up if they wanted over at http://archive.apache.org/dist/tomcat/tomcat-connectors/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK2 confusion
Mladen Turk wrote: > Not even that. We are talking for more then a year for > a next generation binary http(s) protocol. > > Almost everyone agreed that we need > at least few things: > 1. Encryption > 2. Variable sized messages > 3. Client connection close notification. Talk about a hijaak :) I'm going to argue; 'no', but let me offer my rational... 1. These features are available through the HTTP connector which is easier to troubleshoot (sniff) and already standardized. 2. The HTTP connector was somewhat neglected; to ensure that it is completely conformant needs more eyes, not fewer. More effort at AJP 1.x is less effort towards HTTP/1.1 conformance. (This is not only a developer issue, but speaks to how well exercised the HTTP connector is with many users choosing AJP and not seeing or reporting specific quirks.) 3. We would honestly win more bandwidth from fully supporting the content encoding deflate from tomcat to the proxy server than from the few bytes saved with AJP. And SSL Encryption + deflate provided by TLS today will already give you this win, so binary protocol is really not that significant (OpenSSL 0.9.8 supports it, don't ask me if JSSE does.) 4. Waka. Why reinvent a wheel in motion? With the new focus at the httpd Amsterdam code to break apart http from apache, we are adding wiggle room for some to come behind and code to Roy's binary http protocol plan. The difference? Waka when done will be an accepted spec, while I don't see that ever happening to AJP. :) That said, those are technical arguments against but I have no vote here - I'll leave it to you all to weight these against your itches and designs. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Debugging Apache/mod_jk (worker) fault on AIX
Any reason you didn't choose xlc_r? I'd suggest you retest with that
compile.
Rainer Jung wrote:
> Hi Eric,
>
> we won't close the issue immediately with "we don't support cc_r". This
> will be our last option :)
>
> Rainer
>
> Eric Wertman wrote:
>> Hi Rainer... I'll have to re-compile to get this info for you. I'll
>> make sure I can re-produce it and submit the details in a bugzilla.
>>
>> I think the first thing you'll notice, though, is that I'm using the
>> IBM cc_r compiler and not gcc.
>>
>>
>> Rainer Jung wrote:
>>> Eric reported very strange mod_jk behaviour using it with Apache
>>> 2.0/worker on AIX.
>>>
>>> I start a new mail thread, because until now all the discussion is part
>>> of non-specific threads.
>>>
>>> Eric: could you please open a bugzilla (issues.apache.org), so that we
>>> can track the issue?
>>>
>>> Also: When you compile mod_jk for your apache with worker MPM, does the
>>> make output contain the flag -D_REENTRANT?
>>>
>>> If no, how does the begginning of the file HOME_OF_APACHE/bin/apr-config
>>> look like? Example:
>>>
>>> APR_MAJOR_VERSION="0"
>>> APR_DOTTED_VERSION="0.9.12"
>>>
>>> prefix="/var/tmp/install/apache2p"
>>> exec_prefix="/var/tmp/install/apache2p"
>>> bindir="${prefix}/bin"
>>> libdir="${prefix}/lib"
>>> datadir="/var/tmp/install/apache2p"
>>> installbuilddir="${prefix}/build"
>>> includedir="/var/tmp/install/apache2p/include"
>>>
>>> CC="gcc "
>>> CPP="gcc -E"
>>> SHELL="/bin/sh"
>>> CPPFLAGS="-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE"
>>> CFLAGS="-O2 -g -Wall -pthread"
>>> LDFLAGS=""
>>> LIBS="-lrt -lm -lcrypt -lnsl -lpthread -ldl"
>>> EXTRA_INCLUDES=""
>>> SHLIBPATH_VAR="LD_LIBRARY_PATH"
>>> APR_SOURCE_DIR="/non/existing/build/path/apache2/srclib/apr"
>>> APR_BUILD_DIR="/non/existing/build/path/apache2/srclib/apr"
>>> APR_SO_EXT="lo"
>>> APR_LIB_TARGET="-rpath \$(libdir) \$\$objects"
>>> APR_LIBNAME="apr-${APR_MAJOR_VERSION}"
>>>
>>> Regards,
>>>
>>> Rainer
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 6 Scales
Remy Maucherat wrote: > > I don't really believe in this sort of solution (especially since APR > uses deferred accepts automagically). To clarify, httpd 2.2 automagically adds default socket filters (data, or http headers, where the platform supports them). AFAIK APR does not by default. If it did, the other 'half' of the protocols would be borked. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should we release mod_jk 1.2.21.1 or 1.2.22?
Rainer Jung wrote: > > Somehow 1.2.21.1 would express the right thing, but our versioning > header files don't (yet) have the structure to easily make a 1.2.21.1. Version numbers are cheap - roll 1.2.22. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Vendor Notification VU#239041 - apache-tomcat]
Mladen Turk wrote: > Remy Maucherat wrote: >> >> Tomcat permits both '\' and '%5C' as path delimiters. When Tomcat is >> used behind a proxy (including, but not limited to, Apache HTTP server >> with mod_proxy and mod_jk) configured to only proxy some contexts, a >> HTTP request containing strings like "/\../" may allow attackers to >> work around the context restriction of the proxy, and access the >> non-proxied contexts. You neglected to mention %2F - a significant identical issue. > But this is unlikely to happen unless you explicitly add > AllowEncodedSlashes and unless you physically put your webapps > inside ServerRoot so they can be directly access by web server > regardless of proxy used. Nope - you have one misunderstanding of AllowEncodedSlashes! On Windows, this will not happen (if the path is physical and not virtual), you are correct. On all platforms, %2F is caught and rejected by default, as well. On Unix, %5C is an opaque filename byte. E.g. /My\Cool\App/ is a one level deep filename "My\Cool\App" (escaped with shell syntax as My\\Cool\\App). On both, '\' itself unescaped is meaningless and disallowed. Just to be clear, %2F is also an opaque filename byte, that can't be represented on Unix or Windows (because it is their path seperator). But on Mac OS 9 for example, there would be nothing improper about /my%2Fdocs mapping to the file my/docs in WebServer:Documents. It most definitely NEVER means path-delimiter. So Unix couldn't care less that you are passing %5C's al la '\'s, they are opaque character bytes, per RFC 2396 (which for purposes of HTTP/1.1 is not superseded by RFC 3986, although it would be in the next draft of the HTTP spec, probably.) I've started a thread on httpd suggesting to disallow %5C the same on Unix as on Windows, or to treat it as '/' path delimiter on either, for the sake of consistency and the fact that half the world is treating %5C as a delimiter against the RFC guidelines. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Make 6.x trunk the "current" svn:externals link?
Mark Thomas wrote: > Yoav Shapira wrote: >> On 3/25/07, Mark Thomas <[EMAIL PROTECTED]> wrote: >>> Since tc6 is a single component, there is no need to provide such a >>> directory. >> I wonder if we should still have current/tc6 for consistency. > > -0. I can see the benefit of consistency but I don't like the idea > because: > - apart from offering consistency, it serves no useful purpose > - if someone tags the external by mistake the tag will be useless The day that current-current becomes a stable-current (e.g. 6.0 gels, and the next effort will become 6.1, 6.5, 7.0) - actually from the day its released, doesn't it make sense to start directing maintainers to the constant (tc6.0) tag so that current-current can progress? Otherwise, if you wait from the point that 6.1, 7.0 actually begins, instead of the timeframe 6.0 goes into stabilization, the change seems to become exponentially more disruptive when it comes to pass :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r524777 - /tomcat/connectors/trunk/jk/tools/jkrelease.sh
Mladen Turk wrote: > Rainer Jung wrote: >> Hi Mladen, >> >> did you delete setting owner and group by accident from the release >> script? >> > > No, I did it by purpose. I don't have user or group named asf, so the tar > fails. What would be a purpose of it anyhow, and how would you ensure > that the same user will exist on the users box? It should be root / bin or similar. Simple - if you unpack without root privilage, it unpacks as 'you'. If 'you' == root, it would try to restore mladen:staff or whatever your group is. Please back out this change and make an appropriate change :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r524777 - /tomcat/connectors/trunk/jk/tools/jkrelease.sh
Mladen Turk wrote: > Rainer Jung wrote: >> OK, I forgot, that I actually had a user and group named asf (I >> thought tar would ignore their non-existance). >> >> All in all I would suggest root:bin to. > > I used root:users instead. > Think the users group exists on all *nixes. So does bin. users has a radically different connotation, that if you change the perms to 664, everyone on the box has access to the unpacked file, depending on your umask etc. Sounds very dangerous to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Mladen Turk wrote: > > The source distribution can be downloaded from: > http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source/jk-1.2.22/ > or > http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.22/ May I ask -why-? It's not released (quite yet, has 0 votes) - what on earth is it doing on the mirrors already when it's present in your /dev/ area for the committers to review? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Mladen Turk wrote: > > Don't understand your question. > It was more then a week available for a developers review. > The official stable is still 1.2.21 until 1.2.22 gets votes or not, > in which case we'll go for 1.2.23. > So what's the problem? How many times will I repeat to this list that until something has three affirmative votes from PMC members and more affirmative than negative votes, it is not a release from the ASF. And (this might be new to you) anything on www.apache.org/dist/ is official. This primarily protects you - it's your ass (your tarball) until the foundation adopts YOUR tarball as the ASF's release. Ratifying your tarball makes it no longer yours. So any legal fallout was just owned by the ASF. If you want be an RM, or at least play one at an ASF project, let the ASF cover your ass and wait for a vote before hanging yourself out to dry. Look, if it comes up again, I simply won't post here. I'll just point to the archives of the previous warnings/instructions and ask Infra to turn off some group bits as appropriate. The very few, very specific rules were spelled out on THIS dev list at least three times in twelve months. What's the disconnect? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Mladen Turk wrote: > I suggest you revoke my commit privileges to the > www.apache.org/dist/ so it won't happen again and you > won't need to repeat this again. I'm sure infra would be happy to if you would prefer this. I'm assuming the (this might be news to you) was news to you, but this struck me as altogether absurd. I thought everyone grokked why tomcat created the /dev/dist/ in the first place, and I thought everyone at tomcat was altogether with-it now on what constitutes a release. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Releasing Tomcat Connectors 1.2.22
Jim Jagielski wrote: > > On Apr 13, 2007, at 10:00 AM, Mladen Turk wrote: > >> Jim Jagielski wrote: >>> On Apr 13, 2007, at 7:20 AM, Yoav Shapira wrote: Let's try to chill out, please ;) I'm sure putting the candidate binaries on the official mirrors before the vote was an honest mistake. >>> ++1 (especially on the chill out part ;) ) !! >>> I think the issue is that, especially with the number >>> of podlings in incubator, the basic release rules for >>> ASF projects are getting kinda relaxed... >> >> Both of you guys are correct. >> It was: >> a) honest mistake >> b) a mistake >> >> So, can we agree I made an mistake? > > Hey, I make 'em all the time... Ditto (and sometimes real doozies - the more you help out, the more potholes you can step into :) Futher, it's resolved, I wanted to make sure I hadn't missed something when I posted the first question earlier today. If I knew it was deliberate, I would have simply had Infra resolve it in the first place. I asked first, then Infra solved it, so no crisis. No - I don't dislike you Mladen :) Nor Redhat - work with Marc and Joe all the time on httpd-stuff. Personally - I'm a huge fedora fan, with my work hat on - support hundreds of users on a few orders of magnitude more ES boxes. So not only do I raise this to protect you, but your employer, because I happen to like you both. And it happens to protect the foundation I'm also rather fond of. Yours, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: discussion of release
Tomcat-folk, Since there is still a bit of confusion about releases, here is what Leo had to say on the subject of releases earlier today on [EMAIL PROTECTED] I found this to be a really useful Q&A style dialog. I've simply replaced the "podling" or "PPMC" through with [Release Manager], [RM] or [committer], and "IPMC" with "PMC" throughout, as applicable. But I think Leo's words will ring clearer to some folks than my own, we all parse things differently. Leo Simons wrote: [...] > >> On Apr 12, 2007, at 2:39 PM, Leo Simons wrote: >> >>> There's just this one little tidbit - if the [PMC] votes to *release* >>> something, that something should then actually be released. "Release" >>> has a specific meaning and we (have to) do "distribution at no charge >>> to the general public" of them. I guess it's all in a name. >> >> I guess I don't quite understand the issue you are raising. If the >> [PMC] votes to release something, then it goes back to the [Release >> Manager (RM)] to make it happen. I don't see the [PMC] as actually >> "releasing" anything. All it does is to approve a [...] release, and >> then it's up to the [RM] to take the next step. > > I understand your interpretation, but I'm afraid it's simply not how we > need to think about these things. Releasing software is done > officiallly, on behalf of the ASF (which is a good thing because the ASF > is then responsible, and liable, for the release, not an individual > release manager). The only ways to do things officially on behalf of the > ASF are > > (1) an Officer of the foundation does it > (2) a board member of the foundation does it > (3) a Committee that was specifically delegated to do > specific things in accordance with the foundation > bylaws does the specific thing that was delegated > to it > > [An RM] is not a 'real' office set up by the board, so [they] cannot act > on behalf of the ASF. Because of this, whenever "acting on behalf of the > ASF" must be done for [a] project, the [PMC] has to do the acting. > > In this terminology, the "acting" is embodied in the release vote. > Actually creating and moving the files around is something more like > "administrative grunt work" if you will. > >> If the [release manager] discovers something else that's wrong, or for >> some other reason decides not to release, are you suggesting that somehow >> the [PMC] is going to go and release it anyway? > > Given the above, for all intents and purposes, after a release vote has > concluded, the thing that was voted on has been released. > > An in-progress vote can be canceled. > > After a vote has concluded, a release can still be "pulled". And we > don't seem to vote on pulling a release, it is just administrative action. > >>> The alternative is to *not* release something, and then there should >>> not be a release vote, but a different kind of vote, or no vote at all. >> >> Well, I guess I don't see this the same way. I understand that the >> [PMC] doesn't want to waste its valuable (!) time reviewing stuff that >> has no intrinsic value, but if a [committer] is at the point of wanting >> to make sure it knows how to release, and has all the necessary IP >> clearance, copyright notices, readme, and disclaimers, why not have a >> release vote? > > Because a release vote is an official part of the ASF processes that is > as official as it is for specific reasons, it serves a specific purpose, > and should serve only that purpose. > > Doing things this way is part of the "legal umbrella" that the ASF > provides its projects, and the strength of that umbrella depends (I > think) in part on everyone following the same basic steps. > > hope this helps, > > - Leo [Adapted for general PMC use by Bill] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk on i5/OS v5R4
Rainer Jung wrote: > That's what I expect too, but in the log file Henri posted at the > beginning of this thread, both runs were done by the same process and > thread id. So at least if pids have a meaning on iSeries, both runs are > done by the same process. That's different from the *nix world, where > there is a switch to a new parent in between (as long as I remember > correct). Nope, that's correct. Both config passes happen on the single, main process and thread. THEN following the second pass, processes are forked off, and the threads created in each process. THAT is the unix world of httpd. On Windows, both passes happen in both the parent and child processes, the parent is actually does not pass its config via fork() to the children. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk on i5/OS v5R4
Rainer Jung wrote: > Hi Henri, > > Henri Gomez wrote: >> 2007/4/17, Rainer Jung <[EMAIL PROTECTED]>: >>> Apache always initializes twice (all platforms), so this part is usual. >>> >>> What seems special though, is that on *nix platforms, the two init runs >>> are done by different processes, the second process replaces the first >>> one. Your mod_jk log file shows the same pid for both runs. So this >>> might be special and lead to unexpected results, because now things are >>> really done twice. >> >> Well I5/OS is running in MPM mode so... > > Yes, Apache 2.0 always uses MPMs, but on the platforms I know they never > initialize both times with the same process. The parent process always pre-loads the config, runs the full config hooks to test that the module can run, unloads everything and then will start "for real". - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
download page a mess
http://www.apache.org/dist/tomcat/tomcat-5/ is rather gross - any hope of cleaning up the chaos? 3x 5.5.20 + 2x 5.0.30? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Time for 4.1.32?
I know I've said it before, and I know Roy would wig out - but I'm not wigging
out, just trying to educate :) This wasn't a release vote, it was a poll.
It's always good to have a poll ("Should we try a beta now?") - you know that
nobody has something they needed another few days to work on. Or maybe someone
goes ahead and commits some code they had in a checkout, that just needed a bit
more testing first. That's cool :)
But the ASF votes on source code tarballs, we don't vote on trees, or the state
of trees, or the good of having more releases from a particular branch.
Anytime a committer wants, they are absolutely free to tag the tree and tar the
build. But at that moment, it's a 'plain old tarball', it's not a release (even
if there was a vote beforehand like this one.)
Announce the tarball and ask for a release vote. (To avoid confusion, I'd
really encourage the project to create an http://tomcat.apache.org/dev/dist/
location for such things - but those details are entirely up to you all.)
When the *tarball* has 3 +1's, more + than -, it's a release, an honest to
goodness release. If you want to offer folks to vote on alpha/beta/ga that
is ok too. [Acutally, 4.1 is so stable, I wonder if beta makes any sense
anymore, unless some refactoring introduced some new uncertainty.]
I keep rehashing this, because of my role on incubator. If established projects
can't get it right - what hope have we for our podlings who are just learning.
So -do- cut the tarball, but please conduct a vote on the release image,
not on the state of svn. It looks like you have lots of willing folks to vote
on that release :)
Thanks for stepping up to RM this, Mark!
Bill
Mark Thomas wrote:
Mark Thomas wrote:
+1's
Mark Thomas
Peter Rossbach
Bill Barker
Filip Hanik
Remy Maucherat
Rainer Jung
+0's
Yoav Shapira
The release of 4.1.32 beta is therefore approved by the Tomcat PMC.
I'll cut it this weekend with the announcement going out once it is on
the mirrors.
Regards,
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Time for 4.1.32?
William A. Rowe, Jr. wrote: Anytime a committer wants, they are absolutely free to tag the tree and tar the build. But at that moment, it's a 'plain old tarball', it's not a release (even if there was a vote beforehand like this one.) FYI - there's a reason for this. Even if there are competing interests, nobody can single handedly block another release, or even a small minority. Putting releases into user's hands is what the ASF is all about. Good ones we hope :) It might seem arcane, but this is based on the collective wisdom of the original httpd group to ensure that when there are times that folks are generally being disagreeable, at least the project cannot be frozen solid. I'm glad the Tomcat project is really working twords similar goals and we don't have any of that hassle here; but it's good to keep using the same pattern so that even if there were disagreements in the future, it's possible to keep the project flowing. Oh - and this isn't the same as releasing vetoed code. If you want to cut a release, and someone's commit has a veto outstanding, simply tag the version before the debated code was added. Again not a problem here lately, and that's a good thing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Time for 4.1.32?
Mark Thomas wrote: To clarify the position on the beta status, the Tomcat project has historically (at least as long as I have been involved anyway) released initially as Alpha/Beta as deemed appropriate, given people a few weeks to test and then had a stability vote. I intend to follow the same path for 4.1.32. +1 - and I really think this is a great thing that Tomcat does for it's users. Some weeks I wish httpd still did the same ;) My earlier comment was specifically about 4.1 - I'd certainly like to keep seeing stability votes on the rapidly changing 5.5 flavors, etc. And if you want to follow the beta-stable path for 4.1 there's certainly nothing wrong with that. Thanks again for the clarification, No problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r416193 [2/2] - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Filip Hanik - Dev Lists wrote: wow, what just happened here, how could the entire file diff when I checked it in once can someone shed some light on SVN for me here. Line endings. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
