Re: Apache should join the open source java discussion
Serge Knystautas wrote: Leo Simons wrote: Key ASF individuals are joining these discussions, on weblogs and various discussion forums. But the ASF as a whole is silent. In lieu of forming a statement for the ASF as a whole, what about organizing/encouraging/guiding people who want to participate? Maybe specific resources that should be targetted, such as where the most active and/or productive discussions are taking place. What about starting by making sure Apache java projects _do_ work with the 2 open source JVMs that are mentioned in the article ? That would be a statement, much better than we like open source java, but our software doesn't run on it because it doesn't really matter. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is a member?
Ceki Gülcü wrote: Roy Fielding once mentioned that anyone with a history of at least 6 months of sustained contributions was entitled to ASF membership. You have been offered membership in the past but you declined the offer. Correct? Yes, I'm not comfortable with some of the definitions of what is a member :-). There are plenty of people with lots of contributions, both code and community who are not members of ASF. I can't believe they don't believe in collaborative development, or are only interested in their own project. It's great that now the PMCs are growing to include most active committers - IMO ASF membership should be similar with PMC membership ( as admission criteria, etc ), i.e. based on contributions/merit and without all the superman stuff. In other words - church ( or party ) and state should be separated :-) Costin At 12:03 PM 11/27/2003 -0800, Costin Manolache wrote: There are many ways membership could be defined ( but it isn't ). Committers are assigning the (copy)rights of their work to ASF - and as was mentioned, the members own the code and all the IP of ASF. It would be nice ( and fair !) to have the membership based on some objective criteria on code and community contributions. I can't know the exact rules that are used - but sometimes it feels a lot more like membership to a political party. The scary thing is that some of the answers to what is a member ( and I've seen many of those during the last years ) sound too much like a certain party :-). I would assume most people who choose to give significant amounts of time and code to ASF are serious and serve the interests of the ASF. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How ASF membership works and what it means
On Thu, 26 Jun 2003, Greg Stein wrote: On Fri, Jun 27, 2003 at 12:32:08AM +0100, Pier Fumagalli wrote: ... Best way of doing things? Writing a connector for the servlet container using JNI that uses unix sockets, named pipes, or something which is actually faster than the usual TCP socket we use between Java and Apache, but embedding a JVM inside the Apache process space is a big nono... Oh, come on... show us your True Programmer Manliness(tm) and shove the data over to the JVM via shared memory! :-) Hmm. Wait. Java doesn't give you access to shared memory? oh, too bad... JDK1.4 ( NIO ) supports memory maped files, which is a good step in the right direction ( it also adds select, etc ). And of course, a bit of JNI can do anything :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: .Net languages (was: How ASF membership works and what it means)
On Fri, 27 Jun 2003, Greg Stein wrote: On Thu, Jun 26, 2003 at 07:42:12PM -0700, Costin Manolache wrote: ... Dot net is actually doing almost the same mistake as java (AFAIK)- they support other languages, but only syntactically ( like java does with the languages that generate java bytecode ). AFAIK you can't integrate unmodified python or perl with .net code. Sure you can. I wrote a compiler for Python in 1998 or 1999 (forget which) that compiled Python down to MSFT's CLI. Mark Hammond and I worked on that together, altho it was mostly me getting the framework set up, and Mark running to the goal with it. I believe the Python.Net (and Perl.Net) stuff is available from MSFT and/or ActiveState now. Have no doubt tho... it compiled any Python code to the CLI. The obvious problem was dealing with Python extension modules. Not much could be done about that. But pure Python? Or the standard Python library modules? You bet. My point was .NET makes exactly the same mistake as java, by integrating python by compiling it to .net bytecodes ( what you describe ) and making it fit the .net. Just like Jython does in java. Check http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html for a list of languages that work on top of java. The only difference between .NET and java ( in this area) is that .NET advertise this pseudo-integration as real integration , while Java marketing tries to paint is as unpure and bad. As you point out, dealing with _existing_ Python modules and codebase is the interesting part - that's the _real_ integration. Costin [ for the Python stuff, we compiled direct to the CLI; I think the Perl stuff took the approach of writing C# code, then compiling that ] Cheers, -g -- Greg Stein, http://www.lyra.org/ - 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: [ANNOUNCEMENT] Commons-Logging 1.0.3 Released
On Mon, 7 Apr 2003, robert burrell donkin wrote: Could you also upload the jars, in the binary directory ? It would simplify the life of those who want to automatically download dependencies. gladly but first a couple of questions: 1. is this someone that we should now be doing for all releases (in which case, i'll add the instructions to the how to release documentation i've been working on)? Since tomcat has a download target - I am particularly interested by the jars that are used by tomcat. We currently get the .tar.gz and expand it - but it would be faster to just get what we need. If this happens for other releases - that would be great. 2. this is the binary directory in the mirrored release section, right? does this relate to the repository stuff (and if so, how?)? Yes for the first, that's where all files ( and binaries like .jars) should be distributed. For the second - I have no idea :-), and I don't want to get into any discussion about repository. We do have a dist/ directory that is mirrored and I think we all agree that's where the releases should be placed. It does have some clear rules - including the binary/ directory. And the .jars are clearly binaries. :-) BTW, my understanding is that some symlinks are required to the -current version. I would really appreciate if for the .jars we would use the name of the jar without -current. ( for the symlink - the filename needs to have the version). This will allow download with the full name or the latest release - but avoid the need to rename in the second case. Costin - robert - 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: [proposal] daedalus jar repository
On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: 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. Yes, but I already mentioned that it can easily break features that work: if a project uses Classpath attributes in the manifest ( a legal option that simplifies setup - you may like it or not ) - then some things will stop working. It will also break any script or program that creates classpaths by using jar names. And it will break the explicit CLASSPATH env variables and manifest attributes once again every time you upgrade - since the jar name will change. It'll also break Ant build files that use the jar name - just do a grep on jakarta and you'll find how many they are. All those problems can only be solved with the active participation of the projects - by implementing whatever code is needed to support filenames that change. For Classpath attributes - that's not possible, so project will have to agree to stop using this (nice IMO ) feature. It doesn't matter how nice the versioned filename may look or how much it can simplify maven code - if it breaks the code of the project ( sometimes in subtle ways - if ant or a project won't find a jar, it may disable a feature ) It is also redundant information - each jar has a well-defined Manifest that should include version. .so files are versioned - that would be the perfect argument to convince people to adopt this naming scheme. But think what happens if someone takes a .so file that was shiped with an application, and renames it to something he feels is nicer. The app will just stop working. You can't mess with a project distribution files without the risk of breaking something. Many people like this naming convention - but they can't impose it to everyone. I'm more then willing to accept and support this naming scheme - my only condition is to be the result of an informed decision by the apache developer community. ( the breakages are just 2 simple examples - there are many other arguments in both sides ) BTW - an important thing to keep in mind is that in many cases the latest version of a .jar may fix security bugs - so it shouldn't just pick the buggy jar. Having multiple versions of the same jar in a system creates huge problems. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote: Seeing the interest it has raised, I tend to think think it's time to get the act together and start working on it. I'd like to propose this for incubation ASAP, so to not loose momentum. ... Codebases or part of codebases that could convole in the effort: ... I don't think the main issue is codebases. What we need is a minimal common ground on naming conventions for the repository ( so projects can get in sync with the repository ), and an agreement on a metadata format ( descriptors for dependencies and versions and so on ). I think discussion on codebase will just create a mess. The goal is to have a jar repository and get some consistency among our projects. If we have a layout and metadata we agree on - any tool could work. If it is an ant task or a perl program or we just rsync - it doesn't matter. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and community
On Fri, 28 Feb 2003, Noel J. Bergman wrote: Collaboration does happen, now. It's not a future waiting to happen. Is there something that's not happening that specifically needs to be looked at? That's the irony. As far as I can see, most of the build processes could converge around Ant and Maven. It isn't hard to see how the domains served by Gump and Centipede could be subsumed by Ant and Maven, given the additional development that you've told me is already happening. The thought behind my earlier question about the PMC, which initiated this spiral, was that having Ant and Maven under a PMC would help that effort. I tried to stay out of this discussion. The points that I care about is where Maven tries to set a standard that will affect the other build tools. The repository is one example, the descriptors is the other. If the apache community can reach an agreement on base standards - with the participation of all projects and people who are involved or care about the build process - then we're fine. And it is even better if we have multiple tools to support the repo and descriptors and try to make the build process easy. I am worried that Maven will use agressive propaganda and the ASF brand to compete against Ant. All I've seen so far suggest that. And I think that would be bad. However - agressive propaganda has a tendency to backfire, and smart people usually see beyond it. I'm talking about all the landslide move, all others are crap, convert all your projects to maven, the removal of ant build files in projects to force people to use maven, attacks to persons who are involved with competing projects, etc ( I know that people learned that some of those tactics don't work well - and I'm sure I'll see more ) One problem may be that this kind of propaganda may hurt the ASF brand and all projects involved - competition on easy to use or features or speed is good in itself. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
On Fri, 28 Feb 2003 [EMAIL PROTECTED] wrote: In other words - as long as maven decisions affect only maven - I don't care. But if it affects other projects, and the repository certainly does - then the PMCs of those projects or the apache community are the ones that decide. Sure, but please take into account the work we've already done. Of course. The maven word comes up quite frequently on this thread :-) The issue is that the repository on daedalus will affect all apache projects that choose to use it ( to download and upload files ). I don't think distribution of a project's files from apache repository should be handled by anyone other than the project itself. The release manager should sign the files, make the announce about the release and so on. If Maven or other projects want to rip the official distribution apart, rename jar files, etc - in its repository - that's fine. For non-apache jars ( if we get an agreement on including them in the apache repository ) - IMHO distributing them as close as possible to the original layout is the best choice ( assuming the download tools can handle that ). +1 on the oversight committee for non-apache jars. Believe me, the oversight bit is the hardest part. I agree. It must involve the board and the lawyers. A strong -1 on oversight for apache jars. We already have PMCs for each project, and those should oversee the distribution of their own files. Even by other projects? I think we are still discussing the oversight of the daedalus repository, and who should have the responsibility. I think jakarta PMC should be responsible for the files in the jakarta* directory in the repository. Other projects and peole can of course oversee in the sense of checking the files and pointing out problems (like a project can't run without a non-approved dependency ) - but I don't think they should make release decisions for jakarta projects. ( same for ant and all other apache projects - jakarta is just an example ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Thu, 27 Feb 2003 [EMAIL PROTECTED] wrote: Few simple questions: Should we use 2 different dirs for src and binary distribution ? Or maybe 3 dirs ( src, bin, doc ) ? Why duplicate the existing distributions? They're available, mirrored and well understood. +1 I was just commenting on the original proposal - that included the dist/ tar.gz. Maybe a better alternative would be to just enhance the current dist layout with a jars/ directory, instead of creating a whole new structure ? And the only remaining issue would be defining the metadata format for dependencies and other info. Are milestone builds acceptable ? Should we get some weekly gump builds from HEAD into the repository ? FWIW, Milestone and even 'snapshot' builds have proven necessary for projects using Maven. I agree. Even more for projects with longer release cycles ( tomcat, ant, etc ), where betas and milestones are likely to stay around. What policy should we use for removing older versions ( or we just keep everything ) ? It needs to be driven by usage. If someone is still using ant 1.1, fine keep it available. There's nothing worse than a build failing because the repository has changed. +1 again. I would add usage and project policies/needs. If a major issue is discovered in a jar - I see a good reason to remove it and add a fixed version. A build failing is better in this case. Since the versioned jar/unversioned dir format is used - I think various PMCs should try to get the various projects to use the same format internally. That's a project decision. I don't see anyone should be forcing the projects to change their build process to match the repository. That's why I think projects and repo should use a similar layout. If the documentations and project tools expect ant.jar, and the repository gets ant-1.5.1.jar - then we have a small problem. ( there are pieces of code that add a certain jar or check for a particular name - all manifests with class-path are vulnerable ). Again - it's maven choice on what to do with its repo, I'm talking only about the ASF repo - and I think it should match with the project layout. If a consensus is reached on a particular naming - it would be very important to get it adopted by projects. But having a projects files in the ASF repo in sync with the project needs ( and code ) is more important. the ibiblio repository has manual admin as an option (at the moment it's the only one). I would prefer the reverse ( versioned dirs / unversioned jars ) - but I can live with the reverse if it does have a majority support. So asking the projects which format they would like for a repository they don't currently use? Sounds like asking for uninformed opinions. I'd be happier to come ask them to participate in a discussion here. Quite the contrary - I think the projects know a bit better how their jars should be used. Again - code and build files that checks for a particular name is common ( and I don't see anything very wrong with it ). I strongly disagree with the statement that the third party distributor knows better than the original project authors how the project files should be layout. Sometimes redistributors thay need to make adjustments to match their layout - but that allways causes some pain, and the only way to get around is to have the original project support the layout ( for example - apache httpd and RedHat ). Could we put at least this option to a vote, just to have a record that it isn't just a random decision but what the committers really want ? Why not ask the users of the repository. The committers wont be the main users. No, but they do the work that is used by the users :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
On Wed, 26 Feb 2003, Noel J. Bergman wrote: - the ASF repository shall contain ASF jars, which don't require oversight beyond the issuing PMC. - the ASF repository should contain shared third party jars for which the ASF has approved their use and distribution. - the ASF repository shall be mirrorable. Tools intended to work with the ASF repository should understand mirroring. [If not, they may select a specific mirror, but I don't believe that we want them to select the ASF repository as *the* location.] Yes - finding the closest mirror ( or the fastest mirror ) is technically possible, but I'm sure most people would be ok if they just select one from a list, like they do for sourceforge. The ASF distributions are already mirrorable - all that we need is for the .jars to be included. I'm not very sure why the daedalus repository needs to make the symlinks ( when the main dist for src and binary releases is established ) and how those will be mirrored. - multiple repositories are good things, and smart tools should deal with multiple repositories. Supporting multiple kinds of repositories is good - i.e. support the original distribution format. A download tool shouldn't be specific to apache or apache repository - it should be able to get stuff from ibiblio or sourceforge or Sun or IBM ( eventually after displaying the license where it is required ). Multiple repositories for Apache projects are not a bad thing - maven or centipede or RedHat can choose to create other forms of repositories ( that work better with their tools ). I use apt-get to install software on my linux ( and emerge on the other box ) - a rpm or gentoo repository ( that is up to date ) would be great. I usually preffer getting a jar from the source - in the original format, with the signatures and guarantee of the producer. - a smart tool might present a click-through license. The repository should permit this as necessary. [netbeans.org does this, by the way] Yes, that's a good example. Not sure if netbeans download tool supports sf or will support ASF repository - or if they provide their own repository with software to download (well, they do - but I don't know how complete it is ). I'm sure eclipse and other IDEs will eventually either support the original repositories ( my prefference ) or their own repositories. The actual layout of the files and location ( ASF mirrors, sf mirrors, etc) is far less important then the metadata format that describes the dependencies. We already have Gump descriptors covering everything in apache - and IMO this should be used either directly or transformed in one of the standard formats for describing dependencies. ( like apt descriptors, etc - there are several de-facto standards that are already supported by tools ). - ASF projects, however, must not rely upon unapproved third party jar files in such manner as to compromise their license integrity, even if that jar is not distributed via the ASF repository. Exactly. It was made clear ( and nobody objected ) that using tools in the build process is acceptable, and runtime dependencies are the main concern. So in the build process ASF projects may need to get GPL stuff from a GPL repository. This should be optional - IMO - but it seems this is not a legal requirement. If this becomes an apache-wide policy, I strongly disagree that Maven can decide for apache policies. I have proposed that the repository be a build-tool-neutral infrastructure sub-project, since Dw expressed the willingness to have it under infrastructure. I propose that Dion Gillard initially lead that effort, taking advantage of his experience in the area. I don't believe that Dion is a Maven will define for all kind of guy. Yes, the repository effects all projects, but to me that just means that each PMC that cares to should represent itself, not that we need to have dozens of people working this out. Not sure what you mean by lead ( do you propose a new PMC with Dion as chair ? ). I'm +1 on Dion - however the layout and recommendations must be decided by the normal apache community process ( which doesn't include the notion of lead, but proposals and votes ). Again - at least I have absolutely no problem accepting any layout, as long as I am sure it is the result of the apache community decision. Maven made a number of decisions that may be excelent for maven - but they're obviously different from what many apache projects use in their distribution. I'm also fine with a layout and policy that is set by infrastructure, under authority from the board. If a layout/policy is defined - we should do our best to sync the projects and start using the layout ( same thing that happened with the mirroring ) Same for metadata ( that describes dependencies ). However for metadata I think the standard requires participation from all build projects ( who want to
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On 26 Feb 2003, Jason van Zyl wrote: Since I am the one who asked why Ant and Maven aren't related projects under a PMC, you might was well yell at me for having the temerity to ask a rather obvious question. But for all of your railing this morning, you never actually answered the question. To expand, I think ultimately all that matters is that a project be given the space it wants in an attempt to let it flourish. If the Maven developers want to be left entirely alone why is that a concern? If we compete head-on with Ant why is that a concern? If we compete head-on with Centipede and it's satellite of related projects what's the concern? If we don't want to use Gump or talk to any of the Centipede so what? Compete with us! You cannot force relationships between groups when the desire to do so does not emanate in mutual proportion from both parties. I have no problem with maven doing whatever it pleases. The subject of this thread was about the jar repository on daedalus - and about who will oversee it. Maven can choose to not participate - but it can't choose to put it under its charter. I see no problem if Ant, Gump, Centipede cooperate on the jar repository - and maven doesn't. AFAIK Gump and Centipede does not compete with ant or with each other - quite the contrary. If maven wants to compete with ant or gump - that's great, competition is a good way to improve. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Wed, 26 Feb 2003, Nick Chalko wrote: So I am for /projectname/[subproject]/[version]/file[-version].jar That leo suggested. I'm not sure that's what Leo suggested. Having the version in both dir and jar seems a bit too much. The common practice in many projects ( at least in jakarta ) is to use jakarta-SUBPROJECT-version for packages and dirs in the dist. Changing that would be quite painfull - and require a lot of work. Getting the version number in the jars names is not easy either - it require changing build files, docs, scripts, maybe manifests. But it can be done, if it is clear that this is indeed an informed choice. Having one format in the repo and one in the official releases is IMO the worst choice. A download tool that is flexible and can support both formats - and eventually a descriptor that maps the type of names - is easier and require less work than changing all projects. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
On Wed, 26 Feb 2003, Noel J. Bergman wrote: Do we really need to have one big community? We've fostered a tight knit community of maven developers, even if they are not so tight with other parts of Apache. No, I don't believe that we need to be all one community. There is relatively little in common between, for example, Tomcat and James. [Although I do want to see if Remy will spare some time to help us integrate org.apache.naming into James as well]. Well - James IMAP, POP, NNTP servers could benefit a bit from tomcat's low level server components. With tomcat5 moving more to a JMX-based model with less coupling - I'm pretty sure much more could become common. Of course, the servlet container and jsp part are orthogonal. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
On Tue, 25 Feb 2003, Leo Simons wrote: files in /dist/java-repository besides perhaps HEADER.html and README.htmls... Few simple questions: Should we use 2 different dirs for src and binary distribution ? Or maybe 3 dirs ( src, bin, doc ) ? Are milestone builds acceptable ? Should we get some weekly gump builds from HEAD into the repository ? What policy should we use for removing older versions ( or we just keep everything ) ? Since the versioned jar/unversioned dir format is used - I think various PMCs should try to get the various projects to use the same format internally. I would prefer the reverse ( versioned dirs / unversioned jars ) - but I can live with the reverse if it does have a majority support. Could we put at least this option to a vote, just to have a record that it isn't just a random decision but what the committers really want ? This is my biggest issue with the repository conventions. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] daedalus jar repository (was: primary distribution location)
On Tue, 25 Feb 2003, Noel J. Bergman wrote: all PMCs whose committers 'commit' to the repository should maintain some oversight. Infrastructure hasn't considered that a good model for the Wiki, and I don't know that it would work any better for the repository. Someone needs to take responsibility for the oversight. Ok. I think jakarta PMC should have the oversight over all directories starting with jakarta. Same for the other PMCs. Directories that don't start with a PMC name should be under the oversight of infrastructure or board or any other entitiy that understands the licensing policy of apache. Is this acceptable ? Yes, that does. But I am expecting that people will want common things like JUnit, which I understand to be acceptable so long as the IBM license is there. Once the binary distinction of ASF v non-ASF is dropped, then the simplicity of it being OK because it is all ASF-licensed code turns into the policing scenario that Maven is currently practicing, through Dion Gillard. I think all non-apache jars should have the oversight of board or some other entity that can make an authoritative decision on accepting/rejecting packages ( or at least licenses ). But using the repository to hold third party jars for which the ASF has specifically ascertained appropriate license rights exist seems to be what gives us the most bang, because it is the third party libraries that are the most potentially time consuming and risky. Rather than each project have to deal with each third party jar, using the repository for that purpose would both share the burden of acquiring suitable license rights, and ensuring that they were acquired. +1 So, yes, the ASF-only distinction simplifies repository policing, but using it as the central location for authorized third party jars simplifies overall policing of third party license issues for the ASF as a whole. As long as the policing is done by the right people. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ATTN: Maven developers [was: primary distribution location]
On Wed, 5 Feb 2003, Sam Ruby wrote: In two weeks, there is a board meeting. At that time, I would like to be able to report that the contents of the Maven repository conforms to the policies of the Apache Software Foundation. Code under the ASF License is clearly OK. As is the IBM Public License (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following public domain components are also approved: Antlr and Doug Lea's concurrency package. Licenses clearly not conforming to the ASF's policies for distribution: LGPL, GPL, Sun's Binary Code License. If possible: we need a review on the JMX1.2 RI license. My understanding is that it allows redistribution ( JMX1.1 was more restrictive ) and it doesn't seem to require click or other things. No other JMX1.2 implementation exists at this moment and we need some of the security enhancements. Tomcat5 relies on JMX. I consider this critical. Costin Please direct any questions or comments (including new licenses to be considered) to [EMAIL PROTECTED] Some we can resolve for ourselves (e.g., the specific public domain packages above). Others I'll batch up and forward to the board and/or licensing folk. By the board meeting after that (3rd week in March), I'd like to have the infrastructure issues resolved (where should this data should be hosted, mirrored, etc). - Sam Ruby - 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: licensing review
On Wed, 5 Feb 2003, Noel J. Bergman wrote: Code under the ASF License is clearly OK. As is the IBM Public License (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following public domain components are also approved: Antlr and Doug Lea's concurrency package. Licenses clearly not conforming to the ASF's policies for distribution: LGPL, GPL, Sun's Binary Code License. Please also take a look at this: http://www.gnu.org/software/classpath/. The authors intend and believe that the exception granted allows that code so licensed can be used to run free as well as proprietary applications and applets. I have spoken with Nic Ferrier about this license exception. They specifically intend for it to remove any viral implications related to their binary distribution, and redistribution, and they believe that it does so. In the specific case, this is related to the service provider example, so I am only concerned about the permissible use of their binary jars. +1 - if Classpath license is found to be compatible, this will solve a lot of problems, as they provide alternative implementation for JNDI and many other APIs. I think this particular one deserves special attention ! Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: licensing review
On Wed, 5 Feb 2003, Noel J. Bergman wrote: I don't get these GPL people who license their work as GPL, but don't want the viral aspect... I believe that they are trying to separate the licensing of the source code vs. the binary. If you want to use their SOURCE, you have to keep the source code GPL; no proprietary changes. If you just want to use their BINARY, do with it as you wish, unencumbered. In any case, the only issue in my mind is receiving their binary releases unconstrained and unencumbered. This is very similar with some of the other licenses from Sun ( and IBM ) that allow redistribution of the (original) binary - but don't provide the source code under the same terms. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wiki - we have a problem :)
Are we now going to have similar oversight over the mailing lists and archives ? If someone posts a pointer to warez or porn on one of the lists - are we going to have to remove it from archives ? Sorry, but I fail to see the difference between wiki and the mailing lists. Both are open to anyone to post - with the slight requirement to provide a valid email address - if people don't use news gateway ( that can be added to wiki as well ). The information that is posted on mailing lists is archived and available on the web just like wiki. IMO the problem is that wiki is treated in the same way with the CVS or the web site. It should be treated as a mailing list with public archives. I am more concerned with the potential that someone who disagrees with the content of the page would remove it - but again this abuse can be resolved if we require a valid mailing address ( and we can restore the page ) On the other side - I have no problem with having one ( or several ) Wiki per PMC or subproject, and mirroring the postings in the wiki to a mailing list. Costin On Fri, 31 Jan 2003, Dirk-Willem van Gulik wrote: Folks, I am seeing this weeking discussion reaching conclusions of sorts. However there is still a significant problem with oversight. What I mean here is -not- the ASF cultural thing of having things validated by your peers; but the oversight of the type that the ASF as a US incorperated is supposed to maintain. In this role's I am not as much concerned with pages going up which say 'Thou venomed swag-bellied skainsmate!' or other types of respect lacking community interaction; but specificaly of the type which gets us in real-live(tm) trouble; warez, child-porn, list of license keys, etc. So unless I hear this group establishing some very clear policy with respect to WiKi's I will propose to the board that they go and instruct the infrastructure@ folsk as follows: -No Wiki(s) will be ran under ASF auspicien unless there - is a PMC or similar body who duly provides oversight to any abuse. - and the infrastructure@ pmc has validated that whatever access control, metrics and what not are appropriate and that each resource can clearly have an 'owner'. Note that I did not add things such as acceptable use policies or charters. I leave that to the PMC. Though I personally would certainly encourage PMC's wanting a PMC to think about that; as 'scope' helps to foster quality discussion. Though simply saying that use should be on topic or in line with the mission/goal (which usually is firmly embedded in the resolution which created the PMC in the first place) helps. Note that this is what is effectively happening on the push based mailing list; moderation, warning being send to pwersons going off topic and other non appropriate postings, and a community sense of 'scope'. I'd appreciate feedback to solve the 'NOW' problem (not getting sued by the scientology church or abetting (US) crime) - and to help me ask the board for the right thing. We can solve the 'real' issue later. Dw - 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: [poll] weblog package on apache.org
On Wed, 29 Jan 2003, Henri Gomez wrote: - Did there is a need for a weblog package installed at apache.org where commiters could put notes about THEIR ASF related works ? +1 I don't think it is a need - but it would be a good idea. I know there are free or cheap hosting sites - but the point is to have access to the software. I think there is a (pretty strong ) need to agregate the blogs on apache. - Should we select a Java based solution (the request came from jakarta-general initially), or anything else ? Anything that works. I would be fine with Python or Perl. - Which packages/products are good candidates, having licence without apache members/commiters contestations ? Don't know. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Apache Jakarta Law (Scientific?)
So far it seems Stefano ( who is not currently a very active tomcat developer) is pissed off by the decisions made on tomcat-dev. I don't see too many tomcat developers flaming each other. IMHO most ( or all ) tomcat developers agree that both code bases had some good and some bad parts. I also think most of the tomcat community is behind 5.0, which is a merge of ideas and code from both 3.3 and 4.x. And I think users were very well served, and the outcome is one of the best possible. In the end we have a far better community and a lot more tolerance and understanding. Costin On Tue, 2002-11-12 at 08:28, Andrew C. Oliver wrote: The Apache Jakarta Law: Any discussion regarding Apache Jakarta will eventually degrade into a discussion about the Tomcat 3.3/4.0 issue, often including a full re-analysis of the events, revision of the history, and sometimes degrading into a full re-enactment of the emotionally charged flamewar that engulfed the Tomcat project at the time. Often even those who don't often participate in such interesting uses of time will even match the judgement logic necessary to participate in such a conversation. I hope one day my Law is proven false. Perhaps if those involved were to take this on to a wiki and document all about it, the different view points and lessons learned, opposing lessons learned etc, we could one day make this law obsolete at least. -Andy Joe Schaefer wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: [...] I believe it was a mistake to allow two different codebases to share the same name. I'm not convinced that having two codebases is necessarily a mistake. So far the discussion here seems to have centered around the concerns of the existing tomcat developers. I'd like to know what the tomcat users (ie. the future tomcat developers) think of the 3.x/4.x division. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rules for Revolutionaries
On Tue, 2002-11-12 at 07:25, Stefano Mazzocchi wrote: Here is what I would have liked to see happening in Tomcat: What you would have liked is your problem. As I repeated quite a few times and you don't seem to hear is that the decision about a release is a majority vote and can't be vetoed - even if it pisses off some people. A vote on a feature or revolution doesn't mean the end of other features or codebases. As long as each codebase can gather a majority vote - things are going well. There are people who can vote +1 on more than one release and codebase. What's important is that most of the people who vote +1 on a codebase don't automatically vote -1 on the other codebase - which is the real solution. 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 ). And I think the same should apply to other apache projects, even older ones. Costin
Re: Rules for Revolutionaries
In my personal opinion they are just redundant :-) The rule that matter is that the community control the code and the name - a majority vote in the community can decide ultimately what happens. This is a particular case ( again IMO ) of the releases are majority votes and can't be vetoed. A side effect of the 'revolution' rules is that a veto can be overriden - nobody can veto a revolution ( or a release ), and if you change the entire code base or a part of it you obviously can make changes that were vetoed. There are few important consequences: 1. No person ( or group ) can control a codebase by using veto. It is quite easy to find technical reasons against anything. 2. It removes some personal conflicts. A veto or someone blocking an idea can be painful. It's a big difference between a majority voting against a particular idea and one person vetoing it. 3. To take tomcat as an example - it allows diverging groups or opinions to find the common ground. And that's the really great part IMO. 4. Some good ideas that may otherwise be rejected can eventually live. Costin On Fri, 2002-11-08 at 13:50, Sam Ruby wrote: Rodent of Unusual Size wrote: my curiousity has been set off again. there have been numerous mentions of the revolution concept as used in jakarta, and its widespread acceptance as policy. however, i don't see it mentioned in the jakarta guidelines; in fact, only in ted's proposal for new guidelines. is jakarta's semi-formal acceptance of it as an operating principle actually recorded anywhere, or is it actually just an 'everybody knows that' informal general acceptance? general acceptance is probably too strong a word. There are some, including apparently the original author, who now have doubts. But there can be no doubt that this document has strongly influenced the evolution of a number of Jakarta projects. For further reading, I'd recommend taking a look at topics 3 and 4 in http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html In my mind, the concepts of vetoes, revolutions, and releases being a majority decision are linked. Note: when Roy made the statement about releases, it sure sounded to me like he was stating it as if it were ASF policy. In any case, I would recommend that it be so. Taken together, provisions are made for individuals to get attention to be focused on issues that they feel are important, individuals or even small groups can flesh out concepts that may initially be controversial, and a safety valve is provided so that forward progress can still be made. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Can someone summarize what's wrong with the gump descriptor used by all jakarta and xml projects ? I understand we may need to add more stuff ( maybe using some ns: ), but I don't quite understand why we need to change existing definitions. Costin On Tue, 2002-11-05 at 14:08, John Keyes wrote: snip/ If the answer to above is yes : cool and from a maven perspective the above is what can be offered, based on the maven project.xml, and I can write a maven plugin to generate that xml. If you had something different in mind, please explain ;) What you propose is simply a subset of what I envision. With the above descriptor, we can create both a centralized page with the summaries for all projects *and* project summary pages. It sounds like it would make sense if maven was modified to import a projectinfo document and therefore it could generate the project page using it. This would support the vision of it being tool agnostic. -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Jakarta PMC bylaws change
I partially agree with Dirk's opinion. A very large PMC where people don't feel a direct need to participate is wrong. That's the reason I think 'active participants who volunteer for PMC' is the right solution. If someone doesn't feel 'active' in jakarta or doesn't have the time or wish to act as a PMC member - he should be 'emeritus' or shouldn't be an active pmc member. If someone is active in jakarta he probably has all the reasons to be active in the PMC as well - because most issues will affect him. A license problem in a project that you use is a license problem for your project too. And the motivation to solve this is pretty strong. The process should be as objective as possible and bottom-up driven - the number doesn't matter that much as long as everyone is motivated and affected. If the people in PMC are only a subset - it is very likely the 'hierarchy' issues will affect us. People might feel their membership in the PMC gives them extra power on day-to-day project activities. Or we may have extra politics on the selection. Costin On Mon, 2002-11-04 at 09:51, Dirk-Willem van Gulik wrote: On Mon, 4 Nov 2002, Stefano Mazzocchi wrote: Can you tell me what's wrong with a PMC which is almost silent, is composed by committers and manages just one codebase? sounds like an ideal situation for a PMC. From that perspective nothing. Assuming that all is well... and the silence does not mask a certain sort of inertia. However bear in mind that HTTP is small, has very easy and almost 'objective' external requirements in the form of RFCs and had a relatively small code base. Even the rewrite of 1.3 to 2.0 to address some fairly well known issues is/was relatively simple compared to some of the major engineering and dust being through around elsewhere. Now if this would be all - no worries. However I personally think that the transition from that one HTTP crowd to one for HTTP, one for APR, etc, etc was already showing that something is a bit amiss in the scaling; even though the group of peopple is nearly overlapping; long term goal, feature creep in APR, versioning issues between APR/HTTP and even getting release notes out with some sort of coordination with php/perl treading-aint-work warnings, required a fair amount of noise in order to get the coordination they required. I cannot help to think that a much smaller group of people across those projects whould have done better than the current cabal keeping things on track simply by being a smaller focal point who know that they cannot dodge the issue. However it is not here where I see the major issues exposed right now - but when scaling up and over to: It is the jakarta/xml ones which worry me; as they are so much bigger and deal with some much more code; a lot of which does not have a nice RFC or clear set of requirements to easily compare options or provide guidance. Yes, many agree with you in this vision and I think Sam's proposal goes in the direction of creating an evolutionary escape path or, at least, a way to have spread the word about things for those who won't make it here on [EMAIL PROTECTED] Right. Moreover, I don't think a PMC with a hundred of members will behave any worse than a PMC with just a few of them. And I do think it is; as a PMC of a hundred members will never act quicker or more focused/quick as a group of 5-10 people recruited out of those 100 who have a task (say investigate a license issue) and know that there are a 100 people looking at them to get it done. Now having said that; perhaps we need to cycle those 5-10 people much more ofter; as I agree something is amiss. But I think making them a 100 is not the right track - and that is where I see the main flaw. And I also think that too large a cabal will simply create 'chair's whose job is much bigger than a volunteer can handle. It is that task I'd like to split among 5-10 people. As ultimately the board will continue to chase chairs to get things done. And it is easier for a chair to prod a few people nearby than to galvanize the populus as a whole for the sort of boring tasks asked. I really don't think that it can be worse than we have today, so +1 from me. Aye - as I said - short term it is our best option - I think; and if I where a jakarta-head I'd certainly give it a +0 or +0.5. Dw - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subtle barriers to entry
On a related issue - I think it would be very nice to include a link to gmane news gateway. There are quite a few people using it ( I'm no longer directly subscribed to any list ), and I think it should be at least mentioned. I don't know if a news server taking the feed for US distribution or our list mirrors is possible - I can help setting it up if there is enough interest (and resources). Costin ( and if you know someone at google who can get the feed into their news archives - we would solve the search issue very well :-) On Mon, 2002-11-04 at 12:01, Chuck Murcko wrote: I've noticed in looking around the Apache sites that there's a lot of inconsistency in providing links (usually in the sidebars) where people can get on the mailing lists. Some projects, like Foundation, HTTP Server, Cocoon and Forrest, provide wide gateways for participation. Big, friendly, colorful, clearly marked links. Many have Getting Involved sidebars that link to lists of things, and the mailing lists are in there. Some befuddled me in attempts to find any mailing lists at all without going to the project's main page. Home != Get Involved to me. I speculate that one factor in the breadth and quality of development community is the number of clicks it takes to find the -dev list, the general navigation semantics of the site, and the amount of camouflage those links have, whether on purpose (in the case of Jakarta it sure seems that I am being forced to read the guidelines and then be clever enough to notice the link - no bypassing Mom on this page!) or not. Is this just driven by the number of config questions and suscribe (and other) trolls to the dev lists? Or the rising percentage of doofuses in the net world? I knew we should never have let AOL hook up that gateway to the net. 8^) I ask because I'm laying out a Jakarta project site, and I'm used to the -dev list guidelines being something short and sweet, like lurk a bit before jumping in, and search the archives to see if your question (if that's the only reason you're here) has been answered. Or maybe I should just point users to http://www.faqs.org/rfcs/rfc1855.html, and say Read before posting; if you don't, YMMV widely. I presume all here have read that. Just MHO on a community issue. Chuck - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Openness
VOTE 1: would you like to make it possible for non-committers to read this mail list thru a web archive? [X] +1 yes, let's make it readable [ ] 0 don't know/don't care [ ] -1 no, let's keep it private - o - VOTE 2: would you like to make it possible for non-committers to fully subscribe to this mail list? [X] +1 yes, let's open it to everyone [ ] 0 don't know/don't care [ ] -1 no, let's keep it for committers only Costin
