RE: Jakarta embracing the JCP?
Having named leads of any sort is the antithesis of what I would like to see within the ASF. Fair enough, but there's no reason I can see why a JCP lead shouldn't be an OSS chair, I guess the JCP needs spec leads like the ASF needs chairpeople, to be a single point of refrence from above and a single focus for oversight from below. I'm sure that a great many of us work in teams with a team leader who isn't an autocratic megalomaniac, but largely the point of contact between above and below d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
On Mar 22, 2004, at 6:02 AM, Danny Angus wrote: Having named leads of any sort is the antithesis of what I would like to see within the ASF. Fair enough, but there's no reason I can see why a JCP lead shouldn't be an OSS chair, I guess the JCP needs spec leads like the ASF needs chairpeople, to be a single point of refrence from above and a single focus for oversight from below. THe difference is that the spec lead generally owns the resulting spec and licensing rights. geir I'm sure that a great many of us work in teams with a team leader who isn't an autocratic megalomaniac, but largely the point of contact between above and below d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. *** *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
Henri Yandell [EMAIL PROTECTED] wrote on 20/03/2004 08:52:35 AM: [snip] We already effectively have Expert Groups, we call them the PMC. Project Leads, aka active-voice on the project/component. I'm not sure it hurts for us to have a project-lead on things, in fact I think it's something Apache should have. Defined responsibility. I've seen this 'defined responsibility' drive people away from projects. I've also seen projects with a strong leader wallow as their leader has gone off and started something new and more fun. Bugs lie unfixed and the software stagnates. Having multiple people share the load is a far better model, IMHO. People view this as anti-community, but I think it's pro-community. Who is responsible to the community for Tomcat 3 at the moment? The community? That seems like we're kidding ourselves. The ASF-way merely means that it's easy to fill a project-lead gap, or to join in. Not that the project-leads don't exist. [snip] -- dIon Gillard, Multitask Consulting
Re: Jakarta embracing the JCP?
On Mon, 22 Mar 2004 11:14:13 +1100 dion wrote: I've seen this 'defined responsibility' drive people away from projects. (*1) Agreed. Often *innovative* guys run away from such projects. OSS guys do not want to take *responsibilites*, generally speaking. Also, this often dampens the motivation of the not-defined guys. I've also seen projects with a strong leader wallow as their leader has gone off and started something new and more fun. (*2) Agreed, too. Often *conservative* guys hate such projects - and say - This project is very primitive. -- Required would be *balance*, i guess. In case (*1), warm-hearted enemies would be often able to resuscitate (*1) projects. NOTE: If not-warm-hearted, (*1) would lose in competition. In case (*2), public appeal method would be required. In open source world, anyone can take over. - just people do not know what they can do (and they are shy enough) and where such projects exist. - Mechanism would resolve. offer for public subscription *plus* - allocation of appropriate rights Again and again, just a balancing issue. Also, community often loses balance. - Be careful. -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta embracing the JCP?
In my opinion, JCP and ASF should keep working just as they are. JCP has a more conceptual work, defining patterns and standards, while ASF has a more hands on to implement JSRS. It is the biz of JCP define what ASF is to do, while is about ASF know HOW to do it. Sun needs to keep some order in Java comunity, and that´s why JCP exists under her flag. ASF, in contrast is completely free, having no Boss, but ourselves. Naturally, ASF´s process is much ligther in terms of burocracy focusing in real world implementation of some spec defined. (specs are aways specs...hard to define, hard to rollback, better, no rollback, just a deprecated javadoc tag. Have you seen a refactoring in a JSR before? :-) ) things are working this way, and I think they should be kept this way. Sorry if this hurted someone, but my english is not so rich as I wished, to express my ideas. regards, Paulo. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Jakarta embracing the JCP? Date: Fri, 19 Mar 2004 13:44:32 -0500 How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP process? In what way? Can you be specific? As I understand the JCP, what you are asking makes little sense. We don't have spec leads, nor do we want them. We don't have ownership of a project/specification. Everything here is communal and consensual. That is not true of the JCP. Actually, I would prefer to see the JCP continue to evolve to become more like the ASF. What I'm largely interested in are the reasons why not, as these would be perfect reasons why something like groovy, or ant or httpclient, should not become jsr's. A JSR is a specification. It should have a TCK and an RI, but at heart it is a specification. Some people have talked about proposing the Apache Repository Specification, which I understand Maven will evolve to use, as a JSR. If that happened, I'd prefer to see us run a JCP Expert Group more in line with an ASF project, not run ASF projects like an JCP Expert Group. Geir? Your thoughts? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail, o maior webmail do Brasil. http://www.hotmail.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
On Mar 19, 2004, at 12:17 PM, Henri Yandell wrote: This is a little linked to the Apache-open source question raised a while back, though it actually comes from trying to explain to someone what the pro's and reasons for groovy as a jsr might be. How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP process? If there's anything the ASF are not happy with in the JCP we can adjust it, but generally we would manage our own projects in the same way that ASF involvement in the JCP.org says we should manage standards. Are you kidding? We'd have to go to meetings and discuss process documents. I do that 4 times a year as is as JCP rep, and that's more than enough! What I'm largely interested in are the reasons why not, as these would be perfect reasons why something like groovy, or ant or httpclient, should not become jsr's. Groovy is going through the JSR process so that the language will be formalized into a spec and protected for compatibility. This will give the Java ecosystem another language the runs on the JVM for which claimed implementations are guaranteed to be compatible. So... why not run [EMAIL PROTECTED] under the JCP process? Because there is no real need to assert that every project at the ASF in Java is some sort of standard, and further, doing a TCK is an awful lot of work. If we do have something that is a candidate to be standardized, we can go to the JCP and do it there. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta embracing the JCP?
Hi, Your English is great, don't let that stop you from expressing your opinions ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Paulo Simao [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 3:29 PM To: [EMAIL PROTECTED] Subject: RE: Jakarta embracing the JCP? In my opinion, JCP and ASF should keep working just as they are. JCP has a more conceptual work, defining patterns and standards, while ASF has a more hands on to implement JSRS. It is the biz of JCP define what ASF is to do, while is about ASF know HOW to do it. Sun needs to keep some order in Java comunity, and that´s why JCP exists under her flag. ASF, in contrast is completely free, having no Boss, but ourselves. Naturally, ASF´s process is much ligther in terms of burocracy focusing in real world implementation of some spec defined. (specs are aways specs...hard to define, hard to rollback, better, no rollback, just a deprecated javadoc tag. Have you seen a refactoring in a JSR before? :-) ) things are working this way, and I think they should be kept this way. Sorry if this hurted someone, but my english is not so rich as I wished, to express my ideas. regards, Paulo. From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Jakarta embracing the JCP? Date: Fri, 19 Mar 2004 13:44:32 -0500 How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP process? In what way? Can you be specific? As I understand the JCP, what you are asking makes little sense. We don't have spec leads, nor do we want them. We don't have ownership of a project/specification. Everything here is communal and consensual. That is not true of the JCP. Actually, I would prefer to see the JCP continue to evolve to become more like the ASF. What I'm largely interested in are the reasons why not, as these would be perfect reasons why something like groovy, or ant or httpclient, should not become jsr's. A JSR is a specification. It should have a TCK and an RI, but at heart it is a specification. Some people have talked about proposing the Apache Repository Specification, which I understand Maven will evolve to use, as a JSR. If that happened, I'd prefer to see us run a JCP Expert Group more in line with an ASF project, not run ASF projects like an JCP Expert Group. Geir? Your thoughts? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN Hotmail, o maior webmail do Brasil. http://www.hotmail.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
On Mar 19, 2004, at 1:44 PM, Noel J. Bergman wrote: How about if Jakarta [or Apache-Java as a whole] embraced the latest JCP process? In what way? Can you be specific? As I understand the JCP, what you are asking makes little sense. We don't have spec leads, nor do we want them. We don't have ownership of a project/specification. Everything here is communal and consensual. That is not true of the JCP. Actually, I would prefer to see the JCP continue to evolve to become more like the ASF. What I'm largely interested in are the reasons why not, as these would be perfect reasons why something like groovy, or ant or httpclient, should not become jsr's. A JSR is a specification. It should have a TCK and an RI, but at heart it is a specification. Some people have talked about proposing the Apache Repository Specification, which I understand Maven will evolve to use, as a JSR. If that happened, I'd prefer to see us run a JCP Expert Group more in line with an ASF project, not run ASF projects like an JCP Expert Group. That would be a good example of something that would be appropos for a JSR - something that others will/might implement, and if so, you want to be sure that your software which works with one implementation of it works with others. Geir? Your thoughts? We are always working to help move the JCP towards the OSS model, but it's a slow process. In JCP 2.5 (the guidelines for the JCP), the ASF's work was key in getting TCKs and RIs to be able to be licensed under and OSS license. Before that, there was no way to do an OSS JSR. Now, w/ 2.6 that just went into effect last week, the process now formally encourages as much openness and transparency as possible in an EG (although you still can do pretty much what you want...) as well as require an early release of the spec to the community to enable as much feedback and commentary as possible. Previously, the EGs had to release a community draft late in the process, and that made them afraid to have not enough time to fix stuff, so they would tend to really delay. The Groovy EG will be run as an OSS project, btw... geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta embracing the JCP?
On Fri, 19 Mar 2004, Geir Magnusson Jr wrote: On Mar 19, 2004, at 4:52 PM, Henri Yandell wrote: I'm still in disagreement. I'm founding a lot of this on the idea that Groovy is a good fit for a JSR. There's no reason for more than one implementation to exist that I can think of and there's no reason why an open-source project would be hurt under a JCP process. Both big leaps. Suppose that BEA wants to embed the language in their app server stack, and for whatever reason they want to re-implement for monitoring or to limit what program someone can execute Pretty hypothetical. They might want to do the same for JUnit or Ant etc. I think Groovy doesn't really fit the JSR-style so far, but I think it will be a good thing if it happens as it will help to increase the JSR from simply a spec-world into something more of a central clearing house for Java concepts. When you say under a JCP process what do you mean? Formally, it means that someone proposes a project (just like now to incubator, their peers or a PMC I suppose), and a panel of judges (the Exec committed) decides if it can go forward. An expert group then meets and works on the spec, offering it for public comment, and then producing a final spec, a TCK and a RI. What part are you missing in your life? Unsure. Mathematical beauty? Simplicity? I liked the idea of drawing parallels between two processes and allowing them to feed off each other and hopefully draw nearer [in terms of being more OSS friendly or more organised]. Formulate new proposals to the Apache lists in a similar manner to a new JSR and write projects up in a similar format. Have named leads and specified active-committer groups on components. Understand more about which apache-areas are active, which are actively watched and which are in a coma. Everyone seems to assume that the JCP.org exists to create specifications for other people to implement. I assumed that. It exists to create specifications. You could implement the spec, or if the business terms are acceptable to you, reuse the RI as the implementation, under whatever loony license the spec lead decides. However, I see no reason why Groovy fits under that assumption, and so I wonder what else Groovy will get from being within the JCP. In no order : 1) If you are opposing my 'yes' vote on the part of the ASF, speak now. My official motivation for the 'yes' vote is that I believe that it would be a good addition to the Java universe (and at worst, not a harmful one) and more importantly is a OSS project from EG to license to TCK and RI and may even use the ASF's proposed TCK and RI licenses. Wouldn't even if I could. I presume that opposing votes is an Apache board/member thing. I've made the point that Groovy as a JSR will be great as an OSS demo of the JCP on a jug list, so am in complete agreement there. 2) It's not an ASf project, so anything we say here about the motivations of the Groovy team are sheer speculation. (FD - I'm a member of the EG) Groovy will get a formal spec protected by the compatibility requirements of the JCP. It will also get some vague status of 'officialdom' although I have no clear idea what that really means. Seems useful for many projects, so if Groovy is hale and hearty in a year, it would seem that we should ask the JSR question of any apache components that might fit. Jelly, Ant, Maven leap to mind. Probably others. . One big problem/difference is [I've heard anyway] that the project lead has dictatorial powers. I'm not suggesting we ingest the bad water with the good. didn't you just state only 1 paragraph ago that you thought it good to have a defined lead? The bit I view as important is that a lead's responsibility is to the community. Largely this is a Jakarta-blindess on my part. The lead is yourself, the PMC Chair. In other projects it's blindingly obvious, but the size of Jakarta made me not notice it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jakarta embracing the JCP?
Formulate new proposals to the Apache lists in a similar manner to a new JSR and write projects up in a similar format. Have named leads and ... Having named leads of any sort is the antithesis of what I would like to see within the ASF. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
