Re: Apache Dinner Paris - Open World Forum
+1, I'm in also :)
2010/9/28 Emmanuel Lécharny elecha...@apache.org:
On 9/28/10 5:14 PM, Sylvain Wallez wrote:
Le 28/09/10 15:53, Bertrand Delacretaz a écrit :
On Tue, Sep 28, 2010 at 3:51 PM, Emmanuel Lécharnyelecha...@apache.org
wrote:
...
if ( asfer.isPuking() ) {
band.remove( asfer );
asfer.grabATaxi();
asfer.goToBed();
}...
FWIW, some ASFers like me will throw HadEnoughToDrinkException before
that happens, but I like the general idea ;-)
Same here. Now you have to make sure the recursive call doesn't produce a
StackOverflowError with some people :-)
More likely to get a OutOfMemoryException the day after ;)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org
-
To unsubscribe, e-mail: community-unsubscr...@apache.org
For additional commands, e-mail: community-h...@apache.org
Re: gmail accounts?
Greg Stein wrote: Hi all, A while back, I offered gmail accounts to a number of people when the number of invites that I had was pretty limited. However, I now have unlimited invites... If anybody would like a gmail account, then please reply to me privately and I'll hook you up. I'm happy to provide them to any ASF committer and their family. Stupid question but it may help others here : I've got two emails, [EMAIL PROTECTED] and [EMAIL PROTECTED] and registered many lists to them. If I switch to gmail, I suspect I'll have to unregister and register to all lists to be able to send mail to these lists ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clarifying some licensing issues for Apache developers
Brian Behlendorf wrote: It seems worthwhile to state something that probably most people are aware of, but a few recent incidents suggest is worth repeating. Followups are being directed to [EMAIL PROTECTED], a list that is private to Apache committers, where legal issues are discussed. Please subscribe to that list (requires approval) before posting to it. First off, thank you to everyone who has transitioned to the new Apache License 2.0. It is a board mandate that *all* software distributed by the Apache Software Foundation be under this new license. This has some subtle and not-so-subtle ramifications people should be aware of. *) Only software packages created by the Apache Software Foundation may be redistributed from Apache's servers and mirrors. This means no tarballs or binaries from other authors or organizations. We realize that many ASF projects depend upon other software, and that these dependencies may make it difficult for new users to bootstrap quickly. There are solutions to that problem outside of the ASF: ibiblio, sourceforge, CPAN, etc. The board might grant exceptions to this rule - bring it to us if you'd like us to consider it. Should I understand that we could no more include third-party jars in ASF products, for example mx4j jars in Tomcat ? If it's the case this decision will put many, many users in big trouble since they couldn't use anymore ready-to-run package (zip or tarball containing everything needed for run). As one of the founder of the JPackage Projet, www.jpackage.org, which try to maintain a repository of java applications and libs, let me say that the task is not so easy, and for now works only on RPM based boxes, mostly Linux. What should do non-RPM users ? I could understand the board concern about incompatible license, but when developpers select third-party software to make ASF products, they take care of it isn't it ? So I strongly suggest board to reconsider this point or we may see in a near future ASF products distribution, containing both ASF and required third party software, outside Apache servers and it will not help users to find their way. Am I exact in thinking that the original ASF goal is to provide real products for real users, and that we should take care of users as much as we take care of performance, stability ? Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mailing from apache email address
Phil Steitz a écrit : Brian Behlendorf wrote: On Mon, 10 Nov 2003, Phil Steitz wrote: Nice! Finally got this to work. It took me a while to realize that you really did mean localhost on minotaur -- i.e., something like ssh username@cvs.apache.org -L 109:localhost:110 -L 24:localhost:25 Sure. Though you don't need to use different ports. This would work fine: ssh username@cvs.apache.org -L 110:localhost:110 -L 25:localhost:25 Yes, I changed the ports to avoid conflict with sendmail running locally. You could even use the ssh connection for your cvs access :) ssh username@cvs.apache.org -L 110:localhost:110 -L 25:localhost:25 -L 2401:localhost:2401 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository
Stefano Mazzocchi wrote: [EMAIL PROTECTED] wrote: As an aside, one of the issues we had when coming up with Maven's repository format, is that often artifacts (jars, wars, ears etc), will get left on the filesystem outside of a repository. Think rpms for example. Having a file encode project-artifact-version.type has been very useful for us. Yes, it's often different from what the project creates and distributes, but I (and others) have been bitten by commons-logging.jar, struts.jar, junit.jar so many times, that seeing log4j-1.2.5.jar is a godsend. A big +1 to get version in jar file name : For instance in jpackage we install all 'small jars in ' : /usr/share/java/ And make use of symlink : /usr/share/java/log4j-1.2.7.jar /usr/share/java/log4j.jar - /usr/share/java/log4j-1.2.7.jar When there is many jars in a project, we're using subdir : /usr/share/java/jsse/jcert-1.0.3.01.jar /usr/share/java/jsse/jcert.jar - jcert-1.0.3.01.jar /usr/share/java/jsse/jnet-1.0.3.01.jar /usr/share/java/jsse/jnet.jar - jnet-1.0.3.01.jar /usr/share/java/jsse/jsse-1.0.3.01.jar /usr/share/java/jsse/jsse.jar - jsse-1.0.3.01.jar As such you could have many differents versions at the same time in the repository : ie : tyrex-0.9.7.jar (for TC 4.0.x) tyrex-1.0.jar (for TC 4.1.x) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Leo Simons wrote: Hi all, (sorry for the massive crosspost up front, as this is a proposal that should in the end come from the various PMCs towards the infrastructure team I'm doing lots of CCing, just once) FYI, the JPackage project where I'm also involved, as set up a Java RPM centric distribution where you could find many (still not all) apache's java projects. http://.jpackage.org/ We splitted the package in 2 categories, free and non-free. free packages are those that can be build from sources AND could be freely distributed non-free packages are those with licences which prevent them from being freely distributed (including ALL the Sun external but mandatory libraries like activation, mail...) For those interested, take a look at http://www.jpackage.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[poll] weblog package on apache.org
Let's (re)start the poll here since it's the commiters list was innapropriate ;( Subject: weblog package on apache.org The goal of this poll is to get commiters feedback on having a weblog package on apache.org. The basic idea is to provide ASF commiters a tool which could be used to expose their 'ASF related' works, ideas, notes using a common ASF LookFeel. Questions : - Did there is a need for a weblog package installed at apache.org where commiters could put notes about THEIR ASF related works ? - Should we select a Java based solution (the request came from jakarta-general initially), or anything else ? - Which packages/products are good candidates, having licence without apache members/commiters contestations ? Comments welcomed. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] creation of communitity.apache.org
Andrew C. Oliver wrote: You have a vanity license plate don't you? ;-) May be ;--)
Re: [proposal] creation of communitity.apache.org
I would like to propose the creation of such a virtual host so that all apache homepages will be hosted at http://community.apache.org/~name +1, although I would prefer a shorter name like people that was proposed at some time. I've make a dream : http://name.apache.org/ ie: http://remm.apache.org/ http://costin.apache.org/ http://pier.apache.org/ http://acoliver.apache.org/ ;-)
Re: Rules for Revolutionaries
Sam Ruby wrote: Ovidiu Predescu wrote: I'm glad this actually didn't happen, since it took a long time for the 4.0 branch to become stable and usable. If it weren't for the legacy codebase being continually developed, we would have been stuck with a slow 3.2 and a buggy 4.0. I've used Tomcat 3.3 for more than a year before switching to 4.1, and I liked 3.3 a lot for its speed and features. What would have been more likely to happen is that Tomcat 3.3 would have continued on SourceForge, been known by a different name, had a fully supported servlet 2.3 facade, and would have been known as the production quality servlet engine. Of course, it could had been a funny thing :) You should also remember that our friend Pier make many remarks about stability on tomcat 4.x and proposed sometimes ago on tomcat-dev to start a fork to make a minimal but more stable TC 4.X In retrospect, I think the decision to continue the development on both Tomcat versions was a good one. It let the time solve the frictions. The result is that now we have a very mature Tomcat community, and little of the past problems are reflected today on the mailing list. I agree, if at anytime, TC 3.3.x was said as obsolete or to be discontinued, I'll had to choose an alternate servlet engine since TC 3.2 was too slow and memory consuming and TC 4.x still not production ready. But the good thing in making TC 3.3 and 4.x teams continuing their own works was that Tomcat 5 get the best of both part, and was really quickly launched using jakarta-tomcat-connectors as a common sandbox. Sometimes, when you let 2 teams works in parallel on similar project but different implementation, you avoid that one team fly to another umbrella (ie sf.net) and sus save the community and also you could help making the next revolution by merging good ideas from both projects.
Re: Rules for Revolutionaries
Costin Manolache wrote: If you don't need or care about something - it doesn't mean you should vote -1 on it. If 3 fellow commiters are voting +1 - then probably there is a real need or issue. I don't think anyone voted -1 on a 4.0 release, and nobody voted -1 on the 3.3 release ( if I remember correctly ). No TC 3.3 team members voted +0 for 4.0 release and 4.0 members voted +0 for 3.3 release, and if you remember each team congratulated the other one for their release ;) BTW, keeping the both team working on each project has saved the tomcat-dev commiters community which should be the goal of Apache isn't it ?
Re: Rules for Revolutionaries
Jeff Turner wrote: On Tue, Nov 12, 2002 at 04:05:24AM +0100, Stefano Mazzocchi wrote: ... I still disagree. The rules of revolutionaries *MUST* (I repeat *MUST*!!!) protect the identity of the project more than they protect the freedom of innovation of the single developers. More than anything else, the fact that two different codebases were *released* with the same name at the same time, pissed many people off (myself included) and created a lot of problems in the users. Like? How many users do you see complaining because they have a choice? Personally, I find Tomcat 4's startup time is too slow for Forrest/Cocoon development, so if it wasn't for 3.3.x, I'd be using Resin or Jetty. You could speed up TC 4 startup time by : 1) comments mbeans support in top of server.xml : !-- Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ -- 2) Remove the admin and manager webapps which also take some time to initialize. Regards.
