Re: Jakarta at the center of the (ASF) universe
I would tend to agree with Jim. The commit rights never attached to Jakarta but only to a specific subproject under the Jakarta umbrella. There has never been any such thing as a Jakarta committer, only committers to current and former Jakarta subprojects. Likewise, there is no such thing as an ASF committer. The codebase commit rights attach to specific TLPs. As mentioned elsewhere, the first graph might be even more interesting if the threshold was lowered, even to just one committer in common. -Ted. On Nov 18, 2007 4:10 PM, Jim Jagielski [EMAIL PROTECTED] wrote: On Sun, Nov 18, 2007 at 01:58:29PM -0500, Geir Magnusson Jr. wrote: But that's the fact - that most of JavaLand sprang from jakarta... Jukka's graph shows committer cross-polination, not *codebase* cross-polination (as I understand it)... So yes, since most committers for most ASF java projects were in Jakarta (since those projects were *in* Jakarta, after all), I still think that the non-Jakarta page provides a more accurate representation of the real dynamics, by removing the artifical aspects of Jakarta. Of course, I could be wrong :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ Great is the guilt of an unnecessary war ~ John Adams - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is there interest in an integrated development infrastructure built using Java open source products? (was: Suggestion to use OpenGrok... )
On 9/3/07, Henri Yandell [EMAIL PROTECTED] wrote: Personally I'd ask the reverse question of the Fisheye users. Can OpenGrok serve the same purpose? If so, then we should stop using the commercial app and move to the open app. Following up on similar comments made by various people on various threads, perhaps we should consider assembling a complete Java open source stack for use as an integrated development infrastructure. The stack could use Harmony and Derby as a foundation, with products like James, Tomcat, Daisy, Roller, EyeBrowse, OpenGrok, Scarab, and Continuum running in between. The product niche would compare to SourceForge, Google Code, CollabNet, and so forth. We could test and document the system, and bundle it up for distribution to the general public. (Perhaps relying on Maven as a distribution mechanism, a la AppFuse.) Of course, we could also make the platform available to interested ASF projects. Ultimately, some of us might be using the same development infrastructure at our day jobs that we use for Java work at the foundation. The Cocoon group is already running Daisy in a zone, and we also have a Continuum running in a zone, but here the idea is that we would have a full suite of ASF and related products running together, over Harmony, as a single offering. If we take the perspective that we are going to distribute the platform to the general public, and perhaps deploy the platform here for our own use, then the initiative would seem to fall within the scope of a PMC or lab. Thoughts? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Suggestion to use OpenGrok to index all Jakarta source code
Would FishEye serve the same purpose? * http://fisheye6.cenqua.com/ There is already a procedure for using FishEye with an ASF project. First, ask on infra@ for permission to have cenqua.com setup a FishEye instance for your project. Then, contact [EMAIL PROTECTED] and ask them to add your project, and include a copy of the post from [EMAIL PROTECTED] ATM, the only concern seems to be that the initial indexing occur over the weekend. The administration is handled on the cenqua.com side, and so our group is not directly involved. Meanwhile, Atlassian has acquired Cenqua Products, and we're told that Atlassian is working on integration components with JIRA and other Atlassian products. The integration products are expected to be open source, and so we will be able to use them here as soon as they are available. -Ted. On 9/1/07, Alf Høgemark [EMAIL PROTECTED] wrote: I have a number of times missed an an easy to use web interface for searching through all Jakarta source code and subversion change logs, and to also being able to see line number and subversion change log history for a particular file. The OpenGrok tool ( http://www.opensolaris.org/os/project/opengrok/ ) seems to me to be very useful in that respect. So I would like to suggest that OpenGrok is set up to search and index the Subversion repository at http://svn.apache.org/repos/asf/ OpenGrok seems to be a lot more useful than what is currently available using a web browser to point to http://svn.apache.org/repos/asf/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
FWIW, I'd like to change my vote to +1. The existence of a Apache Commons project devoted to Java doesn't automatically preclude the future existence of an Apache Ruby Commons or Apache .NET Commons. After all, the project names are only labels. Should another application for a TLP Commons be made, my hope would be that our Java commons would be predisposed to sharing the host name with our fellow volunteers, should such a request be made. -Ted. On 5/10/07, Ted Husted [EMAIL PROTECTED] wrote: On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: [ ] +1 I support the proposal [ ] +0 I don't care [x] -1 I'm opposed to the proposal because... I do not feel the draft resolution adequately addresses several remarks made in the discussion thread. The resolution should address issues raised as to the scope of the PMC and the use of the commons namespace. Comments on the other thread included remarks like * We'll do whatever the community wants to do. If someone proposes a Ruby library and we have a community interested in creating and supporting a Ruby library, then it would of course be strongly considered. and * Multiple PMCs, one website. So we'd have Java Commons, Ruby Commons, BobsYourUncle Commons PMCs, and they'd all share a commons.apache.org website. But, as it stands, the resolution implies that the proposed PMC will be excluded to Java and would own both the top-level Commons project name and the commons.apache.org namespace. Neither remark is addressed. If we are open to a TLP Ruby Commons or DotNet Commons, then we should reflect that openness in the resolution and in the project name. We can't use Java (been there, Sun complained). But we can preserve the Jakarta name, and leave the door open for an top-level Apache XML Commons or a top-level Apache C# Commons. So why not the Apache Jakarta Commons Project? Or, if we intend that this PMC provide oversight for components in other languages later, then we should strike the word Java from the resolution now, and clarify our intent. Time is not of the essence, and I believe we should define the scope of the PMC and the commons.apache.org host name and namespace now, rather than create FUD later. It took five hundred email messages to create the commons in the first place, and we can spare a few more to get the TLP resolution right. My suggestion is to * amend the Project name to Apache Jakarta Commons PMC. and setup shop as commons.apache.org/jakarta Let the focus of this PMC remain on Java, but, in the Apache spirit of openness and collaboration, make way for other Apache Commons projects in other languages. -Ted. -- HTH, Ted http://www.husted.com/ted/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/26/07, Henri Yandell [EMAIL PROTECTED] wrote: Ack in terms of driving a community away because it is unable to meet our arbitrary criteria. That sort of thinking just seems so Borg to me. It's another way of saying that a software product only has value if its hosted by the ASF. If a subproject, or even a project, is down to one or two committers, and those committers can't find a third, and don't want to apply to the Commons or declare the product dormant, then setting up shop on GoogleCode is an excellent alternative. I've done the same myself, and it's not the least bit painful. In many ways, it's joyful. It might even be healthy if more ASF committers were involved with other hosts. The ASF may be a cult, but it should not also be a fetish :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/25/07, Henri Yandell [EMAIL PROTECTED] wrote: 4) Goto code.google. Ack :( I wouldn't discount GoogleCode (or Java.net or SourceForge or CodeHaus). Right now, there's a GoogleCode site that I use everyday, and it's been utterly reliable. There's features I miss, but the UI is so convenient, I don't mind. We are not Borg, and not every software product need live under the ASF umbella. Jakarta2 - A flattened commons-like umbrella which in terms of change means a flattened dev@ list and svn changes. What I don't know is whether people are going to be demanding that the subsites look the same; ie) need to mavenize each project and adjust the site. The easiest way to deal with things will be to move the other subprojects into Commons and reestablish the Project. This is probably just an unfortunate turn of phrase, but we can't just move anyone anywhere. The Incubator PMC is not going to accept any code without volunteers to go with it. Likewise, we can't do anything about the subproject websites without volunteers to do that work too. But, as a PMC, we could ask infra@ to create a shared mailing lists to replace the others, and make karma adjustments. Here's my take-away from Henri's post. The Jakata PMC, as it stands today, could set a deadline for the remaining subprojects to make other hosting arrangements (TLP, Commons, Google). Otherwise, on a date certain, we would create single Jakarta Dev and User lists for all the remaining subprojects to share, and open karma to all the subprojects to all the Jakarta committers, in the style of the Commons. In other words, create a TLP, join the Commons, or become a commons. One other alternative would be for the active committers to those remaining subprojects to draft their own resolution proposal for creating a new Jakarta PMC, and boot the rest of us out. :) Though, if anyone wanted to make that happen, I'd suggest making it happen for the June board meeting, to coincide with the Commons proposal. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/23/07, Niall Pemberton [EMAIL PROTECTED] wrote: Committ access and being a PMC memeber are 2 different things - its been mooted that we should carry over the current Jakarta commit list for Commons (which I'm in favour of) - but that would be for the PMC to decide if its formed. Retaining someones commit access is a passive thing which is OK - making someone responsibe for a new TLP needs their consent IMO. As to the point of active consent, did each and every individual listed on the proposed resolution either actively consent in an email message on an ASF list, or add their own name to the list? In other words, what was the source of the initial list of PMC members? If there was a thread behind this thread, we should incorporate it by reference. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/23/07, Stephen Colebourne [EMAIL PROTECTED] wrote: In fact, I object to the fact the it seems to be so difficult to escape Jakarta. :) So far, it's been *much* less difficult than creating the Jakarta Commons in the first place! Back in the day, we actually had a separate mailing list just for for the discussions about whether to create the subproject, and how it would work if we did! :) So far, the TLP resolution quickly passed by a landslide. Two of us had reservations about an Apache Commons project that's devoted to Java, as opposed to an Apache [Java|Jakarta|Mocha|J] Commons that's devoted to Java. There were two other negative votes for different reasons, and almost thirty votes in the affirmative. Meanwhile, some of us have pointed out that the other remaining subprojects are within the scope of the Jakarta Commons, and have wondered if these subprojects would now like to join the commons. Of course, that could happen before or after the proposed resolution is offered to the board. But, if it did happen first, that change would remove any complaint as to using Apache Jakarta Commons as a project name. From the beginning, the intent was to submit the proposed resolution to the June board meeting. There's time yet to see if the other subprojects want to join, so nothing is being delayed. I'd encourage people to step back for a moment and look at what Jakarta actually is today. Its a very disparate group of voices pulling in different directions. This is a natural result of the true meaning of Jakarta - the community around the code - leaving. There is no longer any focus within Jakarta. Nor has there been for a *very* long time. Ummm, you may be confusing cause and effect. Jakarta has been very disparate group of voices pulling in different directions for as long as I've been here, which would be going on seven years. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/22/07, Craig McClanahan [EMAIL PROTECTED] wrote: PS: Yes, of course, there are passionate believers in the development of particular libraries. Are there enough to make a viable community for *any* of the libraries on their own? Or enough that care about the Commons ecosystem as a whole to satisfy Apache's notions of community? It is not clear to me (any longer) that a commons type environment fits Apache culture (as it is currently being discussed) at all. You're right, it probably doesn't. Towards that end, we should encourage Commons components with robust communities to apply for top-level status, so that they can report directly to the Board and have their own mailing lists. The one list rule is a great equalizer and should help keep the Commons from becoming another Jakarta. To support smaller communities throughout the ASF, we may need to adjust our notion of Committer and PMC Member to include not only people who can write and apply patches, but to embrace power users too. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/22/07, Stephen Colebourne [EMAIL PROTECTED] wrote: In summary: a) I believe the status quo is not viable b) I believe that merging commons into Jakarta merges two mismatched groups My suggestion was to merge the Jakarta subprojects into the Commons, not the other way around. * The remaining subprojects all seem to be reusable components within the scope of the Commons charter. * If the remaining subprojects join the Jakarta Commons, then we could then ask the board to re-establish the Jakarta PMC, using the list suggested in the draft resolution as the initial PMC. * The extended Commons group then becomes the new Jakarta PMC. * The http://jakarta.apache.org/commons/index.html page becomes the Jakarta home page, and we change the first sentence there to read The Jakarta Commons project is focused on all aspects of reusable Java components.. In the alternative, without an anchor subproject, or a ready initiative to promote Java at Apache, realistically, Jakarta whithers away. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ad dormant code: what about matured code? (Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Rony G. Flatscher [EMAIL PROTECTED] wrote: There may be many reasons why a project turned dormant: no interest (dead technology), committers having gone astray, etc. One reason that may be special is a project which got developed, is used, but there is no reason to develop it further. If classifying a project as matured it still may need fixing of problems and/or enhancements over time, making it necessary to create a new distribution. The idea of putting a matured project into the incubator realm does not sound right to me. That's is *not* what is being said. What is being said is that if a codebase loses all of its committers, and there is no one to nominate new committers, and one or more new volunteers come along that want to work on the codebase, then those individuals could become committers by applying to the Incubator. Anyone who is the position where they have become the last one or two committers to a codebase should put out a bulletin, first asking for other ASF Committers to step up, and if no one replies, then nominating likely candidates from the user list. Unless there are already rules that mandate that projects that got developed to a point after which they go into maintenance mode need to go into the incubator, I would suggest to create a new classification for such projects. Again, no one is suggesting that any codebase be unilaterally moved anywhere. If we are short of committers for a codebase, then what committers remain should recruit new committers. If we lose all the committers, and new volunteers come along, then the Incubator becomes the way that we bootstrap the new set of committers. When we realize that have no committers, for whatever reason, then someone should patch the website so that everyone knows where we stand. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Danny Angus [EMAIL PROTECTED] wrote: Ok Ownership is perhaps the wrong word, if Jakarta is being disbanded who provides the oversight? The same people who provide oversight for any ASF project: The people doing the work. If anyone wants Jakarta to be the ASF portal to all of our Java assets, then make it so. A commit is the only vote that counts. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: That *you* don't see a problem in using the Jakarta name, doesn't mean no one has expressed objections (you even responded to those objections) Yes, I looked back over the thread, and I stand corrected. You did say that the use of the Jakarta name in another TLP seemed premature. Do you still feel that way? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: It's not just you :) It's just too early to do that at this stage, since if it is just some commits as Teds says, it will be a dead horse. I don't need something formal or something, but at least get some attention from the java projects out there if they are willing to help out and also have some collaboration with David Reid / projects.a.o. It's not worth it if the Apache java projects don't like the idea and help out at least with their project. (not suggesting you are of a different opinion though Danny) Then take it to the next stage. Update the Jakarta home page to include links to our other Java products that were never part of Jakarta, like iBATIS, and invite all ASF Java products to use our news feed. Open the door, and see if anyone walks in. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Then take it to the next stage. Update the Jakarta home page to include links to our other Java products that were never part of Jakarta, like iBATIS, and invite all ASF Java products to use our news feed. Open the door, and see if anyone walks in. I am on a different schedule, volunteering on my own terms. In my view doing this now is *way* too premature. I currently only want to invest my time and energy on Jakarta and it's current projects. That's fair. Every volunteer should scratch their own itch :) If other volunteers were ready to explore this course of action now, would you object to someone creating a [EMAIL PROTECTED] portal here by extending the Jakarta home page? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
What if the proposal were to create the TLP for the purpose of reporting directly to the board, but nothing else changed? Would the project name Apache Jakarta Commons still be a problem for you if the physical infrastructure remained here, under the Jakarta hostname? -Ted. On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Yep still feel that way. Projects that want to use the Jakarta name, should just stay here till they are the only one left and after that re-establish the Jakarta Project. Mvgr, Martin Ted Husted wrote: On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: That *you* don't see a problem in using the Jakarta name, doesn't mean no one has expressed objections (you even responded to those objections) Yes, I looked back over the thread, and I stand corrected. You did say that the use of the Jakarta name in another TLP seemed premature. Do you still feel that way? -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: One link to a separate page isn't a problem, since I prefer that no major changes happen to the main site at this stage. Currently I am pretty much dedicated in keeping Jakarta as a brand. And when that time comes to worry about that, I'll work with the people who still have the itch and the cycles to spare. Starting to make it happen now feels like a waste of time, since the future of Jakarta is by no way set at this moment. Why does it have to be and either/or proposition? I would think that regardless of what anyone envisions the future of Jakarta to be, extending the home page to highlight *all* of the Java products at the ASF would be a Good Thing. The notion of extending the Jakarta home page so that it can become the focal point of all things Java at Apache seems orthogonal as to whether or not Jakarta continues to host subprojects. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened) commons become Jakarta.. Then why the concern about the use of Apache Jakarta Commons as a project name? When the time comes, we could just point jakarta.apache.org at commons.apache.org/jakarta. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/21/07, Ted Husted [EMAIL PROTECTED] wrote: On 5/21/07, Martin van den Bemt [EMAIL PROTECTED] wrote: It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened) commons become Jakarta.. Actually, it might be helpful if you repeated yourself in full, to be sure we're not talking past each other. For example, I don't know what flattened means. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The future of Jakarta
On 5/15/07, Danny Angus [EMAIL PROTECTED] wrote: 0/ Do we agree that the end-game is dissolution of the Jakarta PMC and closure of the project? Pro - Draws a line under the reorg effort which has gone on for 3 or 4 *years*. Con - Removes the remaining tangible historic links between former Jakarta sub-projects. At the ASF, we let them that do the work make the decisions. (Mainly because we have to ... otherwise, there would be no one willing to do the work!) We can talk about end-games until Sol goes nova, but in the end the volunteers who do the work will make the decision. So far, the subproject committers have been deciding to create their own TLP. Not because the Jakarta PMC said so, but because the subproject committers said so. The one proactive step we could take is to set a deadline for other TLPs to migrate or to find some other home, either as part of another TLP, or with another project host. Or, we could just wait the remaining subprojects out, and let nature take its course over the next year or three. 1/ If so do we wish to preserve the Jakarta brand? (the website and possibly general@) Pro - As Ted H. says We should stop thinking of Jakarta only as an entity, and go back to thinking of it as to the ASF synonym for Java, as originally intended. With this thought in mind around 10% of the referrals to james.apache come from jakarta.apache. Con - Others consider that the effort of maintaining the resources would be unacceptable to anyone.\ The goodness of the Jakarta brand isn't the result of working on the Jakarta brand. It's the result of fostering healthy communities that create great software. Now, those communities have gone on to create their own TLPs, and to create their own brands. Sure, Jakarta has name recognition. But so does Ant and Maven and Struts and Tapestry and Velocity. Essentially, Jakarta was the first incubator. Now we have a top-level Incubator, and most of our subprojects have gone on to become TLP too. I think Java at Apache has succeeded beyond anyone's wildest dreams. Today, the communities we fostered don't need the crutch of an uber-project. They can stand alone, and for that we should be happy! But not to worry. Whenever we foster healthy communities that create great software, we will create another great brand. It's what we do. :) 2/ If we believe that the brand should be preserved should the commons TLP take ownership of the brand (if/when Jakarta PMC is dissolved) Pro - Commons is an active community which continues to fulfil the jakarta==java remit. Con - Commons is not necessarily interested in the brand or maintenance of its resources. (would people from other projects step up) At the ASF, great brands are created by healthy communities that create great software. I would say that the Commons certainly fits that bill. An excellent way to preserve the Jakarta name would be to lend it to the Jakarta Commons TLP. After all, the Commons had a lot to do with creating the Jakarta brand as it exists today. 3/ If we believe that a commons TLP should not own the brand are any of the alternative options acceptable? - Retain the Jakarta PMC solely to maintain the brand - Move ownership of the brand to the prc (should they agree to have it) - Move ownership of the brand to projects.apache maintainers An Apache Jakarta Commons does not obviate a Jakarta federation or a Jakarta portal. If anything, reuse of the name increases its value. We can have our cake and eat it too! x/ Should we consult more widely the Members and/or the Board? At the ASF level, when we talk about protecting a brand, we usually mean give credit where credit is due. Being a meritocracy, we don't want other people diluting our brand by claiming our work as theirs, or their work as ours. So long as the Jakarta brand is not being poached by a third-party, I doubt that anyone else would care. From an ASF perspective, the only things of value are those things that attract qualified volunteers. From a marketing perspective, a brand may attract downloads, but I don't know if it attracts volunteers. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/14/07, Jesse Kuhnert [EMAIL PROTECTED] wrote: From a practical pov isn't java already associated with the word grouping commons apache? To Java folks it is. But, XML has a Commons too, as does Web Services. A third group tried to create a top-level Commons last year, and creating Commons for other languages has been discussed in other places. Once we have a Commons PMC for the Java language, other folks will want to do the same. If you need a differentiator I would put it in the commons-net.apache.org or whatever name instead of soiling the existing branding that has already been cemented in everyones minds whether people like it or not. The underlying problem is that Sun won't like us use Java as a modifier. The reason we use the word Jakarta is because Sun asked us to find another host name. The brand that is cemented in everyone's mind is Jakarta == Java. Speaking as the knucklehead who suggested the Commons subproject name in the first place, I don't believe it is in the spirit of the Foundation, or the Commons ideal, for us to assume such a generic name all to ourselves. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/14/07, Stephen Colebourne [EMAIL PROTECTED] wrote:
Also, from a practical matter, our projects already use org.apache.commons, so
this is
already recognised in the ASF.
Verbose package names are a Java notion, and they are only relevant
within a Java application. Regardless of whether there are other
{$Language} Commons projects, we could still use the o.a.c package
name.
On 5/15/07, Danny Angus [EMAIL PROTECTED] wrote:
No, that's the point http://commons.apache.org/
I think what's important is that the Java-language Commons PMC not
hijack the top-level hostname space or the top-level projectname space
all to ourselves. If we plan to share the hostname space with other
TLPs, then we all we need to do is make the base URI
* http://commons.apache.org/jakarta
or
* http://jakarta.commons.apache.org
instead. But, we should do that from the beginning, rather than try
and retrofit it later.
The key point would be what modifier to use along with the Commons
moniker. We can't use Java, because Sun will likely complain again.
We could use some other modifier, but we already adopted the term
Jakarta for this very reason.
We can create a Jakarta Commons PMC without affecting the future of
the Jakata PMC. We should stop thinking of Jakarta only as an
entity, and go back to thinking of it as to the ASF synonym for
Java, as originally intended.
-Ted.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/13/07, Martin van den Bemt [EMAIL PROTECTED] wrote: I don't see why. As a member of the Jakarta PMC I'm willing to allow jakarta-commons.apache.org to use our trademark :-) The problem is that you will be hijacking the Jakarta name and since the future of Jakarta (and usage of the name) is by no way set, using the Jakarta name in a new commons TLP is for me at this stage a premature call. We can't hijack what is ours. This vote is not taking place on the Jakarta Commons-Dev list. It is taking place on the Jakarta General List, and, AFIAK, it represents a vote of the *Jakarta* PMC. In the alternative, we hijack the Commons name, which, as others have pointed out, is already being used by other ASF entities, not to mention that it was also used by a top-level project, now closed. * http://commons.apache.org/ I don't know if Henri has discussed the reuse of the Commons TLP name with the Board, but it's possible not everyone will be thrilled with creating a new Commons TLP with a different charter (e.g. Java). Creating a Jakarta Commons PMC avoids overlap with the closed Commons TLP, and avoids overlap with any future projects that might want to create a TLP -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/10/07, Henri Yandell [EMAIL PROTECTED] wrote: * Multiple PMCs, one website. So we'd have Java Commons, Ruby Commons, BobsYourUncle Commons PMCs, and they'd all share a commons.apache.org website. This one was definitely a random suggestion. If we reach a point of impasse with another commons wanting to start, then I (with board hat on) think the solution would be to have multiple PMCs and 1 website. Or maybe that really means a portal and a site behind it. All hypothetical though - XML Commons is dead, DB Commons never happened and WS Commons is afaik not highly active. We do own the Commons space currently. The suggestion may have been random, but it's sound. We already have three ASF Commons group, Jakarta, XML, and Web Services. At one point, some of were working on a dotnet proposal * http://opensource.atlassian.com/confluence/oss/display/commonsnet/Home It would be niave to believe that the ASF will not want to create another Commons for another language. To clear that path, we only need to include a modifier in the project name as well as the website address. As much as I would like to believe we could create a multi-language Commons project, it just doesn't seem like a realistic goal. Experience shows that we can have multi-language products (iBATIS, Logging, Lucene), but experience also indicates that we can't have multi-language projects with multiple products (Jakarta). I would suggest that the reasonable path would seem to be to * keep the focus of the Jakarta Commons PMC on Java, * keep Jakarta in the new project name, and * use jakarta-commons.apache.org as the host name. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
Then why not just strike the word Java from the resolution now? -Ted. On 5/9/07, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Hi, I think this was discussed before and the consensus was we will change the charter if a C# project actually shows up. Jakarta is dying because there is not enough adhesion between the projects. The binding element of the commons TLP is currently we are developing Java components. If there is significant mass in any other language/technology, it is simple to update the charter later, not to over-engineer it at inception. Best regards Henning On Wed, 2007-05-09 at 15:44 -0400, Ted Husted wrote: It would be nice if the proposal allowed for some flexibility as to language. We do have several ASF products written in C#, and the notion of starting a C# commons has come up a couple of times in discussions between open source C# developers. -Ted. On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: Sadly a bit too late to make the next board meeting I suspect. However, here's a vote for Commons to officially request that it move to TLP. http://wiki.apache.org/jakarta-commons/TLPResolution Please add your name if you're a Commons developer and haven't added your name yet. [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Henning P. Schmiedehausen -- [EMAIL PROTECTED] | J2EE, Linux, |gls 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau Open Source Consulting, Development, Design| Velocity - Turbine guy |rwc |m k INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: [ ] +1 I support the proposal [ ] +0 I don't care [x] -1 I'm opposed to the proposal because... I do not feel the draft resolution adequately addresses several remarks made in the discussion thread. The resolution should address issues raised as to the scope of the PMC and the use of the commons namespace. Comments on the other thread included remarks like * We'll do whatever the community wants to do. If someone proposes a Ruby library and we have a community interested in creating and supporting a Ruby library, then it would of course be strongly considered. and * Multiple PMCs, one website. So we'd have Java Commons, Ruby Commons, BobsYourUncle Commons PMCs, and they'd all share a commons.apache.org website. But, as it stands, the resolution implies that the proposed PMC will be excluded to Java and would own both the top-level Commons project name and the commons.apache.org namespace. Neither remark is addressed. If we are open to a TLP Ruby Commons or DotNet Commons, then we should reflect that openness in the resolution and in the project name. We can't use Java (been there, Sun complained). But we can preserve the Jakarta name, and leave the door open for an top-level Apache XML Commons or a top-level Apache C# Commons. So why not the Apache Jakarta Commons Project? Or, if we intend that this PMC provide oversight for components in other languages later, then we should strike the word Java from the resolution now, and clarify our intent. Time is not of the essence, and I believe we should define the scope of the PMC and the commons.apache.org host name and namespace now, rather than create FUD later. It took five hundred email messages to create the commons in the first place, and we can spare a few more to get the TLP resolution right. My suggestion is to * amend the Project name to Apache Jakarta Commons PMC. and setup shop as commons.apache.org/jakarta Let the focus of this PMC remain on Java, but, in the Apache spirit of openness and collaboration, make way for other Apache Commons projects in other languages. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Commons moving to TLP
It would be nice if the proposal allowed for some flexibility as to language. We do have several ASF products written in C#, and the notion of starting a C# commons has come up a couple of times in discussions between open source C# developers. -Ted. On 5/8/07, Henri Yandell [EMAIL PROTECTED] wrote: Sadly a bit too late to make the next board meeting I suspect. However, here's a vote for Commons to officially request that it move to TLP. http://wiki.apache.org/jakarta-commons/TLPResolution Please add your name if you're a Commons developer and haven't added your name yet. [ ] +1 I support the proposal [ ] +0 I don't care [ ] -1 I'm opposed to the proposal because... Voting will close in one week. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do projects use SVN to manage site documentation updates?
The simple answer is that most of us have handled documentation in the same way as we handle the code. We don't patch tagged code once it is released, and we wouldn't patch the tagged version of documentation either. Most often, the website represents the HEAD, so we fix the HEAD, and upload the latest and greatest version. Though, that's been an ongoing question: Should the website represent the HEAD or the latest GA release? The best answer is: Both. Each project (or Jakarta subproject) should a segment of its website intended for the general public. This site would host the GA release of the documentation, warts and all, just like it were burned into a CD. (If you want to fix a serious documentation bug, cut a new release, just as you would with code.) Another segment of the site, intended for the development group, can host the latest and greatest version of the documentation. But, it should be separate and distinct from the GA/General public area. For example, at Struts, we link to the latest GA release of the documentation first * http://struts.apache.org/2.0.6/ But, we also host the HEAD version in the development area of the website * http://struts.apache.org/2.x/index.html On the site, we label the link the Struts 2.x draft docs. The draft/head link stays the same, but each time we issue a new public release (GA or beta), we create an archive folder for that release's documentation. * http://struts.apache.org/downloads.html#PriorReleases Problems with the documentation aside, a common problem is that people try to use a feature that's part of a later release, so we keep the documentation for all the releases handy, so that people can refer to the correct feature set. - HTH, Ted http://www.husted.com/ted/blog/ On 4/21/07, sebb [EMAIL PROTECTED] wrote: How do projects use SVN to manage site documentation updates for exisiting releases? When a new release is created, the site documentation and source files etc will all be in an SVN tag directory. I assume that the SVN tags should never be updated once created, so if problems are subsequently found in the site documentation, and it needs to be updated, what is a recommended way to do this in SVN? S/// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Differences
On Wed, 14 Jan 2004 09:00:31 -0500, Andrew C. Oliver wrote: I understand why you came here to ask this, but its not really a good place to ask (its more of an administrative list). You'd be better going and asking each of the projects (who will probably send you links to their website). Generally these messages devolve into flamebait because each project feels very passionate about their approach (enough to devote real time to developing it in fact) so asking them all in a room together what's the difference is well...often not pretty. Actually, this used to be the place where people could ask questions like this, and chat about everything under the Java sun. A while back, we co-opted the General list for use as the PMC public list. And subscribes to General have been falling every since. Less than a third of what they once were. Perhaps once most of the Committers are on the PMC list, we can move the administrative nonsense there again, and let the General list be the General list again :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Differences
On Wed, 14 Jan 2004 09:00:31 -0500, Andrew C. Oliver wrote: Yes struts can use things that aren't JSP but is not OPTIMAL for that. Thanks to the Velocity Tools, http://jakarta.apache.org/velocity/tools/index.html many people, including myself, find Struts and Velocity to be an optimal combination. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Decision Needed Regarding Wiki
On Thu, 08 Jan 2004 19:12:39 -0500, Noel J. Bergman wrote: As I noted, we have two different PMC members each expressing an opposing viewpoints: - The wikis can be changed by anybody, not just committers, and so we have a more urgent need to keep many eyes on them, which might not be done by a less active project with its own Wiki. A single list provides oversight. - Having content changes for all projects go to a central list is not a good solution because people don't want noise that doesn't relate to their microcosm. We just need to resolve this issue. Honestly, I don't really care, but other people have expressed opposing views. Geir is proposing that *IF POSSIBLE*, there could be one Wiki with multiple lists based upon a URL convention, but that doesn't appear to be available today, and implies that he's happy with multiple lists. --- Noel The situation is not so different than Bugzilla. Anybody can post to Bugzilla too. Committers and PMC Members need to review the Bugzilla reports, and CVS changes, just as we should review the wiki changes. Right now, Bugzilla and the CVS modules, and the DEV lists to which they report, are all aligned along subproject lines. So, there being no other clear consensus, I would say we should do with the wiki what we do with everything else: Align the wikis with subprojects and send the reports to each subproject's DEV list. Since it is not uncommon for a Jakarta subproject to eventually graduate to a top level project, it might be best if we did not bother to nest the wiki's under a Jakarta level, since I believe the content may be harder to shift than a mailing list or CVS module. So, the simplest solution seems to be Allow wiki.apache.org/$subproject Notification: [EMAIL PROTECTED] Here's my +1 If it helped, I'd be happy to migrate by hand what Struts wiki content we have. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
- Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 16:05:11 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ I never understand why you keep doing this. There is no 'schism' between the PMC and the community, and no one is proposing it. I hate to appeal to authority because the ASF charter does provide a healthy bit of freedom for any given PMC, but for example, if we want to follow the model of the httpd project, from which the ASF bylaws were fashioned, and I know you are a vocal proponent of the 'ASF Way', it is my understanding they invite committers onto the PMC after some time after receiving committership when it's clear that is appropriate for that person. Committing != oversight. There are people who are committers that may not wish to participate on the PMC. We want everyone to, but if they aren't *interested* in doing it, putting them on the PMC achieves nothing, and actually, IMO, weakens the PMC. There are all sorts of valid reasons to not want to be on the PMC, I suppose, and we should never stop inviting that person. 100% should be the goal, not the requirement. The schism is that the PMC did not elect our committers. In the normal course, the body that elects the committers also decides which committers (or other interested parties) merit inclusion in the PMC. However, Jakarta has not done things in the normal course. The PMC did not select most of the committers: the subproject communities did. And when our community selected the committers they expected that these individuals would be the ones actively managing the codebase. The community expected these individuals to have the rights and responsibilities we now abscribe only to the PMC. I believe from the ASF perspective committing==voting and committing==oversight Every time a committer commits, they vote for the code they commit. Most often, it a vote subject to lazy consensus, and in rare cases it might not be binding. But, it is vote nonetheless. Every time a committer commits, they either donate code to the ASF or facilitate a donation, and they incur the obligation to ensure, to the best of their ability, that this is IP that can be donated to the ASF. If we have a committer that does not accept these obligations, then a misunderstanding has occurred, and such committers should step down. The ASF does not grant write-access lightly. I think people understand that. In the normal course, virtually all ASF committers are PMC members, because its the committers make the decisions and do the work. It is true that on occasion an ASF committer will not yet be member of the project PMC. Their votes may not be binding, and their commits will be scrutinized by PMC members (which is to say other members of the development team). But, in due course, the PMC that made them a committer also makes them a member. When our community elected all of our committers, it was with the understanding that they were the ones with binding votes, that they were the decision makers, that the Jakarta Committers were, in practice, the Jakarta PMC. In my humble opinion, it is the duty of the PMC to now ratify the decisions our community has already made. Since we now know that the PMC is *not* a steering committee and is in fact the active managers of the codebase, we are obligated to finish the job our community started: give the committers the legal rights and responsibility that we always believed they already had. Make the committers the PMC, because they are the only true PMC that we have ever had. Each and every one of our committers have earned their stripe. They have all proven to the community that they are thoughtful, responsible self-starters capable of managing our codebase on the community's behalf. These are the individuals that have been creating, maintaining and releasing the products we all cherish. These are the individuals that have been doing the true work of the PMC. Where things have gone wrong, they have gone wrong because we were still using a bootstrap PMC that excluded all but a few of our decision makers. I'm sure that there are Jakarta committers that would be unwilling to serve on a bootstrap PMC, but serving on a true, inclusive PMC may be a different matter. Right now, the only plan seems to be to nominate committers one-by-one on the PMC list. I'm just saying that we shouldn't play favorites. I believe all Jakarta committers have already earned membership in the PMC; we should tender the offer to every Jakarta committer and let each decision-maker decide for himself or herself. If the consensus is that the bootstrap PMC will continue to hand-pick which of our duly-elected committers are promoted to the PMC, and which are not, then so be it. But, personally, I think that process is nothing but busy work. The community
Re: [PROPOSAL] Proactively encourage TLP status
- Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 16:05:11 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ Because the PMC would consist of those doing the active management (i.e. the active, interested committers) , we have things covered. All active committers should be interested or else they wouldn't be active committers. Oversight is not some otherwordly task to be conducted by an elite subset of our committers. IP oversight is something *every* decision-maker should be thinking about *every* time they commit a line of code. Consensus oversight is something *every* decision-maker should be thinking about *every* time they post to the DEV list. If committers aren't thinking about this now, it's only because they have no reporting requirements to remind them. Our community has already decided who its decision-makers should be: the committers. The Jakarta PMC doesn't need to second-guess the Jakarta community. We simply need to ratify the choices the community, in its wisdom, has already made. Moving forward, we may want to distinguish between newbie committers and the silver-haired PMC members. But, as it stands, when each of these committers were selected, they were selected to be *the* decision-makers. They were selected to do what the PMC does: actively manage the codebase. We should trust the judgment of our community, let each committer decide for themselves, and then Jakarta be whatever Jakarta wants to be. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
- Original message From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 12:12:29 -0800 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ Ted, Stephen - you are free to propose or encourage any subproject to do whatever you want - but please make clear that this is your personal opinion or proposal ( unless jakarta PMC or the board votes on this ). But please start with the projects you are dirrectly involved with :-) - I don't think it's a good practice to act as a parent for childs you don't know very well. In Struts, we are discussing the TLP issue, http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg20416.html but tabled the discussion pending the 1.2.0 release ... which is where I'll be spending most of my volunteer time again. If Struts does graduate to a TLP, I would update the wiki page based on our own experience (if someone doesn't beat me to it) and post a link to all the DEV lists. (Unless, of course, the growing consensus changes and the PMC decides to do such a thing itself.) As mentioned, my core concern is that everyone concerned has been given due notice of the disconnect between the original Jakarta guidelines and the status quo. As one of the early PMC members, I am partially responsible for that disconnect and need to discharge my own responsibilities to the community. As for the rest of it, I've said my piece, and I'm happy to let Darwin and Consensus decide. Thanks for all the fish. :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Indemnification of the PMC
- Original message From: Danny Angus [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sat, 27 Dec 2003 22:58:55 + Subject: RE: Indemnification of the PMC Seems to me that part of the reason it is difficult to resolve the issues confronting Jakarta is that several initial assumptions are required, and that these are not stated or clearly implied anywhere. Greg assures us that the board aren't likely to act precipitately (if thats how you spell it), and we haven't had official communications from The Members of The Board on the topic, yet there are a lot of hints about the unsuitability of Jakarta's present organisation. I think we could do with some concrete direction, or at least an affirmation of our mandate to continue what we are currently doing. Because to me it is increasingly feeling like we're trying to fix something which (apart from a few details like the bylaws) isn't broken on the basis of speculation and conjecture, and the danger in that is obvious, we'll end up breaking the thing we're trying to fix, or failing to fix the parts which are broken. And with the utmost respect for Sam hopefully that is something a new Chairman, with more time and fresh enthusiasm for the role, will be able to provide. Well, first, the idea of consensus is at the core of the Apache culture. Consensus means that everyone involved has agreed that a course of action is the best available. It may not be everyone's first choice, but it is a solution everyone can live with. Consensus is not something that is easy to represent in a list of rules and procedures. It's a process of human engineering and difficult to reduce to writing. It would even be harder to reduce to writing for every community. Communities are like all other human relationship. Each one is a little bit difference, and, in human terms, the little differences can mean a lot. Now, with Jakarta, there seems to be a belief that we should be following a deterministic process with definitive procedures. Elsewhere in ASF land, there's a feeling that if you need to call upon a formal procedure (say, by exercising a veto), then consensus has failed. When this happens, many Apaches might feel that the real problem isn't the technical issue underlying the veto, but the consensus issue underlying the *need* to veto. Procedure is a fail-safe. Achieving consensus through discussion is the nominal process. The Apaches on the board don't like to make dictates, since dictates defeat consensus. They are not our bosses as much as they are our colleagues. They want to us to sort this out for ourselves. Because, if we can't sort it out ourselves, then we're not building a community that can endure. Tough love. As for what we are suppose to be doing here, the board has already made two mandates. One in section 6.3 of the bylaws http://apache.org/foundation/bylaws.html and another by resolution http://tinyurl.com/3x6rs. The PMC is responsible for the active management of the Jakarta codebase. Part of good management is effective oversight http://tinyurl.com/2eyvg, which is to say solving little problems before they become big problems. We know oversight is failing because we've had to take some drastic measures over the years. One subproject could not resolve an issue, either through consensus or by following the voting process. As a result, a committer lost his write access. By Apache standards, having to do such a thing is a red-letter scandal. Consensus oversight failed. We've also had to temporarily restrict access to CVS modules because of unresolved IP issues. All the issues were resolvable and should have been resolved *proactively* rather than *reactively*. IP oversight failed. There is no doubt that the Jakarta subprojects are healthy. Every project has its hiccups, and Jakarta is no exception. But, we seem to lack a mechanism that allows issues of consensus and IP to come to to forefront *before* it is too late. The infrastructure club is our final fail-save, employed as a last, desperate measure. Denying access to resources is a black-mark that screams oversight has failed. It's not an oh well that we can sweep under the rug and forget about. Other ASF projects have fewer lines of code to worry about, and most, or all, of the committers are on the PMC. If a committer/member has a problem, he or she can bring it up directly on the PMC list, without having to find an intermediary or post a sensitive observation on a public list. IMHO, we need to put aside the maverick guidelines posted at Jakarta and just try to do things the ASF Way. * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. If anyone reading this message agrees,
RE: [PROPOSAL] Proactively encourage TLP status
+1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were (draft 2)
-PROPOSITION (1)- * Require all Jakarta products (or subprojects) to file regular reports with the PMC. You mean 'make each subproject work like a TLP' don't you? Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasise how broken this process is? -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. -- I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes nothing of significance. Stephen - 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] As it ever were (draft 2)
- Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:16:26 + Subject: Re: [PROPOSAL] As it ever were (draft 2) Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasize how broken this process is? Not that I see. It formalizes what should have been done from the beginning. We tried to do it before, but we then run into the politics of whether the person making the report is the PMC representative to the subproject. The fundamental disconnect is that all of the committers should be on the PMC, because all of the committers are the decision-makers for one or more of our various products. -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. No. We are instituting a minimum threshold meritocracy for each product. The PMC members/committers who are working on a product, and interested in its development, and the ones who make the decisions about that product. That's how it works now socially, and that's how it should work legally. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. As it stands today, any of the current PMC members could do exactly that. And, this is also how it works in the Commons today. If I want to chime in on a product and start committing, other volunteers are happy for the help. If you did subscribe to the Struts list and took an interest in the product, I'm sure we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your stripe. Not by trying to do harm, but by trying to do good. The value of administrative [vote]s on the DEV list are often overrated. A veto must have technical merit to be binding. Malicious vetos are not valid. And, as you know, when someone tried to enforce their own will over the will of the community, the ultimate result (sadly) was a suspension of write access. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. No, the committers to each subproject are committee members. Most Apache projects practice a minimum threshold meritocracy. We don't expect every committer to be involved in every decision, or cast votes or opinion outside their area of interest or expertise. If three committers/members vote +1, we're good to go. The PMC was not meant to be a legislative body: it's suppose to be the core group, the decision-makers, the active managers, the committers. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes nothing of significance. It changes everything. It turns Jakarta from a place that is supposedly governed by an other wordly elite to a place that practice minimum threshold meritocracy -- both socially and legally. Today our social order is out-of-synch with our legal status. This proposal legalizes what already happens in practice. * It provides a forum where ALL the decision makers can discuss oversight (not just a chosen few). AND, * It puts reporting in the lap of the decision-makers for each product, which ensures it stays on the *decision-makers* radar, and is not pushed up to some body that cannot possible oversee our products. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
On Dec 28, 2003, at 8:43 AM, Ted Husted wrote: * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and No, it doesn't. We need to put as many as possible, hopefully all, but it's not required to be all. We can also have people that aren't committers on the PMC. * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. Erm, I'm not so sure that this needs to be legislated like this. If anyone reading this message agrees, or disagrees, please respond to the As it ever were proposal under another thread. Let's see if we can build a consensus and then create and maintain a solution that works. IMHO, the ASF Way *will* work if we let it; we've just never tried to let it. I don't think that anyone is debating if the ASF works. I think we all know it does. I think we disagree what the ASF Way is - I think it simply requires inclusive participation on the PMC of those willing to feel responsible for more than just the code they are working on, namely project direction and oversight. Thus, the PMC does not necessarily mean forced 100% committer participation, although that percentage is the goal, nor does it mandate strict reporting schedules and reporting content and format. I do believe that if we continue on the way already started - ensuring CLAs, putting as many active Jakarta committers on the PMC as are interested, educating them as to their oversight role, then we would be in a much healthier position and able to then grapple with the day-to-day PMC process. Until we achieve the former, the latter is somewhat of a intellectual game. As you like to point out, we all are adults working for the best interest of the organization. Please work with us on this. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - 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] Proactively encourage TLP status
On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
- Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 11:11:07 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. Steve made a proposal I supported, so I demonstrated my support by pitching in. AFAIK, there's no such thing as a personal wiki page (which Steve has already proven). * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I had some time over the holidays myself, so I put together a proposal that reflected how I believe we should proceed. Other people responded to that, so I made some changes and issued another draft. There were other threads that seemed related to that proposal, so I tried to draw them together to see if we could build a consensus. All I've done is make a proposal for the community to review at its leisure. If a consensus were to develop, I'd volunteer to move it along. If not, the kids need shoes ... I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Committers commit. I believe it's something that should be done, so I volunteered to do it. I also mentioned if someone else were ready and willing to do it, I'd be happy to step aside. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... My point is that there is a social and ethical requirement to inform the committers of the status quo. There are many ways in which the points covered on the http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges wiki page conflict with the original guidelines. The only way to ensure everyone is aware of the status quo is for a posting to be made to every DEV list. Since I've served on the PMC, I feel jointly responsible for erroneous information. I don't discharge my responsibilities lightly. I guess all that I'm really asking is that a posting be circulated to each DEV list regarding the proposed changes. As mentioned, I'd be happy to do this myself, or help someone else do it, so long as it was done. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
Mea culpa. I'm trying a new mail client and managed to press the wrong buttons. Sorry for the confusion. -Ted. - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 11:19:04 -0500 Subject: Re: Indemnification of the PMC Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
- Original message From: Stephen McConnell [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sat, 27 Dec 2003 06:48:59 +0100 Subject: Re: Indemnification of the PMC If I understand correctly, the opinions of an individual are not the same as a motion passed by the BOD. It is my understanding the BOD has not passed any resolution that grants a PMC member any of the rights implied by the message quoted below. In fact, my understanding is that the role of PMC implies no rights at all - just extra responsibility. Is there anything concrete to suggest otherwise? The ASF's authority to indemnify individuals stems from Section 12.1 of the ASF bylaws: http://apache.org/foundation/bylaws.html This section provides for indemnification of directors, officers, and members, as well as individuals serving at the request of the corporation The theory is that the PMC Committee members fall under the latter clause. Since, the corporate resolution only installs the PMC (the argument goes), plain-vanilla committers don't fall under section 12.3, since they don't serve at the request of the corporation. Though, section 12.1 does not specify PMC members as such, and so there's some wriggle room there. From a legal standpoint, the safest thing is to be an ASF Member *and* serve on the relevant PMC. (Something more of us ASF Members need to do this year is nominate more Jakarta-bred committers to the ASF.) For those of you with access to the ASF Members list, there's a good post by Roy dated 12-Mar-2003 that sums up the indemnification issues as well as the issues surrounding the role of the PMC. According to the ASF Bylaws and the Jakarta resolution, http://tinyurl.com/3x6rs being on the PMC doesn't grant additional responsibility, it grants *all* the responsibility. While, in practice, the lowly Jakarta committers now handle the active, day-to-day management of the codebase, it is not their responsibility to do so. Personally, I think that this perception that being on the PMC means more work than being a committer is a nonsense. Elsewhere, most or all of the committers are PMC members. Elsewhere, committers who are not a PMC members are the exception rather than the rule. The reason being on the PMC here may seem like more work, is because we are *making* it more work than it should be. Within Jakarta, we've gotten the fallacious idea that the PMC is a steering committee that sets the strategic direction for the project. This idea is not based on the ASF bylaws or the Jakarta resolution. The guidelines altered the role of the PMC years ago, either as a misunderstanding or as an experiment. The bylaws specifically say that the chairman shall establish rules and procedures for the day to day management, which is what our committee spends a lot of time trying to do. As for what the PMC is supposed to be doing, the bylaws state that Each Project Management Committee shall be responsible for the active management of one or more projects. Within Jakarta, we've trying to fill the chairman role with a committee and let the committers take responsibility for the active management of our codebase. (Recently subject to the PMC's rubber stamp.) IMHO, this is why there seems to be a fundamental disconnect between Jakarta and the rest of the ASF. We've reduced the chair to a notetaker, given the PMC the chair's responsibilities, and given the committers the PMC's responsibilities. Jakarta folks and the ASF board folks on not on the same page, and we talk past each other. Here's how Roy Feilding styles the roles: project= something the ASF wants to accomplish, management = making decisions for progress toward a goal, and committee = the people voting on decisions Roy also stated that: The PMC must equal the voters on a given project, or the entire theory of delegated authority, responsibility, and oversight upon which the ASF depends for legal defense of its contributors [is defeated]. The PMCs were based on the Apache Core Group. The PMC is *not* suppose to be some other-worldly land where benevolent beings ponder deep issues and create solutions. The PMC is them that make the real, day-to-day decisions that foster the project's community and create and maintain the project's codebase. At Jakarta, that would be the committers -- ALL the committers. It's possible we might also want to create some type of executive steering committee within Jakarta that could do the sort of stuff the current PMC seems to want to do. But, we cannot usurp the PMC constituted by the ASF for some other role. We must make the PMC what the PMC is intended to be: The committers who make the day-to-day decisions. If we did want to get back to basics, we should start by going back to the HTTPD guidelines, http://httpd.apache.org/dev/guidelines.html and make the minimum number of changes needed to
Re: [PROPOSAL] As it ever were (draft 2)
[PROPOSAL] As it ever were I've incorporated many of the suggestions made on the list and prepared another draft for community review. -ISSUE- The ASF Board has indicated that it does not believe that the Jakarta PMC, in its present form, is capable of providing oversight of all the subprojects under its purview. The role of the Jakarta PMC is two-fold: * The PMC is responsible the active management of the project * The PMC provides oversight for the project -Management- When the board creates a project, it passes a resolution. Resolutions regarding Jakarta have been passed here: http://tinyurl.com/3x6rs and here http://tinyurl.com/2zkdb The board's authority to create Projects and PMCs stems from section 6.3 of the ASF bylaws: http://apache.org/foundation/bylaws.html From a legal perspective, the PMC is the only entity that the board recognizes as being responsible for the management of a project. Only committee members have binding votes. Only committee members would be indemnified by the ASF in the event of a law suit http://tinyurl.com/3eq9c. In fact, most of the rights and responsibilities we at Jakarta have ascribed to committers in fact belong only to PMC members. Originally, we envisioned the PMC to be a steering committee http://tinyurl.com/2o2v5, responsible for the strategic direction and success of the Jakarta Project. But this is *not* the case. The PMC doesn't just set the agenda, it is the body that *actively manages* the project. The PMC has the rights and responsibilities that most of us would ascribe to the subproject committers. -Oversight- As used here, the term oversight follows its dictionary definition: o·ver·sight 1. An unintentional omission or mistake. 2. Watchful care or management; supervision http://tinyurl.com/2eyvg The board expects PMCs to exercise (2) so as to avoid (1). :) All good managers must provide oversight, and a PMC is no exception. For a PMC, oversight boils down to issues of committer consensus and intellectual property. In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions). Jakarta now manages 21 subprojects (with Pluto on the way), and another 40+ components in the Commons and Commons Sandbox, The board's question is How can the Jakarta PMC, as it is now constituted, possibly provide oversight for all of this code?. -CURRENT APPROACH- The PMC has decided to expand its membership to an indefinite number and is actively soliciting nominations of qualified committers. So far, the PMC has rejected the idea of nominating all the committers or any committers who volunteers. Each new nominee must be voted in by the PMC (or not). At this time, no other changes are on the agenda. For additional background, see * http://tinyurl.com/226pt * http://tinyurl.com/2vclu and the archives for the general list * http://tinyurl.com/2gq7d or http://tinyurl.com/3cw3e. -PROPOSED CHANGES- (1) Require all Jakarta products (or subprojects) to file regular reports with the PMC (2) Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc -PROPOSITION (1)- * Require all Jakarta products (or subprojects) to file regular reports with the PMC. A key element of oversight is vigilance. One way to achieve vigilance is regular reporting. Just as the board requires the vice president of a project to file regular reports, the PMC should require each subproject to file a similar report. Here is a format often used by projects reporting to the board: * What code releases have been made? * Legal issues: * Cross-project issues: * Any problems with committers, members, etc? * Plans and expectations for the next period? Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Failure to report would have to be considered a serious matter, possibly leading to blocking CVS access. Accordingly, each subproject would want to be very, very sure these reports are in fact being filed. -PROPOSITION (2)- * Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc The original Jakarta guidelines state that committers have the binding votes and make the decisions regarding the codebase. We now know that, from an ASF perspective, committers have write-access to the codebase, but the PMC members have binding votes and make the decisions. The idea of committers with non-binding votes has been broached many times over the years. Each time, the consensus has been that we vote most with our commits, and that every volunteer committing to a Jakarta codebase is entitled to a binding vote (and veto). Whenever we selected any committer for any Jakarta codebase, we did so with the expectation that they would be responsible for its active management. We were in fact not merely electing committers but PMC
Re: [PROPOSAL] As it ever were
My complaint is this: Our current base of committers were led to believe they have binding votes. We are now told this is not the case. The committers we now have were all elected on the premise that they had binding votes and oversight responsibilities for their codebase. They were in fact elected as if they were to be members of the PMC. Personally, I feel it is an abomination to think we have the right to hand-pick a subset of these committers and bestow upon them binding votes. Our communities deserve to be represented by the set of committers that they have already chosen, not an arbitrary subset deemed to be PMC material. I call for the Jakarta Chair, as the ASF Vice President in charge of Jakarta, to do the Right Thing and promote all Jakarta committers to the Jakarta Project Managemenet Committee. Anything less breaks the covenant we made with each and every Jakarta committer, as published in the original Jakarta guidelines. We said committers had binding votes, and it is now our obligation to make it so. If we fail to make a good faith effort to correct our oversight, then we will have accepted all these contributions under false pretenses. If all committers are PMC members, then all committers can then be subscribed to the PMC list. Each subproject can be given the responsibility of submitting to the PMC list a regular report as to their status. Routine business can be conducted in the subproject DEV list by the PMC members associated with that subproject. In the event there is an unreported oversight issue, any Jakarta Committer/PMC member will be able to bring it up on the PMC list at will. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
I apologize for not quoting. I'm experiencing technical difficulties and making do the best I can. I meant what I said. We must make an immediate, good faith effort to correct the false and misleading information in the Jakarta guidelines, and give all committers due notice of their true status. Otherwise, there's a point where we cross the line. The PMC does not now nor has it ever affirmed each and every decision made by the committers. It may affirm some of the release votes, but there's a lot that goes into making a release. And, AFAIK, the PMC is not authorized to delegate its decision making to non-members. IMHO, we all thought we had the rights and responsibilities of PMC members in the first place. When each and every of these committers were appointed by a subproject, they had the traditional role of a PMC member in mind. Hence, the proposal is to make all Jakarta committers PMC members, which, I believe, was the underlying intent of the original guidelines, and what we all thought was happening in the first place. I reject the idea that being a PMC member brings additional responsibility. All committers are already responsible for decision-making and oversight. We simply need a mechanism that reminds everyone of our existing responsibilities. If all committers are subscribed to the PMC list, and each subproject is given the explicit responsibility for regular reporting, I sincerely believe we will be able to easily dispatch the oversight issues. All we need is a little infrastructure, and the volunteers will take care of the rest. A long-standing principle at Jakarta has always been that the highest, best votes are the commits. We have always rejected the idea of committers without binding votes. To say now that votes are socially binding but not legally binding is inconsistent with community standards. I am happy that we do have communities that will honor the votes of all its committers, whether they are legally binding or not. But, our legalities should reflect the community standards, which are that a committer is a committer. Obviously, if a committer wants to opt-out and become a developer again, that is their choice. But we should not be second-guessing the communities by opting-in committers to the PMC. The community thought they were good enough to have binding votes and binding vetos: who are we to say different? I've proposed my solution: Promote everyone who doesn't opt-out to the PMC; subscribe all committers to the PMC list; require regular reports from each subproject. AFAIK, the only other option on the table is to continue to nominate committers willy-nilly and hope-against-hope that a few more heartbeats will somehow give the PMC the wisdom to make decisions on the subproject's behalf and the mystic ability to oversee all the codebases. I don't think we need to create a Jakarta elite. I think we need to do what we meant to do in the first place: let the committers make the binding decisions. Accordingly, if a positive consensus develops among the committers regarding the original proposal, we can bring it as a vote in the Jakarta way. Otherwise, I would just let the proposal drop, so that the consensus view can proceed. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
(Again, sorry about the quoting.) o·ver·sight 1. An unintentional omission or mistake. 2. Watchful care or management; supervision http://dictionary.reference.com/search?q=oversight The board expects PMCs to exercise (2) so as to avoid (1). :) For a PMC this boils down to issues of committer consensus and intellectual property. In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions). IMHO, if we were to * require subprojects to file regular reports with bullets regarding consensus and oversight, and * subscribe all committers to the PMC list where these reports are filed then we'd be able to defuse these happenstances before they turn into incidents. IMHO, the one and only set of individuals that can provide watchful care over a codebase is the set of committers we already have for each subproject. IMHO, each and every committer to a Jakarta subproject has already passed through a gauntlet that proves they are PMC material and entitled to binding votes. All we need to do is complete the process that promotes our committers to PMC members with binding votes, as our original guidelines contemplated, and require subprojects to provide regular status reports. (Just as the board requires our project to report.) As both Roy and Greg have said, if the Jakarta committers truly understood how few rights and privileges they have, they would be demanding both ASF and PMC membership. Few do, so few have. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
steward The proposal is to expand the role of the moderator, rather than invent an overlapping role with similar responsibilities. If the volunteer is not up to task, then another volunteer can be sought. (Hence, the language about the Chair appointing another volunteer.) The idea is that they have *already* volunteered to moderate the list. If one individual doesn't want to volunteer, another can be found. delegate The proposal does not delegate the board's responsibility. To be binding, anything voted on any DEV list would still need the a 3+ quorum of PMC members. PMC members would be voting on PMC business. There is nothing anywhere that says all the PMC business has to take place on a single list. If PMC members want to subscribe to all the lists and monitor all the PMC business, that's their choice. Conversely, if PMC members want to abstain from the routine business surrounding a given codebase, they don't have to subscribe to that DEV list. Meanwhile, through the steward's reports, the committee-at-large is being kept in the loop as to each subproject's big picture. The proposal does the things. * It realizes the fact that Jakarta doesn't have non-binding committers (meaning that all committers must become PMC members). * It provides a clear mechanism for scoping the work of the PMC. The business of each subproject can be conducted by people who are in-touch with that subproject on that subproject's DEV list. * It provides a clear channel for oversight. The steward's reports are designed to ensure that someone is at least thinking about these matters on a regular basis. Since it's someone's role to report on these things, they are more likely to be reported. Some issues we had in the past would not be readily addressed, since all the committers will be on the PMC list. A PMC member won't have to go off and talk to a subproject and report back. The subproject committers can hash issues out on the PMC list, where other members can provide input. And, any committer/PMC-member who thought there *might* be a problem, can now bring it up directly on the PMC list, whether the steward brings it up or not. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Make release managers the default stewards Not every subproject has a clearly defined release manager. In Struts, we are even starting to have multiple people collaborate on the release manager role. The key to oversight is persistence. Since it is not possible for every committee member to be personally aware of what's happening in every subproject, we need regular reports from someone who does -- just as the board needs regular reports from each chair. We don't need for subprojects to have a chair, but we do need someone to tender regular reports as to the subproject's status. The keyword being regular. The person making these reports should already have a working knowledge of the subproject and be able to report based on what they already know. Of course, what they know is based on reading and understanding the traffic on the lists. Ideally, the DEV list moderator should also be someone who is plugged into the subproject. So, instead of starting out by creating two roles with overlapping responsibilities, I'm suggesting we try extending the list moderator's role first. List moderator is the only persistent role that must already exist for each subproject's DEV list. In some cases, we may need to have different volunteers fulfilling each role. But, personally, I like to try making do with what we have before running out and creating something new. I also don't want to get bogged down with finding a steward for each subproject. The DEV list moderators are there, so let's use them. If a list moderator doesn't want to steward, then I'm sure they can find someone who does. Hey, we all friends here. :) The key point is that the chair, and its PMC, need consistent, reliable reports, so that the chair can report in turn to the board. We need each subproject to fulfill the responsibility of regular reporting by whatever means necessary. We also need to push that responsibility down to the subproject. The people working in the subproject are the only ones truly aware of its status. Should we encourage subprojects to elect a steward? No. AFAIK, we don't elect roles like list moderator or release manager. People just step up and offer to do the job -- as it should be. But if a subproject wants to a elect a steward, or a list moderator, or a release manager. that's their business. All we need is for the job to get done. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] As it ever were
Re: Proposal to grandfather Active Committers to Jakarta subprojects as PMC Members. As it stands, most Jakarta committers have assumed that they already have the rights, privileges, and responsibilities granted PMC members. (Mainly because it was written that way in the Jakarta bylaws). When all these committers were elected, it was with the understanding they had binding votes and oversight responsibility, as stated by the original Jakarta bylaws. It could be said that we have been electing PMC members, rather than only committers, all along, without realizing it. Following our original bylaws and practices, there is no such thing as a committer without the rights and responsibilities of PMC membership. Accordingly, a stipulation of becoming (or remaining) a committer to a Jakarta subproject can said to be PMC membership, as it is described by the ASF bylaws. To complete the process we've already begun, I suggest a [VOTE] be brought on each [EMAIL PROTECTED] list to nominate the list of its active committers to the PMC. This vote will also serve as notice to committers who wish to opt-out. To bootstrap the process, the current moderator of each DEV list can be asked to bring the vote and report the result. If necessary, a new moderator can be installed by the Chair. The moderator of each dev list will also act as the PMC steward for the subproject. The list moderator is suggested since that individual is already suppose to be monitoring the list where this activity occurs. The steward will have the responsibility of immediately reporting any new committers/PMC members elected to a subproject, so that they can be affirmed by the chair and notice given the board. All PMC members (which is to say all active committers to jakarta-* CVS repositories) will be subscribed to the PMC list, which will be a required list for PMC membership, like [EMAIL PROTECTED] The PMC business for each subproject will continue to take place on its own dev list. The steward for each project will report to the [EMAIL PROTECTED] list the status of his or her subproject, covering such points as: * What code releases have been made? * Legal issues: * Cross-project issues: * Any problems with committers, members, etc? * Plans and expectations for the next period? The chair can then summarize these reports for presentation to the board. Effectively, each dev list becomes a sub-committee of the PMC. (Divide and conquer.) The list moderator/steward becomes the subcommittee's secretary, with the additional responsibility of summarizing the result of our ongoing meetings. As appropriate, the steward or any PMC member can bring up oversight issues to the PMC list. Routine matters, such as releases, can be approved by the PMC members who are committers to a given subproject. So long as the usual 3+ quorum is met, there would be no reason to bring routine votes before the [EMAIL PROTECTED] list. Of course, the result would be tabulated on the steward's report, which *is* published to the [EMAIL PROTECTED] list. -Ted. Pro-forma [VOTE] It has come to our attention that the Committers to a Jakarta subproject must also be members of the Jakarta Project Management Committee to have binding votes. To complete the legal process, the current PMC is asking each subproject to nominate it's active committers to the PMC. Since we have never supported the idea of non-voting committers at Jakarta, and only PMC members have binding votes, if a committer is unwilling to serve on the Jakarta PMC, we will be unable to continue to extend write access to any jakarta-* CVS to that individual. Each PMC member will also be subscribed to the Jakarta PMC list. *However, all subproject business can continue to occur on this DEV list as always!* In the future, we anticipate that the PMC list will be very low-volume. (Really, we do!) The only change is that the owner of the DEV list must also serve as the PMC steward for the subproject. The steward must submit monthly status reports for the project and immediately report any new Committers to the PMC list. But, other than that, it will be business as usual. Accordingly, we ask that the Committers to this subproject nominate the following individuals to the Jakarta PMC. Please check all that apply. [ ] $committer Any committer who wishes to opt-out may notify the Jakarta chair ([EMAIL PROTECTED]). If you opt-out, regardless of the vote, you will not be subscribed to the PMC list, and your write access to jakarta CVS repositories will be removed. (Sorry, but it's part of the package now.) ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Geir Magnusson Jr. wrote: I'd say it the other way around. The ASF is a collection of communities that create and maintain codebases. To obtain infrastructure support and some legal protection, these communities donate the copyright of its software and ownership of its brand to the Foundation. In order to provide legal protection and watchdog its copyright, the board assigns a vice president to oversee the project. A committee is also convened to assist the VP with oversight. I think this is mostly right, and I say mostly because it's legally precise, but in practice, the community tends to be there first, rather than be convened later, Yes, that's what it says. A collection of communities that ... *not* a collection of codebases. [SNIP] A very subtle concept is that the ASF doesn't actually own the codebase. The codebase belongs to its community, and under the Apache License, that community can always vote with its feet. Since it is the community that gives the software its value (by using and maintaining it), there is an Apache belief that the community is the true owner of the codebase. The ASF just owns the brand and yesterday's copyright. I believe that this isn't right - the ASF does own the codebase via the copyright, and the codebase is licensed at no cost to any entity that is willing to agree to the terms of the license. That entity, community or otherwise, cannot remove that license or change it unilaterally. It owns a static image of the codebase, but from an Apache perspective, a codebase is a living, growing thing with a lifecycle that can endure for decades. The point is that without a community, even if it is a stable community of users helping users, the codebase has no value, and there is nothing *worth* owing. The board may sometimes disagree with a dysfunctional PMC, for the good of the community, but I don't believe the board would ever deliberately act against the community. The point of the exercise is to create communities around codebases, which means the community always comes first. (Else, there is no reason to have the codebase to begin with.) The essential difference between SourceForge and Apache is that SourceForge is just about sharing code. Apache is about building communities around the code we share. The reason a true community (in the Apache sense of the word) has never coalesced around Jakarta is that the subprojects were too coarsely grained to share code. So, we invented the Commons. The difference between Jakarta and Jakarta Commons is that the Commons has codebases that are *designed* to be shared with a community of developers and users. The truly marvelous thing about Jakarta Commons is that its communities transcend Jakarta. Everywhere I go in open-source land these days, I find other projects importing packages from the Commons. Thus, our license and style of management is exposed, and fresh blood is drawn into the Apache community, so that the cycle of life can continue. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Santiago Gala wrote: [SNIP] This implies that those having easier ability or will to maintain the product are the effective owners of it. as in a rapidly changing environment, software rot takes care of static code bases. Exactly. There is a saying from Dune: Whoever has the power to destroy a thing, owns that thing. (The case in point being melange.) The community has the power to effectively destroy the ASF's codebase by defecting and reforming elsewhere, leaving the ASF project dormant. Conversely, the ASF cannot destroy the codebase, since the community can just set up shop somewhere else under a new brand. Meanwhile, the ASF cannot create or maintain the codebase itself, since it has neither the resources nor the will. So, while the static copyright and the brand belong to the ASF, the living codebase belongs to the community that supports it. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta: Confederation or Single Project?
Michael Davey wrote: Jakarta is the *brand*. It defines itself. Jakarta brand development. A brand can give a unique identity and grouping to an otherwise disparate and commodity range of goods and services. Apache is a brand too, and, IMHO, a much stronger brand than Jakarta. I believe Jakarta distracts people from the fact that everything we do here is on behalf of the Apache Software Foundation. We are not Jakarta Committers, we are Apache Committers. We use the Apache License, package our product for apache.org, check code into cvs.apache.org, and donate every line to the Apache Software Foundation. I realize that there are people who have romantic notions about Jakarta and like to talk about preserving Jakarta for Jakarta's sake. But for the life of me, I can't see why. For me, it's always been about the codebase and its community. If a product I use is hosted at SourceForge, I work at SourceForge. If it's hosted at Jakarta, I work at Jakarta. If it's a top-level ASF project, then I work there. I go where my community lives; and my community is centered on a codebase, not a hostname. There are people who have called Jakarta a jewel. I'd agree that Cactus is a jewel, as is Lucene, and Velocity, and all the other *communities* we've built around our codebases. But Jakarta is not the jewel, at best it's a jewelry box. All along, there have been people who envisioned a Jakarta community. But, what's the point of that, really? We already have the Apache community and the open source community. Why do we need another community within a community? What's the point of another layer of indirection? In my experience, if you make a significant contribution to any open source codebase anywhere, its community will welcome you with open arms. We don't need hostnames to create communities. People create their own communities and forge their own relationships, by the simple virtue of their contributions. And look what's happening with logging: Now that it's a TLP, they are bringing-in the various Log4J compatibles. Now, there can be one Apache logging project serving every platform. That's community-building! The real, underlying issue with Jakarta is that most of our products are *not* about Java. They are about a feature set. Java was just a convenient implementation language, but most of our products could be implemented in other languages and made available to a broader community. In fact, many have, but since they are not Java implementations, we have multiple communities around a product instead of one. A language-centric project like Jakarta doesn't create community, it dilutes it. But I would not say that Jakarta is broken. I'd say Jakarta is finally starting to work. The proof that Jakarta is working is that products are finally growing up and becoming projects. Every worthy parent's goal is self-sustaining children. The Foundation, like a good parent, has always tried to build self-sustaining projects -- projects that can outlive their creators. I'm happy that some of these projects were born at Jakarta and became great enough to join our top-level peers. So, why are Ant, Maven, Logging, Slide, et al, graduating to top-level Apache projects: because they can :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Choosing against Jakarta
No worries, mate. The Apache License is the ultimate hedge. No matter what happens, you can always set up the source someplace else. The most you could possibly lose would be the product name, and, realistically, if there wasn't a community behind the product, Apache wouldn't want it anyway :) As an Apache Committer, you can setup a product in the Jakarta Commons sandbox whenever you want. (Just like SourceForge.) If you can interest other people in the product, and build a community to support it, the product can be promoted to the Commons Proper -- or even to the top-level of Jakarta or the ASF, depending on the product's extent. The thing to keep in mind is that you are not donating code to Jakarta. You are donating it to the Apache Software Foundation. The ASF is here to stay, as are all of its products, no matter where they are hosted. As long as a product has a vital, meritocratic community, it's sure to have a home at the ASF. Of course, SourceForge is also a fine place to host a project. I often choose SourceForge when the people I'm working with are not ASF Committers. This in itself is a good reason to choose SourceForge: you can't add ASF Committers at will. ASF Committers must have demonstrated a sustained interest in the project and an understanding of the Apache Way. Usually this is a good thing, but sometimes it is not. As far as anything else goes: This too shall pass, but open source and the Apache License endure. -Ted. Stephen Colebourne wrote: As some of you may know, I look after my own date and time code in Java at www.joda.org. I had been hoping to bring this code to Apache, as I believe it to be a very good fit with developments within Jakarta/Jakarta-commons. Today I decided not to pursue this option for the time being, until the situation with Jakarta's future is resolved. Instead I applied for a new sourceforge project to house it more cleanly. Why post this here? Because I believe that others may also be questioning the value of Jakarta. I confess that I have no idea what, or if, Jakarta will look like in 6 months time. Certainly it made no sense to me to attempt to get a new project adopted by Jakarta at the moment. Stephen - 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: Why you *want* to be on the PMC
To do this, each product would simply need to draft a resolution to create the PMC and select a chair, and ask that it be placed on the board's agenda for the next meeting, just as Log4J and the others did. It would be very important that each product do this themselves, to help show they are ready for self-management. Essentially, each product would still be a TLP, but would just be hosted at Jakarta. This option has always been available, it's just that every product since Ant has chosen to have their own hostname and website. It's also important to remember that some of these products, like Log4J, are not just about Java anymore. The Apache Logging project will have compatible codebases available for half-a-dozen platforms. (Now *that's* community building!) -Ted. Dirk Verbeeck wrote: +1 If this is acceptable by the board then it's the ideal solution. No changes to the email/website structure, jakarta remains the center of the apache java development with a shared announcement list, general list, news and download pages, ... The only change is that the board gets a list of members overseeing each project (=PMC) and additionally a Jakarta Community project building a java community at Apache. (assisting the java projects) The board will not get one big report from jakarta but many small ones and can see witch (sub)projects needs more members. Of course many members will be joining multiple PMCs. Is this possible? -- Dirk Noel J. Bergman wrote: There is a difference between a hierarchy and a confederation. There is absolutely nothing that says that we cannot have: Jakarta PMC: responsible for jakarta-site/jakarta-site2 Tomcat PMC: tomcat and related code Struts PMC: struts and related code Jakarta Commons PMC: ... Tapestry PMC: ... ... All without a single change to the Jakarta domain. No one should feel that there is any relationship between the Foundation's legal structure, and e-mail/web addresses. We have had this confirmed already by both Greg and Sam. The above *is* an acceptable solution to the Board. The question is whether or not it is an acceptable one to us. --- Noel - 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: POI Logo legal matter
I'd ask if the contributor could remove the diamond look so that it looks more like steam and less like the Windows flag, then see if we need to run it by counsel. The cup part seems like a stretch to me too, since it is a very different looking cup. But the diamond pattern does seem a bit too close for comfort. Andrew C. Oliver wrote: Hi All, The committers are about to be asked to vote on the new POI logo. While the recent user logo poll was not binding (as only committer votes are binding), I expect the majority of committers may cast their vote democratically. Unfortunately, the logo that has won the poll is controversial. Had I seen the Windows XP logo (I use Linux and sometimes w2k due to work/cross browser testing, but I always shower afterwards), I probably would have nixed this one. However, my opinion is but that of a lay person. From my understanding the foundation employs council that is available, however not being a member of the foundation, I'd like to solicit the assistance of a foundation member to bring this issue to the foundation or said legal council. I've been told that the logo is potentially a problem: a. because it looks too much like the windows xp logo b. because it employs a coffee cup (which I think is unlikely) and therefore would peeve sun too. I'd like to ask the legal reprentative to look at: http://jakarta.apache.org/poi/news/images/logoRaPiGmbH8.png results: http://vote.sparklit.com/poll.spark/640946 and tell us whether this logo is likely a trademark infringement on either issue. In the event it is, we'll not submit it to the POI committers as a candidate. Thanks, Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: process of OSS development at jakarta
Leo Simons wrote: If y'all could comment and perhaps expand a bit, I'll put a webpage somewhere. Or, if I missed the mark completely, I'll do nothing =) How about tieing that page in with the outline we started here: http://jakarta.apache.org/site/guides -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [DRAFT2] Jakarta Newsletter - June 2002
I add a /news directory and the first edition to the site2 CVS. So on the website this would be under jakarta.apache.org/site/news. But I don't know how to get the web site to checkout the new folder. cvs update ignored it. I tried creating a news directory but that didn't help. If someone can set up the website to checkout the new directory, the rest is done. -Ted. Rob Oxspring wrote: Please find attached the xdoc/html/txt versions of the the second draft (zipped). The changes: oNew sections for Jetspeed, Lucene, and Tomcat oMentions actual release of JXPath not just talk of oCeki's name is now in its full glory, as is Mike McAngus's oSwitched Mahler Thomas to Thomas Mahler Do people want the html version? if so, we could do with finalising the location and someone committing the xdoc before I send the final copy out to the wide world. If we can decide this matter and there are no more changes / submissions then I'll send this copy out tomorrow. So again - let me know of any changes you think are necessary. Rob Name: draft2.zip draft2.zipType: Zip Compressed Data (application/x-zip-compressed) Encoding: base64 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [DRAFT2] Jakarta Newsletter - June 2002
Thanks, Danny. (Been using a GUI too long =:0) A draft archive page is now up at http://jakarta.apache.org/site/news/ Once this ships, I'm thinking we could add a Newsletter section at the top of the welcome page [Jakarta Newsletter] * June 2002 [Product News] * ... And change from June to July when the time comes. We could also change the default News Status page to a portal that links to the pages we have now have for * Newsletter archive * Product News * Other Jakarta News * Elsewhere and get all this moved under the new /news folder. Sound like a plan? -T. Danny Angus wrote: cvs up -d -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: 02 July 2002 13:34 To: Jakarta General List Subject: Re: [DRAFT2] Jakarta Newsletter - June 2002 I add a /news directory and the first edition to the site2 CVS. So on the website this would be under jakarta.apache.org/site/news. But I don't know how to get the web site to checkout the new folder. cvs update ignored it. I tried creating a news directory but that didn't help. If someone can set up the website to checkout the new directory, the rest is done. -Ted. Rob Oxspring wrote: Please find attached the xdoc/html/txt versions of the the second draft (zipped). The changes: oNew sections for Jetspeed, Lucene, and Tomcat oMentions actual release of JXPath not just talk of oCeki's name is now in its full glory, as is Mike McAngus's oSwitched Mahler Thomas to Thomas Mahler Do people want the html version? if so, we could do with finalising the location and someone committing the xdoc before I send the final copy out to the wide world. If we can decide this matter and there are no more changes / submissions then I'll send this copy out tomorrow. So again - let me know of any changes you think are necessary. Rob Name: draft2.zip draft2.zipType: Zip Compressed Data (application/x-zip-compressed) Encoding: base64 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FW: Third-Party Support
Done. Pier Fumagalli wrote: Not acked... Pier -- Forwarded Message From: Alex McLintock [EMAIL PROTECTED] Date: Sun, 30 Jun 2002 21:50:28 +0100 To: [EMAIL PROTECTED] Subject: Third-Party Support Please add my firm to the page http://jakarta.apache.org/site/vendors.html We would like to be in the Complete solution providers section. Please can our entry read OpenWeb Analysts Ltd http://www.owal.co.uk OpenWeb Analysts Ltd solves problems through software. We specialise in making the most of Open Source software in web situations. Whether that is working with a perl based content management system, or writing Java code for an XML/XSLT based document generation system, OpenWeb Analysts has the skills. London, UK info at OWAL.co.uk Thanks Alex McLintock Openweb Analysts Ltd, London: Software For Complex Websites http://www.OWAL.co.uk/ Free Consultancy for London Companies thinking of Open Source Software. -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Newsletter - May 2002
+1 on no biding peer review But the sequence of events Pier suggested seems fine (1) The volunteer list editors post submissions to the general list and copy their own DEV list. [NEWS] July 2002 - Struts copy/ (2) The volunteer newsletter editor collects the submissions together and sends it out on announcements like a digest. If there were comments, it would be up to the newsletter editor that month to decide whether to commit them to the newsletter or not; perhaps consulting with the committers for the product first. -Ted. Peter Donald wrote: I would actually prefer no peer review (or at least no binding peer review). If people want to have a say what goes into it then they should get off their butts and write something for it ;) I am sure that the writers will be at responsible enough (and if not we can yank their privlidges to post it to announcement list) At 04:19 PM 6/5/2002 +0100, you wrote: Rob Oxspring [EMAIL PROTECTED] wrote: Jakarta Newsletter == Issue: 0 Date: May 2002 Great job... I'd like to propose the following: peer review on this mailing list, vote request, and then send it off on announcements... This can be done every month if Rob is willing to keep up with the pace of my flamewars. Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
I think the real point is that while, given the chance, some people may prefer to do one thing or another, as Committers we all can potentially do anything that needs to be done whenever we have time to do it. Since this is a volunteer organization, and we all have other pressing responsibilities, it is important that we do not encourage any systemic bottlenecks. If the Committer who likes to do the releases can't, someone else can just step up to bat without any hoopla. A committer is a committer .. from each according to their abilities, to each according to their needs. Regardless of what we choose to do from time to time, the codebase is our joint responsiblity. And when we drift away, someone else will step into our shoes. When we are gone, another committer may elect to do what we used to do, or a new contributor may fill the void and then be nominated as the product's newest Committer. The real problem I would have with non-voting Committers is that comitting is an important way of how we vote. Because we are all responsible for the entire codebase, jointly and severally, we don't have to vote on every little thing. We can vote through our commits -- unless and until another Committer points out an error in our judgment. Since committing is voting, what I think what some people want is a non-vetoing Committer. Someone to do the work without sharing in the responsibility. Which is to say, we can reject what they do, but they can't reject what we do. Personally, I would find that type of master/slave relationship difficult to maintain in a volunteer organization like this. If you are working hard enough to need commit rights, you are working hard enough to have veto rights. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Leo Simons wrote: we have, in practice, in quite a few of the subprojects. The in practice part in that sentence explains the quotes around leads. We have a nice theoretical meritocracy model defining several roles and responsibilities. That's just fine. The current model defines user, developer, committer and pmc member. In real life, there's more roles, overlapping roles, more specific roles, less specific roles. Examples: with Avalon, Peter and Berin handle most of our releases; they assume the role of release manager. Jeff Turner's been working on the build process; he had the cap of build process manager, now passed over to Nicola Ken, all informally. Fortunately, this is all okay and no-one complains. Like Ted said, we're pragmatic about it. Thing is, formal roles and responsibilities currently are (as per http://jakarta.apache.org/site/roles.html): user: no rights, no responsibilities developer: right to get quoted as author for authored pieces, no responsibility committer: right to vote as per voting guidelines, responsibility to sign and submit Contributor License Agreement pmc member: right and obligation to set overall project direction when these no longer reflect the ad hoc pragmatic roles defined within subprojects, or when they make using these pragmatic roles difficult, we should think about changing these definitions, roles and responsibilities. Fact of the matter is, the model is not perfect, and not everyone in our community fits into these categories very well. Saying that everyone who submits a patch is a developer is a bit of a strange definition, as you don't really develop documentation, etc etc etc. Pier brings this up, perhaps in a somewhat clumsy way, but with a valid point and valid arguments: voila, heated discussion and comments on a personal note. if it ain't broken, don't fix it leads to things like windows. We'd still be forced to work with AWT and JSP. - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Committer access and responsibilities...
Those who do the work of creating a Jakarta product are entitled to make the decisions regarding that product. A successful product is more than code, it also requires documentation and support and easy-to-use distributions. Whether a patch is to the code or the documentation isn't relevant. A patch is a patch, a contribution is a contribution, and anyone who makes sustained contributions to a product is elligible to become a committer. A change to the codebase can affect everyone, including them that don't code but simply document. They should have as much to say about the codebase as everyone else. The real point behind meritocracy, I believe, is that we are all equal and there is no formal hierarchy. It's also a big part of what makes Jakarta both fun and different from our regular jobs. We have a simple and effective system here that's been proven to work. I don't believe that the formal system is broken or needs to be refactored. -1 on there being shades of gray between contributors and committers. A contributor is anyone who has submitted code, documentation or any other deliverable that has been made part of the product. Committers do the work of creating the product by posting contributions to the CVS or other secure area. +1 on non-coders or specialists being voted as committers when the circumstances warrant. There is nothing to prevent this now nor should there ever be. If its OK with the other committers to a product, there's no reason for the rest of us to care. If it's not OK with the other committers, then it is not the system that's broken, but the committers -- and no amount of tinkering is going to fix that. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Pier Fumagalli wrote: Chatted with a lot of people, seen many, different development models, went around, asked, talked, and I believe I have a pretty decent picture, and maybe even a solution... So the major topic of discussion is that I perceive a substantial difference between being able to commit code to a CVS repository, and being a committer committer, with all dues and responsibilities that this role concerns... For example sometimes someone might want to have commit access just because he is working for a company that deals with a particular project in Apache (we've seen this happening several times with some projects such as Xerces and Tomcat), but he really doesn't care about the whole fuzz of Apache and stuff, and once the employment contract ends, the relationship with Apache terminates as well (I don't need to enumerate all those examples along those lines). One other example, if we didn't have Henri building RPMs for basically all Jakarta projects (and others), or if Henri wasn't a committer on Tomcat, don't you think that he would deserve committer status even if he's not tied to any particular codebase? We had this problem in the current election of the members, Sally Khudairi: Sally doesn't code, but she was involved with the ASF since before it was even created as a press organizer. Does she deserve to be a member of the foundation? Even if she doesn't code? Yes she does, IMO (and she was elected and nominated a member today)... So, IMO, there's a great difference between being a coder, and being a member of the Jakarta community, at least in my opinion. There might be coders who are not involved with the community, and there might be non-coders who are much involved with it, want to participate, are active and deserve to be committers... Our current structure doesn't allow that to happen, both things. If you need to write code in a particular source-base, and you need CVS access, you are automagically made a committer, even if you don't care about much else, and if you're very much involved with the overall project, but not tied to ANY whatsoever codebase, and really, don't want / can't do it. So, given this little background, I would like to ask to the PMC, and all other committers, if others agree that we should splitting the committer figure in two parts: - contributor: a contributor is someone who has access to a particular CVS tree, but for any reason doesn't want/need to be involved with the whole Jakarta community. He just wants to code his little bit and live a long life. - member: is someone who is involved with the Jakarta community, somehow, somewhere (might be just giving a great deal in supporting users of our projects, or providing extra value to projects, like guidance in respect to overall specifications, binary builds). He is effectively a member of the community and has all the rights and dues of every member, such as participate in the election of the PMC. And redefining the figure of the committer as follows: - committer: is a contributor, but also a member, therefore he has all
Re: subproject layout conventions
Leo Simons wrote: I very much agree. I was under the impression though that at this point, there are some designers available somewhere. It would be good if they would explain which things would be good to change so we can put that into the system. There is no paid staff, and AFAIK, no designers who are also committers. And even if there was one, we can't depend on something like that. We can depend on there being programmers here, otherwise there would be no living products, and before long, no users or Website to worry about. except that the website is not only for geeks. It's also for people that make decisions and have money. Says who? I'm thinking Jakarta is a developer-to-developer site. If other stop by, they're welcome, but our focus has to be on what we know. Personally, I leave the eye-candy to others, and focus on functionality. Given the products we write here, I think that's going to very common. I'm not saying that I would be particularly interested in any design anyone else came up with. I'm just saying that if I need to change it, I'm going to change it, because there ain't nobody else here to do it. Personally, I'd say it's better that our sites don't look ~too~ good. That way people don't get the wrong impression. There is no commericial support here. Just a bunch of volunteers doing the best they can. Jakarta is an all-you-can-eat buffet, and should probably look like one :o) -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: subproject layout conventions
Leo Simons wrote: As long as we agree that nothing should get into the way of site functionality (and we do), why would you oppose a site that also is easy to navigate and looks good? The only thing I oppose is the idea something being set in stone or approved by some mythical designer. http://www.mail-archive.com/general%40jakarta.apache.org/msg04500.html I need to change something, then I will change it. Everything is a shared resource here, and every committer is encouraged to take whatever action they feel prudent. I actually support what you are doing, so long as you remember who you are doing it for. The committers are the bosses here. Everything we do has to empower the committers and help them get past the adminutia and on with the development; or else there will be no committers, no products, no users, and no Web site. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Danny Angus wrote: Try and look at the front page for, admittedly a one liner, but one without subjective overtones, which doesn't present a non-contributors view of many projects as the Jakarta Overview Definition of what the project is. The overview has been donated to the ASF, and is under Jakarta rules now. If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. We are very quick to say Thanks for Volunteering around here. OK, someone volunteered, and we got what we wished for. Apache stands for patching ... -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Printable pages
Jon Scott Stevens wrote: I'm ok with that. Netscape 6 and IE 5.5 are released versions of the latest technologies. If those new technologies support the features we need, then lets require them for those features. It is like the big switch from JDK 1.1 to JDK 1.2. :-) I agree that a more printable site would be a good thing, but I don't know if I would classify this as as a feature we desperately *need* -- if it means forcing people to change browsers just to access the Jakarta web site. I would be -1 on a product change that made the main Jakarta web site inaccessible with Netscape 4.x. Of course, what each individual subproject does with their own area is up to their own comitters. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Web: http://husted.com/struts -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [site] proposed changes to site.vsl template
[EMAIL PROTECTED] wrote: Cool, feedback :) Where do u think it needs more whitespace - between 'menus' or 'items'? Personally, I like putting the sidebar menus on the right, so they are near the scrollbar. Then if the page is a little wide, its the menu that gets pushed off rather than the content. This also can also let you reduce the gutter between the columns (as you have already done, without it looking quite as squished. And, I believe, if the page is being viewed with a screen reader, this puts the navigation after the content, since the reader would read the columns left to right. I don't know if the menu has to be in an actual HTML list, which tends to indent things a little much. I'd either use non-breaking spaces (which are apparently not permitted right now) or a tranparent GIF to indent them. I haven't tried to do it yet, but it would also be nice to have different sidebar menus for sub-areas of the main site, like the volunteer guides area, the PMC area, and some other places where we are using page links instead of putting up a new sidebar. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Web: http://husted.com/struts -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Jakarta is developer-centric because developers are the ones who volunteer to do the work. They need working products to use with their paying jobs, and find that sharing the development load works better than going it alone. We don't get many marketing volunteers because there is very little payback. More marketing generates more users, but that doesn't always translate into more development or better products. Sometimes more users can actually hurt development, since user support distracts developers from developing. (Only so many cycles in a day.) I do a lot of work on product documentation myself, mostly becuase I have a mind like a sieve, and need it for my own reference. But for most developers and users, there is less of a payback, since once they know the product they don't feel the need to document it for their own use. Jakarta is here to build products. If someone wants to market those products, that's great. If volunteers want to provide commit-ready documentation, like Phillip did, I'll fulfill my responsibility as a committer, and post it. But the problem now is, who's going to maintain it over the long run? If the developers want to, that's great, but if they don't, well, how the other committers spend their volunteer hours is up to them. So, sure, some clear exposition about Jakarta would help a lot of people. If someone has an itch for more documentation, they should create it and share it with the group in a ready-to-commit format, as Phillip did. Though, I'm sure anyone ready to do the work doesn't need someone else to suggest the idea. Jakarta cannot be anything by design; it can only be what the volunteers make it. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Web: http://husted.com/struts Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] ASL vs. GPL page: is this okay?
http://www.dictionary.com/search?q=license http://www.dictionary.com/search?q=licence alex wrote: At 09:16 07/03/02, Danny Angus wrote: It is spelled licence. ;-) Wow - we managed to correct Jon on a technical point! (Just kidding Jon - no offence) licenSe is what Apache Software Foundation does - ie the act of licensing. licenCe is the document or permit given - eg the file itself. Since this is all about the document then licenCe is the correct spelling (ignoring Case that is). Personally I feel the existing web page which Jon reminded us of was quite good and if there is anything important missing then that is the page which should be improved. Alex -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: news@jakarta list? (Re: Introducing Enterprise Object Broker)
I think the original suggestion of [EMAIL PROTECTED] was fine. It is not mysterious or hard to remember, and most of the OT threads around here are generated by some type of news item. -Ted. Jeff Turner wrote: On Thu, Mar 07, 2002 at 06:03:21PM +, Pier Fumagalli wrote: Paul Hammant [EMAIL PROTECTED] wrote: Folks, Enterprise Object Broker (EOB) is an application server that tries to a be a simpler EJB container. It is not complete yet, but we have many demos showing local, remote, and webapp usage. Ok. Will we all stop using general@jakarta for advertisement of things which are NOT ASF related? Thankyou... Then could we perhaps have a news@jakarta list for this sort of thing? A lot of people find announcements like this relevant and interesting. How is it different from freshmeat? It's that 'community' thing Stefano goes on about. People have established webs of trust here. EOB is by Apache people, using Apache code, and that makes it *relevant*. --Jeff Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 - Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jakarta-site2 sidebar
+1 (done). Andrew C. Oliver wrote: Hi all, quick proposal... does anyone object to me moving [MISC] Who we are? bla bla bal to the TOP of the sidebar and renaming it [ABOUT]? Rationale: the MISC trivializes the information and says don't read me. If community is more important than codewhy is the code above the community info? ;-) I'm volunteering just waned consent first. -Andy -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 - Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The Complete Server Platform?
Leo Simons wrote: 2) a statement of intent in important places on the website. I'm guessing that putting we would like to see tomcat integrate with avalon on the projects' respective websites would mean that such will happen sooner. My concern would be that this promotes a We are Borg attitude. Why would we like to see Avalon integrate with Tomcat? Why not Jetty or Resin? If our committers are choosing to use Tomcat because it meets their real-life needs, then why would we have to tell them that. Won't they just do it because they need it? IMHO, committers should decide what is best for their product first. If we all do that, and we all create best-of-breed products, then interoperability will be a natural occurance. If it is not a natural occurance, then we are mixing politics with technology ... We would simply be replacing the Dark Lords with a Dark Lady. AFAIK, we don't tell Jakarta committers to use Ant. They choose Ant because it is a great tool. The same should go for every Jakarta or ASF product. Meanwhile, I do think documenting how J2SE (Standard Edition) technologies can provide an end-to-end solution is a great idea. For example, jGuru is running on Resin, Lucene, James, and JSPs. Scales great, and not an EJB to be found. So, should we (meaning I) write that up as a case study and post it on the site? Or, pass because they are not using Tomcat? AFAIK, Apache is part of the JS2E group, rather than the J2EE group, so it seems to me that promoting J2SE solutions is a natural thing for us to do, regardless of who provides the underlying product. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/struts -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Java Persistence Layer [was EJB, etc]
See http://jakarta.apache.org/site/newproject.html If you are serious, the first thing you really need to do is get the source posted someplace. This could just be a page on a free host, with the Apache License recast as the Michael Lee license. Or, SourceForge if you think you might want to play with it bit first. But, the ASF does not simply take code donations. We host projects and products with developers that want to actively promote the product as open source, under the Apache License, and manage the codebase in a meritocratic way. So, its not so much about the tool itself, but about them that want to use and improve the tool. You might also want to take a look at http://netmeme.org/simper/ Seems like you have a number of bullets in common. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Michael Lee wrote: Along the same lines as a smaller alternative to EJB (entity at least), I wrote my own java persistence layer for smaller 2-3 tier type environments. What would I need to do to submit this to jakarta? Its pretty damn cool. Every developer I showed loved it and immediately saw the void it filled. It is INCREDIBLY easy, fast and powerful. It is complete but has some design holes I'm not happy with that I hope the open source community could help aleviate. Anyone who has written a smaller 2 to n tier app would love this. I use it for most of my persistence coding where EJBs or toplink are overkill (which is most). I have to respond to something. I am putting up my qualifications to try to expunge and unneccesary cricism/bias that people should have if I were not to disclose this information; I was a consultant for BEA professional services for a couple of years. Before, and after, BEA I did a lot of RMI/CORBA/JDBC/servlet work. Before even that I wrote some of my own cross platform networking, database code in C/C++. Believe me, I have done my fair share of N-tier development on all kinds of os/hardware environments in all kinds of vertical markets. As for J2EE, I did a lot of work in Weblogic (obviously) but have also worked with JBoss/Websphere/IPlanet (I LOVE JBOSS!! Not quite as good as weblogic but the price is sure better! And to respond early, I could start up JBoss in under 12 seconds or so with about 40 EJBs and 200 jsps in a WAR file on a Pentium III 750mhz with 512MB ram). I currently work for a company that is is folding that makes a web services development/deployment/management tool. Knowing my qualifications here is my response to Aaron's post whom I have summarized with this one line from him; No matter what you try to do with EJB, I can provide a simpler, faster, more scalable, and cheaper solution. Wow, you should start your own company. Your obviously much smarter than the 100 or so developers that make Weblogic or the 50 or so that make JBoss, or the ? 100 ? or so that make Websphere, etc. You can make a Java Bean container that can handle clustering, fail over, caching, persistence, transactional services, security, etc. better than all those people? Wow, your the man. If I could create a product by myself better than all those people and create a billion dollar company I would. Seems stupid not to? Kind of strange you call 'people' stupid and claim you can do better than these teams at creating this monumental amount of complex code yet you don't do it, even though it could bring you great wealth? Ok then, how about open source? I have an open source persistence layer that I wrote to fill a void that I saw. It is a smaller persistence layer that performs C.R.U.D. operations, has caching, performs rudimentaty find operations, is PATHETICALLY easy and reusable, is fast and has no meta-data. It is not scalable like a J2EE container, has no built in security other than through the JDBC connection, does not have fail-over, does not have transactional integrity except that which the developer writes, etc. But if you want a quick from the web through a JSP form with little or no business logic, to the database, and back it performs like a champ. Much faster than EJB for one machine for just this type of task. I do not make claims that I could do something better than someone else without proving it. I want to release this open source and put my money where my mouth is. If I wanted a larger persistence system I would use JBoss (as I have no money) or Weblogic if I had some money. If I needed even more control and versatility over my persistence layer I might even add something like a Toplink. All perform well for what they do. My API/tool is a persistence layer between nothing and EJB. EJB is great at what it does. Granted, it is used many times where it does not need to be (ie: a simple RMI/JDBC design would probably suffice) but it does have a void that it fills. I have designed/coded many systems
Re: Bug database appears to be down
Until the Bugzilla is fixed, you should direct any issues regarding Ant to the Ant DEV list. Could get lost here =:o) http://jakarta.apache.org/site/mail.html Christopher Taylor wrote: Hello, The bug database appears to be down. The bug I wanted to submit was against ANT. If you use the copy task with filtering turned on, and the file is a different encoding type than the default decoding, the copy task will mangle the destination file. For example, I am using a Windows 2000 workstation with JDK 1.4 installed. I am putting together a Japanese and English website, where the files are all in UTF-8 format. The default encoding (as seen with the following code: import java.io.*; ... FileReader reader = new FileReader(some file); System.out.println (reader.getEncoding()); ... will be CP1252 (US-ASCII). What the copy task needs is an additional IMPLIED attribute that specifies the encoding for filtering tasks. The code in the org.apache.tools.ant.util.FileUtils class would need to be changed so it could receive an encoding parameter as well. Lines 220, 221 of FileUtils.java would need to be replaced with: FileInputStream fis = new FileInputStream (sourceFile); FileOutputStream fos = new FileOutputStream (destFile); InputStreamReader in = new InputStreamReader (fis, encoding); OutputStreamWriter out = new OutputStreamWriter (fos, encoding); This would fix the encoding problems with the filtering, as long as all content encountered during the filtering process was UTF8 encoded (since ASCII is subsumed by UTF8, this shouldn't be a problem for most people). Thanks, and I will post a patch on the jakarta-ant mailing list. -Chris -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: EJB = bad = MS.net
Struts works just fine with EJBs, along with any other standard Java technology. The discussion is about EJBs in general, independant of whether they are used with Struts or not. A good number of Struts developers do use EJBs, which is why so many people are contributing to this thread. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Yu, Yanhui wrote: Hi, I am involved in a pretty large project (we have not really started coding yet). As far as I can tell, we seem to go with Struts + WSAD + EJBs Java + JSP. Am I right to interpret that you mean the combination of Struts and EJBs are problem prone? Please help me to clarify on this. Thank you very much, Yanhui -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: bug HTML in STRUTS
The best place to post a message like this is the Struts USER list.
http://jakarta.apache.org/site/mail.html
BELGHALI Hassan (INFOGOLD) wrote:
Hello ,
Whe are encontred a problem in the Taglibs HTML: OPTIONS and
HTML:SELECT
The Taglib OPTIONS is change in to sevrols lines
See after the exemple in Frensh:
There are the javascript code before and after
Best regards .
Problèmes dans le FrameWork Struts.
Dans la situation actuelle, le menu d'accueil est créé entièrement en Java
Script ( pour être dynamique )
Afin d'intégrer la Date de Consultation dans ce menu dynamique, nous avons
besoin des Taglibs du Struts HTML :SELECT et HTML :OPTIONS
Le problème se pose sur le Taglib OPTIONS car celui ci est transformé en
plusieurs ligne d'options :
Voici le code Java Script :
document.write('html:select name=CompteurForm property=dateConsultation
');
document.write('html:options collection=listDateConsultation
property=value labelProperty=label /');
document.write('/html:select');
Voici le code après traduction par le Struts :
document.write('select name=dateConsultation');
document.write('option value=05/02/200205/02/2002/option
option value=06/02/200206/02/2002/option
option value=07/02/2002 selected=selected07/02/2002/option
');
document.write('/select');
Cela nous génère des erreurs par la suite lors de la lecture du Java Script
à cause du 'Retour à la ligne'.
La solution pour éviter cette erreur serait de retirer le caractère 'Retour
à la ligne' dans le Taglib OPTIONS.
J'ai donc modifier la méthode 'addOption()' de la classe 'OptionsTag' du
package 'org.apache.struts.taglib.html' en remplaçant la ligne
'sb.append(/option\r\n);'
Par 'sb.append(/option);'
Voici le nouveau code après la traduction par le Struts :
document.write('select name= dateConsultation ');
document.write('option value=05/02/200205/02/2002/optionoption
value=06/02/200206/02/2002/option option value=07/02/2002
selected=selected07/02/2002/option');
document.write('/select');
Maintenant les options sont sur une seule ligne. ( même si cela ne se voit
pas dans ce document) Ainsi Java Script reconnaît la commande et l'exécute
correctement !
Rappel : Cela concerne le même package pour lequel une modification a déjà
été faite sur la méthode 'doEndTag' de la classe 'FormTag'
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Java Web Development with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.0.2 Security Exception
The best place to post a message like this is the Tomcat USER list. http://jakarta.apache.org/site/mail.html Lars Wunderlich wrote: I get the following error after installation the current 4.0.2 release of Tomcat. I doesn't make a difference whether I use the exe-representation or the zip-file regarding this release. What can I do in order to install Tomcat correctly? D:\Tomcat40\jakarta-tomcat-4.0.2\bincatalina run Using CATALINA_BASE: .. Using CATALINA_HOME: .. Using CATALINA_TMPDIR: ..\temp Using JAVA_HOME: D:\jdk1.3.1 Exception during startup processing java.lang.reflect.InvocationTargetException: javax.xml.parsers.FactoryConfigurat ionError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl could not be inst antiated: java.lang.SecurityException: sealing violation at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java: 141) at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:224) at org.apache.catalina.startup.Catalina.start(Catalina.java:725) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: need help!!!
The best place to post a question like this is the Struts USER list. http://jakarta.apache.org/site/mail.html ¶ª ¶ª wrote: hello! I am a java developer,and I used Struts for serval days..but i found something wrong whit struts. For a chinese,I use gb2312 code ..and i write the APPLICATIONRECOURCES in chinese.but it appears bad code ,i must change encoding in IE...but why? i also changed the text from struts-example, and the same things happend.. please help me!!! iexcl;iexcl;iexcl;iexcl; iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl; iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;diudiu iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;[EMAIL PROTECTED] iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;iexcl;2002-01-23 _ ÏíÓÃÊÀ½çÉÏ×î´óµÄ Web µç×ÓÓʼþϵͳ ¡ª¡ª MSN Hotmail¡£ http://www.hotmail.com/cn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PMC Nomination - Ted Husted
Assuming there is a sufficient number of willing candidates to fill the seven slots, I would respectfully decline my nomination, so as to ensure someone else the chance to serve. It's been my experience that the best way to build community is to not only participate yourself, but also to give others the chance to step up to bat, and this seems like a good opportunity to do that =:0) In the event another person is needed to serve on the Committee to fill the seven seats, I would be happy to volunteer again. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Java is dead... but it could still be saved!
+1 Kevin A. Burton wrote: Heck no. .NET/c# why would I want to use an even more proprietary thing to get back at SUN? Heck no. ... hm.. this discussion could be on the list... buy anyway. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: TomCat license
The license for Tomcat, and all other Apache Software Foundation products, can be found here: http://apache.org/LICENSE Other questions regarding Tomcat can be directed to the Tomcat USER list. http://jakarta.apache.org/site/mail.html Kollár Dóra wrote: Dear Sir / Madame, My name is Dora Kollar and I am Presales Specialist at Noreg Ltd, Hungary. Noreg Information Protection Ltd. has been present on the Hungarian information protection market since 1998. Noreg provides a full scale information protection service for its customers. Besides the vulnerability testing and intrusion detecting, the safe network communication, access control, encryption, electronic signature authentication solutions and all information protection auditing and consultation activities in connection with all the mentioned fields are also included in the scope of service of the company. Last year we implemented Baltimore UniCERT modules at a customer. UniCERT WebRAO 2.2 MediaKit contains a non-commercial Jakarta Tomcat web application (TomCat 3.2.1). Does it (Tomcat) contain some limitations? Do we have to purchase licence to use it legally? If your answer is yes, how many licences do we have to purchase? What is your license policy? I am looking forward to your reply. Many thaks and best regards, Dora Kollar Presales Specialist Phone: +36 1 4386380 Fax: +36 1 4386381 E-mail: [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jkarta-site2
Danny Angus wrote: 2/ if I add it to news xdoc do I also have to add it to index under headlines, and.. if I do that do I knock off the earliest headline to keep the lists the same length. +1 Actually, I'm thinking five looks a little crowded. If you wanted to go with three, I think that would be fine too. But I don't think we want more than five. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Broken Link On Struts Page
The best place to post a message like this is the Struts-DEV list. Each subproject maintains their own area of the Web site. But in this case, I'll take care of it :-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ [EMAIL PROTECTED] wrote: FYI - On this page: http://jakarta.apache.org/struts/userGuide/resources.html, the link called StrutsResourcesChecker to this page: http://jakarta.apache.org/struts/userGuide/resources/checker.html is broken. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RE: J2EE considered harmful
yahoo.com goes way beyond a search engine: Email, address books, auctions, classified ads, file storage, calendars and shared calendars, personalized portals for like 27 different sub applications, the list goes on. Yahoo is delivering a vast number of dynamic applications to an incredible number of users, with excellent performance and reliabity. If there a success story in IT, this is it. I picked yahoo.com and google.com as two different examples of high traffic Web sites that are delivering scalability. I only mentioned google.com since it is ~blazingly fast~, and represents a very different best-of-breed right now. Andrew C. Oliver wrote: Those are both search engines with non-critical data update issues. You do need an example with more business-logic oriented type functionality. I could mock something like those up with Lucene just with a few routers and pushing the indicies to the mirrored systems. This doesn't answer the enterprise system question. Secondly we need examples on a more moderate basis. (sorry, if that sounds critical, I don't mean to be, I think you're heading the discussion the right direction, I just don't think those examples do that) On a more personal note. Funny story: My wife went to high/grade school with the Google guy. Small world eh? -Andy On Fri, 2002-02-01 at 08:57, Ted Husted wrote: Perhaps the question to ask is how are real sites providing real scalabilty without resorting to Enterprise JavaBeans? Take google.com and yahoo.com for example, Yahoo offers a signficant number of remote, multi-user applications like the ones we would like to provide to our own clients. Are they using EJBs? If not, what do they use? How can we turn Yahoo's approach into a toolkit model that other developers can use? Google is offering a single, read-only servvice, but at mind-bending speed. How does it serve so many users so quickly? Again, how can we package that approach in a way that it accessible to other developers? Sorry to be providing more queries than code, but to paraphrase Linus, it often takes one person to articulate an issue, and another to resolve it =:o) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: J2EE considered harmful
You know, since Apache is a member of the J2SE group at Apache, it would make a lot of sense for us to develop a resource page regarding J2SE scalability. I'd be very happy to start and maintain such a page here, as I do for Struts. http://husted.com/struts/resources.htm If anyone has some starter links, send them along, and I'll get going. More importantly, we should also not hesitate to pubish our own orignal material, such as case studies, if anyone here wants to pass one along :-) Personally, like James, I think all the tools are already there, and much easier to deploy that bothering with EJBs. The vendor slove to say you get this-and-that for free, but the hidden costs are staggering, and in the end, it's obvious that you lose much more than you gain. Two steps forward, six steps back. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ James Strachan wrote: Agreed. Though I've 2 points to make. #1 you don't need to use EJBs to distribute business logic If you do need to distribute business logic, then there are various alternatives open, from HTTP/Servlets, JMS, SOAP or EJB. Each should be evaluated on their merits, cost/benefits etc. #2 just because you may eventually distribute your business logic, assuming you're going to from the start (and assuming that means EJBs and then jumping through lots of EJB hoops headeaches and paying a fortune to some EJB vendors) is bad XP practice IMHO I prefer to take an XP approach, first build a web application that works, is performant and scalable then worry about whether business logic needs to be distributed later. Afterall us Java folk are OO guys right? We can write our business logic in such a way that it could migrate to EJB later if we think thats the right thing to do. Or to put that another way - I'd prefer to focus on giving the customer what they want and making a good web application than grappling with EJBs just because one day, maybe, under some conditions, I might want to distribute some of the business logic in the web app under the 'faith' that its the right thing to do. Most business logic in most web applications is pretty minimal in terms of computation and is often mostly database intensive so moving this code to another process doesn't usually buy much in terms of scalability - if anything its the reverse thats true - what with all that EJB distributed garbage collection connection based protocol stuff that needs to be done scalability (and usually always performance) can go down. If your application will grow it is good to have a middle tier that can be moved and load balanced. With Entity beans of course this is less possible. (And stateful session beans ;-). I think this is true of traditional GUIs, say a Swing client front end, a middle tier server (say server side beans aka EJBs) and a database. I don't think this is true of web applications as they are quite different things - a servlet engine is not a 'GUI' client. Servlet engines are a stable, performant and very scalable application servers in their own right. Get a hardware load balancer and a farm of servlet engines and your *way* scalable. Arguing for the need for another, remote CORBA component-centric application server based on mostly connection-based protocols, RMI, stubs and distributed garbage collection to make your web-application more scalable seems, well, strange. In my experience web applications scale best when you have a big server farm of servlet engines which are load balanced. A database at the back and hopefully some kind of read only caching going on to take as much load off the poor database as you can. Then you can distribute parts of your web application into different server farms, get load balancing, shuffle things around as load changes etc. Then pick the web technologies of your choice, Struts, JSP, Velocity, Turbine etc. Away you go. I still don't see the 'scalability' argument as in any way advocating that EJBs are actually useful for web applications. In fact this idea that EJBs are required to build scalable web applications is plain false - probably marketing hype spread by the EJB vendors. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta PMC Nomination - Rejection
So long, and thanks for all the fish =:0) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Java Web Development with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Jon Scott Stevens wrote: Hey all, I just wanted to say that I'm not going to accept my Jakarta PMC nomination and do not want to be included in the voting for the next election. I have been involved with Java Apache/Jakarta since Sept 1996 and I think that it is time for me to move on from being politically responsible for this group. Honestly, I'm jaded and burned out on it all. That said, I recently signed a 10 year lease on a prime event space in downtown San Francisco and I am moving towards spending more time being a big time night club owner than working on Jakarta. More info: http://www.studioz.tv/ (p.s. that site is built with Anakia smile) I also just released Scarab 1.0b1 and am focused primarily on making Scarab the best issue tracking tool around. Expect to see more great developments on this project. It is by far, one of the best designed, largest and most complex pieces of software that I have ever had the pleasure of helping develop. It will be around for a very long time and will eventually put Bugzilla out of business. More info: http://scarab.tigris.org/ thanks, -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Fwd: cvs commit: jakarta-site2/xdocs index.xml]
I'm not comfortable with carrying this type of editorial matter at the top of the home page, and would like to move it to the news and status page. -Ted. Original Message Subject: cvs commit: jakarta-site2/xdocs index.xml Date: 30 Jan 2002 21:53:04 - From: [EMAIL PROTECTED] Reply-To: Jakarta WebSite CVS List [EMAIL PROTECTED] To: [EMAIL PROTECTED] jon 02/01/30 13:53:04 Modified:docs index.html xdocsindex.xml Log: lets have a little fun. Revision ChangesPath 1.52 +32 -0 jakarta-site2/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-site2/docs/index.html,v retrieving revision 1.51 retrieving revision 1.52 diff -u -r1.51 -r1.52 --- index.html29 Jan 2002 01:47:06 - 1.51 +++ index.html30 Jan 2002 21:53:03 - 1.52 @@ -140,6 +140,38 @@ table border=0 cellspacing=0 cellpadding=2 width=100% trtd bgcolor=#525D76 font color=#ff face=arial,helvetica,sanserif + a name=That flaming fireball in the sky...strongThat flaming fireball in the sky.../strong/a +/font + /td/tr + trtd +blockquote +p +In a recent a href=http://www.theserverside.com/resources/article.jsp?l=SunInterview;article/a, Karen Tegan, Director of J2EE Compatibility and Platform +Services for Sun Microsystems, had the following to say: +/p +p +The J2EE Compatible brand has achieved significant momentum over the +past two years, and we want to make sure that any open source efforts +don't impact the viability of that effort. +/p +p +In other words, Sun doesn't give a hoot about whether J2EE licensing +restricts open source J2EE products (in case you missed it, it does). +Thus, the Apache Software Foundation's involvement in the Java Community +Process (JCP) is simply an advertising statement for Sun to claim that +they have a 'vision which uses open standards and non-proprietary +interfaces'. If you would like to express your opinions of Sun's +licensing terms, feel free to contact a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a and let us know what you +think. Thanks. +/p +/blockquote +/p + /td/tr + trtdbr//td/tr +/table +table border=0 cellspacing=0 cellpadding=2 width=100% + trtd bgcolor=#525D76 +font color=#ff face=arial,helvetica,sanserif a name=WelcomestrongWelcome/strong/a /font /td/tr 1.21 +28 -0 jakarta-site2/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- index.xml 20 Jan 2002 16:28:07 - 1.20 +++ index.xml 30 Jan 2002 21:53:03 - 1.21 @@ -9,6 +9,34 @@ body +section name=That flaming fireball in the sky... +p +In a recent a +href=http://www.theserverside.com/resources/article.jsp?l=SunInterview; +article/a, Karen Tegan, Director of J2EE Compatibility and Platform +Services for Sun Microsystems, had the following to say: +/p + +p +The J2EE Compatible brand has achieved significant momentum over the +past two years, and we want to make sure that any open source efforts +don't impact the viability of that effort. +/p + +p +In other words, Sun doesn't give a hoot about whether J2EE licensing +restricts open source J2EE products (in case you missed it, it does). +Thus, the Apache Software Foundation's involvement in the Java Community +Process (JCP) is simply an advertising statement for Sun to claim that +they have a 'vision which uses open standards and non-proprietary +interfaces'. If you would like to express your opinions of Sun's +licensing terms, feel free to contact a +href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a and let us know what you +think. Thanks. +/p + +/section + section name=Welcome !-- ApacheCon is over. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts vs. Turbine
http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayQuestionAnswer/action/SetAll/project_id/2/faq_id/36/topic_id/203/question_id/781 or (same thing) http://www.mail-archive.com/struts-user@jakarta.apache.org/msg03206.html http://www.mail-archive.com/general@jakarta.apache.org/msg00495.html http://jakarta.apache.org/velocity/ymtd/ymtd.html -Ted. Gerhard Froehlich wrote: Hi, DISCLAIMER: No flame war please! I just overlooked the 2 jakarta project Struts and Turbine. Both seems very similar to me and I want to know where they main difference is and when to use Turbine and when to use Struts. Please add you comments! Gerhard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] POI @ Jakarta
+1 Andrew C. Oliver wrote: Proposal for POI - A Jakarta Subproject version 1.0 - 17 Jan 2002 (0) rationale The POI project seeks to provide pure Java APIs for reading, creating and manipulating files written in formats based on Microsoft OLE 2 Compound Document Format. The POI project has already successfully created a Pure Java OLE 2 Compound Document Format library (POIFS) and a port of the Microsoft Excel '97(-2002) file format (aka XLS, BIFF8) and tools for serializing XML in these formats (which will be hosted as part of Cocoon 2). The POI project user community is growing leaps and bounds in usage as evidenced by its position as one of the most active projects on SourceForge and the 2,290 people who have downloaded it so far this month. The POI project currently has two active developers. The development community might be small but is fanatically committed (and growing rather quickly). It is likely that the upcoming port of the Microsoft Word 97 File format will increase the size of the development community, not to mention the user community. The documentation is comprehensive and includes full documentation on the previously undocumented (or at least incompletely documented) Microsoft OLE 2 Compound Document Format. There are also HOW-TO documents that illustrate use cases and examples. Lastly, The project founders have agreed to collaborate with a developer at the OpenOffice.org project on the Excel File Format Documentation. Many Jakarta projects could potentially take advantage of POI and its use in Jakarta will likely further seed the POI developer community. POI is a unique project in the Java world. Up until now there have been no successful free attempts to provide read/write access to OLE 2 CDF or MS Excel (97+) file formats. POI coupled with other Jakarta technologies could produce some highly useful offspring. A few specific examples might be Office Document indexing for Lucene, Velocity generating Excel and Word document presentations, Office document management capabilities for Slide as well as content delivery and editing in Turbine. POI would make it possible to use Jakarta and XML-Apache projects in many cases where currently a proprietary solution is currently required. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in generating and reading files in formats based on the OLE 2 Compound Document Format. (2) identify the initial source from which the subproject is to be populated The initial packages would be based on existing POI codebase currently located at SourceForge: http://poi.sourceforge.net (3) identify the Jakarta resources to be created (3.1) mailing list(s) poi-user poi-dev (3.2) CVS repositories jakarta-poi (3.3) Bugzilla program - poi components - Web site, POIFS, HSSF, HDF (3.4) Jyve FAQ (when available) poi-general poi-poifs poi-hssf poi-hdf (4) identify the initial set of committers Andrew Oliver Marcus Johnson (5) identify apache sponsoring individual Stefano Mazzocchi -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta PMC bylaws change
+1 Sam Ruby wrote: The number of PMC seats will be set at seven. Annually, all seven seats will be up for renewal. The ASF board will be asked to provide a person or persons to administer the nominations and a subsequent ballot. The administrator(s) will determine the mechanics of the voting procedures. Any committer to any Jakarta code base will be eligible to vote. Once the new PMC is in place, the first order of business will be to determine a chairperson from amongst their ranks. Once ratified, this proposal would be effective immediately, and an election would be initiated. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] jakarta-site2.xml [Was Re: updating subproject websites]
Done. http://jakarta.apache.org/site/jakarta-site2b.html robert burrell donkin wrote: On Tuesday, January 15, 2002, at 10:27 PM, Ted Husted wrote: If you would like to send the XML the page to me, Robert, and I will post it as an alternative page, and we can whiteboard it for a day or two, as we did on the New Product Proposal page, before talking it live and direct :) sounds like a good plan to me :) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Jakarta PMC bylaws change
True. Right now, I monitor the Commons, Lucene, and Taglibs, and only have commit rights to one of these. Since the PMC meets here, the subprojects can represent their own interests. The primary role of the PMC is to ensure that the ASF bylaws and Jakarta guidelines are observed, and that Apache resources are not used in inappropriate ways. The PMC gets to vote on new subprojects, but the committee members have no other special privledges or powers. -Ted. Marc Saegesser wrote: Simply because each Jakarta project doesn't have a committer on the PMC does not necessarily imply that each project would not have representation on the PMC. Hopefully, through the nomination and voting process, each project would find someone that is willing to represent their interests in the PMC. Requiring direct representation for each project does not sound like a good long term strategy. Marc Saegesser -Original Message- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 4:07 PM To: Jakarta General List Subject: Re: [PROPOSAL] Jakarta PMC bylaws change On Thu, 17 Jan 2002 06:27, Sam Ruby wrote: The number of PMC seats will be set at seven. Annually, all seven seats will be up for renewal. The ASF board will be asked to provide a person or persons to administer the nominations and a subsequent ballot. The administrator(s) will determine the mechanics of the voting procedures. Any committer to any Jakarta code base will be eligible to vote. Once the new PMC is in place, the first order of business will be to determine a chairperson from amongst their ranks. Once ratified, this proposal would be effective immediately, and an election would be initiated. Sounds good - but this kinda has one other implication. The PMC will no longer be able to adequetly cover all sub-projects - it would be quite possible that some some projects would be completely without representation. If this was put in place it kinda suggests that maybe jakarta should not be so big ... ;) -- Cheers, Pete These aren't the droids you're looking for. Move along. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
For the time being, I've removed the sentence about the Commons from the working draft. Though, since both Jakarta and Commons have procedures for accepting new products, it would seem polite to steer anyone interested in donating a codebase to Jakarta to both places. After all, many proposals have been met by the response, Why not propose this to the Commons or try it in the sandbox. If another subproject were to publish guidelines for proposing a new product, as the Commons does, then I agree we should cite that subproject here too. It's also important to note that the advertisement was originally put in by Jon Stevens, not any of the Commons committers. http://jakarta.apache.org/site/newproject.html -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ Peter Donald wrote: On Mon, 14 Jan 2002 00:18, Sam Ruby wrote: Peter Donald wrote: Unless you plan on adding similar comments for a few other projects I would suggest you remove the commons advertising Why? Should the reference to Turbine be removed from http://jakarta.apache.org/site/source.html ? Do you have a proposed patch? Something you would like to add? Um ... here is the section I am talking about Jakarta can host a product within a top-level subproject, or as a component in the Jakarta Commons. This document covers what is expected of a proposal for a top-level Jakarta subproject. The Jakarta Commons has a similar but different procedure for accepting new products. See the Jakarta Commons site for details. Is this something you think is needed and should be in the jakarta guidelines? Guys, I can understand why some of you may not want to participate in other activities, but this is no excuse for attempting to block the progress of others. hmm - exactly how am I blocking the progress of commons? I have wanted to do something very similar to commons for ages - hell way before JDD even proposed AUT which was way before commons was proposed. And if you recall I was somewhat active in early library-dev discussions, no? Do you disagree with anything here? Have I ever blocked anybody moving anything to commons? Yes I would love to particpate in commons but I probably wont because I consider the management process of it broken. Consider this - how many committers are there in commons atm - 10, 20, 30 ? Now to get a new project moved you need a 3/4 vote - lets be generous and say about 12 votes! That seems real likely. Then you have the joy that every commons committer has voting rights on everything - even code they have never contributed and never will - sounds like a great meritocracy - right? M, just the sort of thing we are meant to be promoting. So yes theres buckets of stuff in ant, in excalibur and at home that I would love to move to commons but that aint going to happen till its fixed or if ever. Considering you seem to be accusing me of blocking progress in commons I want you to explain it in real simple terms how I am doing it? I seem to be a bit think and can't quite figure it out. -- Cheers, Pete Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposed redraft of the subproject proposals
+1 http://jakarta.apache.org/site/newproject2.html Sam Ruby wrote: Good draft. Here's some ideas (not quite proposals) that might merit discussion: 1) Upping developers from 2 to 3. I'd rather have a rule that said three that we chose to break on occasion than to have to explain why 2 is barely sufficient. 2) Alignment with existing Apache subprojects. Code that is used by many existing subprojects is attractive. Code that makes use of alternatives to Apache code exclusively is less so. 3) Warning sign: developers who ONLY work on the task because it is their job. 4) Warning sign: lack of diversity in developers. For example, if all of the developers are from the same company... - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
+1 There is now a Subproject Alternatives section citing Taglibs, Avalon, Commons, Turbine, XML, et al. http://jakarta.apache.org/site/newproject2.html Peter Donald wrote: Unless you plan on adding similar comments for a few other projects. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: updating subproject websites
robert burrell donkin wrote: i've reread it a few times and i think that i might i understand it now. is the following the answer to 'how should i go about making changes to the existing web pages of a subproject': Assuming that the subproject is setup to use the site2 default advice. This is not required, but is usually the case. The subprojects are responsible for their own subsite, so the best people to check with are the committers to that subproject. 1. modify the subproject's xml (in the subproject's source directory) and run anakia to get html versions. 2. check in the changes into CVS. 3. logon to the machine hosting the Jakarta web site, cd to the subproject' s web directory and execute a 'cvs update'. 4. enjoy the revised web pages :) Yes, if the subproject site has been setup to work the same way the main site works. But, again, you should consult with the committers to the subproject. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] project descriptions index.xml
OK, Danny. If you don't have karma to site2, I'll punch it up. -Ted. Danny Angus wrote: Hi, I like the table of descriptions, but have a patch for James' description .. cvs -z9 diff -u index.xml Index: index.xml === RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v retrieving revision 1.18 diff -u -r1.18 index.xml --- index.xml 8 Jan 2002 05:34:01 - 1.18 +++ index.xml 11 Jan 2002 11:00:05 - @@ -172,7 +172,7 @@ /tr tr td align=right valign=topa href=./james/index.htmlJames/a:/td -td valign=topJames is an email/news/messaging server written in Java. It uses the Avalon component framework. It currently supports SMTP and POP3 (stable) with IMAP and NNTP in the works./td +td valign=topJames is an email/news/messaging server written in Java. It uses the Avalon component framework. It currently supports SMTP, POP3 and NNTP with IMAP coming shortly./td /tr tr td align=right valign=topa href=./jetspeed/index.htmlJetspeed/a:/td -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
