Re: [PROPOSAL] Open JPA
Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Geir Magnusson Jr wrote: However, I absolutely don't believe that at graduation we need to closely examine the assets of the project to make some judgment about individuals as committers. O, I don't know. Since commit access in the podling frequently results in commit access in the TLP, I think it might be reasonable at graduation to take a look at the records of the podling's committers. Commit access in a TLP is earned -- period. Someone who's on a podling's commit list but committed little or nothing shouldn't graduate to TLP committership solely on the strength of having been on the podling list. Which is a really long-winded way of saying: At graduation, maybe it's worthwhile to see whether the podling committers actually earned any Apache merit. Maybe it's something we require of the PPMC? :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thoughts on Umbrellas, Federations, and Communication
Echoing robert... inline Matthieu Riou wrote: One of thing things that the we need to look at is how to improve communication across projects. Perhaps having some ontological mailing lists would be part of a solution. What ideas and views do others have? I know that mailing-lists are part of the foundation of the ASF and are a really useful way to communicate effectively. However my feeling is that we don't have the right tools or policies to use them as effectively as could be. For example, as a commiter, I find it extremely annoying that I have to subscribe to a mailing-list just to post a message on it. Also most archives aren't really user-friendly. Not being able to do a simple search on ALL mailing lists is for me a major drawback. So I'd suggest (if possible) the following ideas: * Give any commiter the necessary rights to send an e-mail on any mailing list without having to subscribe. It's not a rights issue, but simply a mechanical issue of how the lists work. Maybe there is a post-ok-don't-send mode. Or maybe we could cook up a gateway for committers [EMAIL PROTECTED] or something... * Provide fully searchable mailing-list archives. Hey! thanks for volunteering! :) I think this would help reducing the boundaries between each project as any commiter would be able to comment and participate to a specific discussion on any project. Well, back in Jakarta's heyday, the general list was the meeting place for all the subprojects. It was a lot of fun. I'm not sure we could do that on an apache-wide scale though. Part of the fun was because we knew each other, and that there was a topic domain that was narrow, but broad enough to span Jakarta. And I'd simply define a few search criteria that I'm interested in and check these once a while on all list archives. Hey! Thanks for volunteering! :) Maybe we should subscribe all apache mail lists to one google account and figure out how to have a web site proxy searches into it... geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Open JPA
Yoav Shapira wrote: So we agree that we allow the current proposed committer list as-is, but when we look at graduation from the incubator we examine test case and documentation as well as the product source code itself, because by bringing these people in as committers through the incubator, the OpenJPA team commits to working on test cases and documentation as much as product code? I certainly still believe that we bring the committer list as proposed, with any further additions by the Apache community. However, I absolutely don't believe that at graduation we need to closely examine the assets of the project to make some judgment about individuals as committers. Can you imagine if we judged all source? (Hey, you overuse Singletons, and quite frankly, I perfer XMLBeans over JAXB. You don't do enough javadoc, and your spelling stinks...) Why? Because (to me, anyway) the point of incubation is figuring out how to work as a meritocratic community of peers, and learning how (as the PPMC) to govern the project in the Apache fashion, to know our IP rules and processes, etc. If I believe that those high-level things have been achieved, I therefore must extend trust to the mature podling that they have the low-level, detailed issues of committer participation, code, docs, test cases, and others reasonably well in hand. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Open JPA
Yoav Shapira wrote: Hola, A couple of questions: :Core Developers: Fourteen of the initial committers are BEA employees. One of those is a committer on the Apache JDO project. We anticipate that five of these fourteen will be involved in the core code development, and the other nine will be involved in documentation and ongoing QA for the project. Must the other 9 have commit privileges? If they're doing docs and QA, most of what they'll be doing is available via JIRA or whatever issue tracker is set up. There's no harm in QA and docs people having commit, especially if they are working on SVN-based QA infrastructure and/or documentation that has some permanence and structure in a reusable format. :) (We had a doco person as a committer in Velocity many years ago w/ no downside, and joke we'd be breaking new ground having formal QA people in an open source project /joke ) JPA is for use in any Java application, not just J2EE. Therefore, any application that needs to do data persistence in the object/relational style (including any application that currently uses Hibernate) will benefit from Open JPA. Would it make sense for this to go in DB or Jakarta, then? The Geronimo association implies a J2EE container in my mind. It makes far more sense in DB, although it makes sense as a TLP as well (as much as anything does). I don't see the Jakarta link other than it's in Java. This is a peer technology to JDO2, for example, and arguably wouldn't exist if not for the cesspool of politics that surrounded The Great EJB3/JDO2 War of 2004. I suspect though that it will have a far larger community given the popularity and hype around the spec. The Geronimo associations are due to the fact that EJB3, the EJB version for J2EE 5, has a subspec that it's own core persistence engine. That is what JPA is. (Son of EJB3) So Geronimo can use OpenJPA as the persistence engine for it's EJB3 implementation, but the spec for JPA is explicit in it not requiring J2EE or EJB - it's for general use in J2SE, just like Hibernate, for example. When we've discussed how Roller, for example, can shed it's Hibernate dependency, I've suggested that Roller switch to the EJB3 persistence API that Hibernate also implements has so that some future Apache Licensed implementation could be substituted to comply with distribution requirements. OpenJPA is one such Apache Licensed implementation, or will hopefully soon be. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DB PMC sponsoring Cayenne in incubation
Why do you think it's optional? I do think we should clear it up in or docs, but the way I think of it is that there's an Apache Member or Officer who thinks it's a good idea for the project to come here. Seems like a good idea to have one. geir Andrus Adamchik wrote: So let's go ahead. Looks like the Champion requirement is indeed optional, and we have all other roles covered now. Can someone start the Incubator PMC vote on Cayenne acceptance? Andrus On Mar 7, 2006, at 10:47 PM, Jim Jagielski wrote: Perfect! On Mar 6, 2006, at 3:06 PM, Andrus Adamchik wrote: On Mar 6, 2006, at 10:48 PM, Jean T. Anderson wrote: Andrus, since Jim and I aren't reflected in the posted version of your proposal, it might be more manageable to put your proposal at http://wiki.apache.org/incubator/ . That'll make it easier to make any other changes the Incubator might like to see. Done: http://wiki.apache.org/incubator/CayenneProposal Andrus - 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: [Wicket] As erspective podling candidate
Timothy Bennett wrote: Geir Magnusson Jr wrote: I've been tracking the progress of the Wicket community for a while now, as I've personally adopted Wicket as a web application development framework, both privately and professionally. What!?!?!?! Not Ruby On Rails Do your friends know? :) hehehe... rails.. another discussion for another day... IMO Apache has a great opportunity to bring one of the next brightest technologies under the ASF umbrella. Wicket is interested in Apache. If Apache is interested in Wicket, then I would gladly offer my assistence in helping facilitate further discussions between the necessary peeps within Apache and the core Wicket dev team. Sounds good. I'm just interested in what motivates people to come here. Good luck! Me too! I wonder that sometimes myself!! On a more serious note, the Apache name brand itself is something of value. Note - that is a warning sign :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wicket] As erspective podling candidate
Niclas Hedhman wrote: On Monday 06 March 2006 03:35, Geir Magnusson Jr wrote: Timothy Bennett wrote: On a more serious note, the Apache name brand itself is something of value. Note - that is a warning sign :) Well, it is a fact, isn't it?? The warning sign is when it becomes the a driving force for a project to join. And ironically, ASF can't really tell... ;o) I think we should be able to tell... geir Cheers Niclas - 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: [Wicket] As erspective podling candidate
Bennett, Timothy (JIS - Applications) wrote: -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Friday, March 03, 2006 10:46 AM To: general@incubator.apache.org Subject: Re: [Wicket] As erspective podling candidate do *they* want to? why would they want to move? Geir, I've been tracking the progress of the Wicket community for a while now, as I've personally adopted Wicket as a web application development framework, both privately and professionally. What!?!?!?! Not Ruby On Rails Do your friends know? :) As part of my tracking of the project, I became aware last December that the Wicket core developers were planning an exit strategy from Sourceforge. I immediately felt like Wicket would be a great candidate for Apache, not just because of the innovation of the technology, but because they already had a healthy and vibrant developer, user, and support community. I asked Alex Karasulu if he thought Wicket would be a good fit for Apache, and he readily agreed. It was at that time that both Alex and myself approached the Wicket team to determine if there was an interest level on their part in possibly moving to Apache. Their interest is VERY high in moving to Apache, but they had some questions and concerns. Some have been addressed, but some issues remain outstanding. For instance, they understand that incubation is necessary, but they very concerned about continued support of their already mature product and user base, and the long-term future of Wicket. In essence, they are exhibiting the some of the core characteristics of what an Apache PMC is supposed to do. Wicket is no one-man show. They have a core set of about half a dozen developers, with a number of other second-tier contributors. Their user community is heavily involved in wiki contribution and providing user-contribs of Wicket component extensions, and integrations with technologies like Spring and Hibernate. Others, like myself, are interested in Wicket's natural affinity to live in OSGi, with or without a servlet container. The core developers have a detailed roadmap for future growth of the technology, and they readily include their user community in helping prioritize new features. Their user mailing is very active (125-175 posts/day), and the core developers are readily accessible via mailing list and IRC. Additionally, they are under contract to product a Wicket-In-Action book, which is currently be written. Bottom line is that Wicket WILL move from Sourceforge. The only question is where and when. They are getting ready for a 1.2 release within the next month. After that, they want to move the project before starting on the 1.3 release path. They are very interested in Apache, but are naturally concerned about incubation. They will want to move as quickly through the incubator as possible, and I believe the maturity of their developer community will facilitate. They know they have things to learn about the Apache Way, but they will be motivated to demonstrate this as quickly as possible in order to exit as a top level project at Apache in preparation for their 1.3 release. As such, they feel they will be demanding to their incubator mentor(s) and they would like some assurances of having enough Apache support. Moving Wicket is an expensive endeavor both in time and resources, not to mention the impact to the user community. It is a job they want to do once, so they are being very careful and diligent in choosing their new home. IMO Apache has a great opportunity to bring one of the next brightest technologies under the ASF umbrella. Wicket is interested in Apache. If Apache is interested in Wicket, then I would gladly offer my assistence in helping facilitate further discussions between the necessary peeps within Apache and the core Wicket dev team. Sounds good. I'm just interested in what motivates people to come here. Good luck! geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wicket] As erspective podling candidate
do *they* want to? why would they want to move? Alex Karasulu wrote: Hiya, I've been following the Wicket project (http://wicket.sourceforge.net) for some time now and have noticed that besides having an awesome web framework they've got a solid community behind it all. These folks have great collaboration going on and the code is all ASL. I'm posting this email to guage the interest at the ASF for bringing wicket into the incubator. I've had a few conversations with Apache people and wicket folks about this. Any thoughts? Comments? Thanks, Alex - 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: [VOTE] accept Cayenne into incubator
Mike Kienenberger wrote: Yes, we've already discussed this in the cayenne community and are in agreement that while we'd prefer TLP, we're ok with being under DB or Geronimo. Geronimo? Sheesh. The issue now is incubation sponsorship, which is independent of landing spot after graduation. Lets just resolve the sponsorship issue and move from there. geir -Mike On 3/2/06, Andrus Adamchik [EMAIL PROTECTED] wrote: Ted, The community has been aware of our two graduation options. The issue of sponsorship, albeit the important one, doesn't change the goal of the proposal. Cris just posted a note to our committer list to inform everybody who is not watching [EMAIL PROTECTED] of the current developments. But I think we can proceed with the DB PMC vote. Andrus On Mar 2, 2006, at 5:57 PM, Ted Husted wrote: On 3/2/06, Andrus Adamchik [EMAIL PROTECTED] wrote: This (and what Jim said a few minutes ago) is consistent with my understanding of the current situation. I just made changes to the proposal on Wiki to reflect that DB PMC is a sponsor. See this link with highlighted changes: http://objectstyle.org/confluence/pages/diffpages.action? pageId=1121originalId=1120 So if now the vote moves to DB, what mailing list is it going to be on? [EMAIL PROTECTED], or is there another PMC list? Andrus First, the Cayenne community should vote among themselves to affirm that they would be willing to join DB. Then, someone in the DB PMC can call for the vote there. Once the DB vote passes, then you can announce the vote on general@, and proceed from there. (See, for example, the Struts/Webwork2 process.) But, we don't want to start out by having one or two individuals make unilateral decisions for the community. -Ted. - 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] - 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: site frustration
you needed ant anyway William A. Rowe, Jr. wrote: Jean T. Anderson wrote: The incubator site has a build.sh at http://svn.apache.org/repos/asf/infrastructure/site/trunk/build.sh This appeared with an svn up, thank you for the pointer Jean :) (After, of course, I surrendered and got ant configured lol) - 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: site frustration
excellent. Soon you can check in harmony :) actually, w/ the J9 VM from IBM under the eval license, Harmony will already run ant an velocity to build anakia-based sites :) Justin Erenkrantz wrote: On 3/1/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: you needed ant anyway Nah, we checked it into the incubator site dir. The only thing you should need is a JVM. Requiring anything else is a bug. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cayenne ASF Proposal
please post the actual proposal to the list, not just a URL thanks Andrus Adamchik wrote: Hi folks, We at Cayenne project (http://objectstyle.org/cayenne) would like to join Apache. We wrote a proposal draft that can be viewed here: http://objectstyle.org/confluence/display/CAY/ASF+Proposal Brian McCallister volunteered to help us as a mentor. And now we need a Sponsor. I understand that for TLP a sponsor must be either Incubator PMC or the ASF Board. I am asking for advice on how we can go about that. Thanks Andrus -- Andrei (aka Andrus) Adamchik Cayenne Persistence Framework Lead Architect http://objectstyle.org/cayenne/ - 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: Cayenne ASF Proposal
Ah, I see Leo did... Geir Magnusson Jr wrote: please post the actual proposal to the list, not just a URL thanks Andrus Adamchik wrote: Hi folks, We at Cayenne project (http://objectstyle.org/cayenne) would like to join Apache. We wrote a proposal draft that can be viewed here: http://objectstyle.org/confluence/display/CAY/ASF+Proposal Brian McCallister volunteered to help us as a mentor. And now we need a Sponsor. I understand that for TLP a sponsor must be either Incubator PMC or the ASF Board. I am asking for advice on how we can go about that. Thanks Andrus -- Andrei (aka Andrus) Adamchik Cayenne Persistence Framework Lead Architect http://objectstyle.org/cayenne/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] @domain for Incubator mailing lists
I think that this is the longest active running [vote] thread on an apache list of all time... It was started on Sun, 18 Dec 2005 04:49:14 GMT Noel, can you please tally the votes? :) Davanum Srinivas wrote: +1 On 2/21/06, Rodent of Unusual Size [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Noel J. Bergman wrote: Please vote on the following: New mailing lists should be created under the @incubator.apache.org domain, just as all of the other project resources, e.g., the web site and SVN subtree. +1 - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ/t5O5rNPMCpn3XdAQLf2AQAutLOyRd07SLVhAbzA0D6bfGpkBMHJwLd X8KPEEZzwFMJpCGZkSu0sSJoGqu0GoBbe18oaIKMD2nsO3jSCl/7Jw/dThOXcrWY 7BQt/adiNUVP9LkcS5zKYrBQ0cUp1ejIt5Bnynkjk5t1gmbv/Gl0Hunph0HXuHph deELlj217hU= =PD70 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - 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: Account requests for Incubator projects
Why not just modify incubator procedure to make it clear that 1) Mentors make the requests and 2) They sign the email w/ the title $PODLING_NAME Mentor Now #2 don't prevent someone from misrepresenting themselves - which would have to be dealt with - but rather it allows us to not act on but simply reply back to those that ask for accounts w/o representing themselves as mentors... geir Erik Abele wrote: On 21.02.2006, at 21:18, Noel J. Bergman wrote: Infrastructure, All projects in the Incubator are managed by the Incubator PMC. All Mentors are Incubator PMC members (see committee info if in doubt). Requests for infrastructure and accounts should be coming from those Mentors, and should be cc'd to the Incubator PMC, so that it can maintain oversight. Hmm, while this makes sense it also makes it very hard to recognize valid requestors. The Incubator PMC membership is not always a long-term relationship and so root@ (et al) will have to find out about new mentors in some easy way. For example there's this account request from Don Brown [EMAIL PROTECTED] from today - it's not easily possible to find out if he is supposed to be in charge of that - there's nothing on the PMC list and there's just one vote thread covering the proposal on the public list, nothing else... so how are we supposed to find out if he is a mentor for some poddling? (And btw, I don't think it is efficient to dig mailing list archives on every incubator request but that's the only possibilty right now, the website isn't up2date in this regard.) Cheers, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Proposal for Apache Ode
Sounds like Jim is volunteering :) Jim Jagielski wrote: On Feb 17, 2006, at 11:02 PM, Davanum Srinivas wrote: = MENTORS = These individuals will participate as Incubator Mentors * Geir Magnusson Jr. * Davanum Srinivas * James Strachan I am +1 on the proposal, but am simply curious if the above 3 people actually have the time to adequately mentor this? - 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: Ode / BPEL Donation of BPEL 2.0 Engine
Sanjiva Weerawarana wrote: I totally agree these codebases are large and complicated (remember I was the one who was surprised how fast people found that the Sybase codebase was nice and cool). If you really think the best solution is not to force them to merge then let's not go down the single project incubation path. That's a path that'll guarantee that the project will never graduate IMO. I have no problem saying we're going to incubate three different BPEL impls at the same time, but I am sure everyone realizes the reality that that's likely to mean none of them will really capture a dominant place in the world simply because 3's just too many. I guess that's fine too. If we reversed course and went with multiple, I think that Darwin would lend a hand there, so to speak. Code mergers and community consolidation between the like-minded and the willing will take place, and obviously there will be competition for users, contributors and mindshare. From what I understand to the goal of tight embedding of SybaseBPEL to the ServiceMix JBI container, it plays to a different audience - one that wants to use JBI, and have BPEL included, versus people who wish to use BPEL independently from any given service container or management system. Both are legitimate technical objectives IMO. I'm interested in working on the latter. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ode proposal
incubator.apache.org Alan D. Cabrera wrote: Sorry, that's what I meant. What are the domains for the lists? Davanum Srinivas wrote, On 2/17/2006 1:19 PM: harmony-ppmc...Also dont' forget to change the domains for the lists.. -- dims On 2/17/06, Alan D. Cabrera [EMAIL PROTECTED] wrote: Davanum Srinivas wrote, On 2/17/2006 12:01 PM: Hmm...Can we apply the same criteria to *ALL* committers (including those listed in the status page now?) One more question, Since Noel (as the PMC Chair) talked about Incubator pmc sponsoring this, can we please reflect that and ask for a ppmc mailing list as well? Cool. Will do. What's the format of the ppmc mailing lists? Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ATTN: ODE *Please read*
Maybe I missed the mail, but the final draft of the proposal for Ode was never posted anywhere for Incubator PMC consideration. Can we please have this done so that we at least have it in the incubator mail archive (rather than written in chalk on the sidewalk aka the wiki) geir Noel J. Bergman wrote: The mailing lists are setup. Would everyone interested please move discussion to the new mailing lists? To subscribe: [EMAIL PROTECTED] To send mail: [EMAIL PROTECTED] Ismael. if you would please do so and repost your excellent set of questions, that would be great. :-) --- 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: Ode / BPEL Donation of BPEL 2.0 Engine
Could I presume to suggest something as obvious as Apache BPEL or similar? makes it easier for people to grok what we're doing. I know it's not terribly imaginative, but might make it easy for people to recognize it as a BPEL project. (Like ActiveBPEL) geir Noel J. Bergman wrote: Bill and Ismael, Do be clear, as I understand it from comments such as: Ismael: Intalio [working] alongside Sybase Bill Flood: My preference is simply that we apply our combined talent to work towards something greater than the sum of the parts. and from a telephone call with Bill, the desire on the part of both donors is to have a single project, rather than two separate ones, which will start from both codebases, and work together with others on a union. FWIW, comments that I have received in the past day indicate a great deal of excitement about this possibility, so hopefully something really great will be the payoff from the initial angst. Is there a consensus to call this joint project Ode? If so, we can go ahead with that. Else, if you wanted we could start with bpel-wg-dev@, so that you can immediately start, and leave Ode available for use later at graduation or if there arises a later desire to have separate PXE and Ode projects. I prefer, as it seems both of you do, the joint community. Just asking the question. --- 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: Ode Proposal
The Geronimo PMC needs to vote on sponsoring this. Before you do that, just to start the discussion : - Why would the Geronimo PMC sponsor this? - Isn't BPEL a bit far afield from J2EE, which is our charter as a PMC? - How about bringing it to Agila, which already has a good start on BPEL and workflow, and take the best from the Sybase contribution and the best from Twister and combine? Alan D. Cabrera wrote: Ok. Here's the proposal http://wiki.apache.org/incubator/OdeProposal. Please feel free to comment. Bill Flood, can you provide us with the list of Sybase developers that wish to work on this project? Can you get the Software Grant paperwork faxed in? Any other ASF committers want to jump in? We need some more mentors. Anyone? This is not meant to stop discussions about this donation, just to start the bureaucratic machinery while they take place. Regards, Alan - 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]
[Fwd: Re: Ode Proposal]
Was cross-posted originally and I didn't on my reply... Original Message Subject: Re: Ode Proposal Date: Tue, 14 Feb 2006 10:54:47 -0500 From: Geir Magnusson Jr [EMAIL PROTECTED] Reply-To: dev@geronimo.apache.org, [EMAIL PROTECTED] To: dev@geronimo.apache.org References: [EMAIL PROTECTED] Wasn't it offered already to ServiceMix? I mean, people already voted on accepting the code, so I assume it's available somewhere... geir [EMAIL PROTECTED] wrote: Great! I'm assuming the source won't be available for review unless/until Ode is accepted as an incubator poddling? Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 James Strachan [EMAIL PROTECTED]To: dev@geronimo.apache.org mail.comcc: general@incubator.apache.org, servicemix-dev@geronimo.apache.org Subject: Re: Ode Proposal 02/14/2006 10:10 AM Please respond to dev On 14 Feb 2006, at 15:03, [EMAIL PROTECTED] wrote: Allan, This proposal appears to be gear towards the web services/SOA community. Is support for orchestration of non-WS business processes considered out of scope for Ode? No - the code should be reusable for most orchestration needs; even in cases where there are no pointy brackets involved :). James --- http://radio.weblogs.com/0112098/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Why not just bring into Agila and work on it in there? Bill Flood wrote: Dims, We heard your plea and have moved the proposal through the incubator as you suggested. At this point, we are looking for supporters. From the energy you put behind your posting, we are all hoping you will also be committed to helping us drive this forward. We are also reaching out to the Agila folks and anyone else who wishes to get involved. http://wiki.apache.org/incubator/OdeProposal Best, Bill On 2/3/06, Davanum Srinivas [EMAIL PROTECTED] wrote: *IF* that is the objective, then the correct way is to follow the Apache Incubator process(es) draw up a proposal, name *ALL* the committers in servicemix who are willing to contribute, add your own team names, post the proposal to the [EMAIL PROTECTED] mailing list. Ask for more people to join, Proactively invite other folks (from Apache and outside Apache as well) to join, seek active support of exising Apache folks who may be interested in joining a BPEL implementation. For god's sake just check the list of people who wrote the original BPEL spec and compare it to the people who work at Apache on web services related stuff and u will see what i mean. thanks, dims On 2/3/06, Bill Flood [EMAIL PROTECTED] wrote: The dependency on Axis should be removed. It's the result of a couple lines of dead code. BPEL 2.0 is an objective. The discussion over where the contribution lands is one of the most important aspects of the process. Too narrow a scope and the project could fail to get critical mass, too wide and folks are worried about the kitchen sink. If we can find the right balance we will be well served. We are not hardwired to any one particular approach and welcome involvement from all corners. The ServiceMix approach has a few positives - by in large they seem to like our contribution and they have critical mass. On 2/3/06, Davanum Srinivas [EMAIL PROTECTED] wrote: I was determined to stay of this, but alas! i could resist asking this: Would you be ok to having a stand alone project with committers from servicemix, your team, people from other backgrounds (could be existing ws committers) working on this code base, bring it up to say BPEL 2.0 from BPEL1.1, upgrade it to say Axis2 from Axis 1.3 etc.etc...OR are u insisting that this code has to go into servicemix and nowhere else... If it is the latter, why? If it is the former, why is there so much resistance? As they say, i'll take your answers off the air. thanks, dims On 2/3/06, Bill Flood [EMAIL PROTECTED] wrote: Dims, I'll take Cory off the hook since he was acting in good faith on behalf of Sybase :-). As we are learning, there are a variety of ways to work within the Apache process as long as the community is supportive. From the Sybase perspective, we are interested in working with a vibrant community in a meaningful way that balances the needs of the community with that of our own. when we first started thinking about the open source path, we looked at Agila and communicated with the developers. While the Agila developers were quite helpful, the project was not open to our contribution and our assessment was that their existing code line would take substantial work to bring it up to where we thought we already were. When we looked at ServiceMix, we found a mature community that not only appeared open to a contribution such as ours but one which would help us establish a good affinity with the ESB. The Sybase folks working on this code line will continue to vigorously support the orchestration component and provide help in adjacent areas related to SCA. At this point, we feel comfortable in our contribution to the ServiceMix project based on the positive uptake. Under the rules of meritocracy, we will work to ensure that the interfaces remain clean and the build granular enough to be reused and hope to work with you in the future. Best Regards, Bill ---Original Message--- From: Davanum Srinivas [EMAIL PROTECTED] Subject: Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project) Sent: 02 Feb '06 21:12 Cory, Could you please get James' help and draft a complete proposal? Please see http://www.google.com/search?hl=enlr=safe=offq=incubator+proposal+site%3Awiki.apache.orgbtnG=Search for a list of proposals, their format and their content. Once the proposal is ready, please post it to [EMAIL PROTECTED] Also, please take a peek at the documentation on the http://incubator.apache.org/ site especially w.r.t to the incubation process, what to expect and steps involved. thanks, dims On 2/2/06, cory [EMAIL PROTECTED] wrote: Hi, BPEL 1.1 is supported. The code works with Axis 1.3. Sybase wants this code to be successful within the community and is going to work to support it. Cheers, -cory On 2/2/06, Davanum Srinivas [EMAIL
Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Bill Flood wrote: Geir, approaching Agila was our first avenue. We looked at what they had and I initiated several conversations about donating to that incubator project. We offered a base line upon which to build but there did not seem to be any uptake although both committers said they were happy to have us come in and provide coding help on what they already had. I don't really know. I wasn't part of that conversation, although I did have a few discussions w/ people after this all started. I expect that what you just said might have been the problem. They already had a BPEL engine, and it sounds like you were suggesting they stop and reboot on your codebase. After all, they have some users and wouldn't want to just drop them. I was a little mystified. Jumping in and bringing their stuff up to where we already were seemed counter productive given the large gap in code maturity and capability so we passed. Based on the support we have seen for our contribution from others in Apache thus far, I have to believe that our impression wasn't just the result of our inherent subjectivity I believe we did approach them in good faith and I'm not sure why there was disinterest in our offer via Agila but here we are. We left the previous conversation on good terms. At this point, my preference would be that the Agila folks look at the contribution and see if they want to become part of that larger community for this new baseline. To me, it's not about ownership, it's about critical mass in the community to carry something forward. How about making a fresh start then... If the Agila people are interested, put out a call for any and all other implementations of BPEL that might be donated and build a larger community, mixing the best of anything that is donated to get the best BPEL engine and community we can? In the same way that we built Geronimo from best of breed J2EE-ish OSS projects that are out there, I'm sure we could do a similar thing with BPEL. Maybe do a bake off to help find the best codebase, and have the community collaborate around that? (I'm not sure what that would entail, actually...) Would you be interested in that? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Bill Flood wrote: I'm open to what works best. I think the proposal for Ode is in essence a fresh starting point for a community. Sybase just happened to submit some code, which may or may not be accepted and that we thought was passable. In the end, the community has the last say so we welcome that type of open discussion. That's why I'm bringing it up here :) Good luck with it. geir On 2/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Bill Flood wrote: Geir, approaching Agila was our first avenue. We looked at what they had and I initiated several conversations about donating to that incubator project. We offered a base line upon which to build but there did not seem to be any uptake although both committers said they were happy to have us come in and provide coding help on what they already had. I don't really know. I wasn't part of that conversation, although I did have a few discussions w/ people after this all started. I expect that what you just said might have been the problem. They already had a BPEL engine, and it sounds like you were suggesting they stop and reboot on your codebase. After all, they have some users and wouldn't want to just drop them. I was a little mystified. Jumping in and bringing their stuff up to where we already were seemed counter productive given the large gap in code maturity and capability so we passed. Based on the support we have seen for our contribution from others in Apache thus far, I have to believe that our impression wasn't just the result of our inherent subjectivity I believe we did approach them in good faith and I'm not sure why there was disinterest in our offer via Agila but here we are. We left the previous conversation on good terms. At this point, my preference would be that the Agila folks look at the contribution and see if they want to become part of that larger community for this new baseline. To me, it's not about ownership, it's about critical mass in the community to carry something forward. How about making a fresh start then... If the Agila people are interested, put out a call for any and all other implementations of BPEL that might be donated and build a larger community, mixing the best of anything that is donated to get the best BPEL engine and community we can? In the same way that we built Geronimo from best of breed J2EE-ish OSS projects that are out there, I'm sure we could do a similar thing with BPEL. Maybe do a bake off to help find the best codebase, and have the community collaborate around that? (I'm not sure what that would entail, actually...) Would you be interested in that? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Lance Waterman wrote: As one of the Sybase BPEL developers, this certainly sounds reasonable to me. Perhaps we can start a discussion around what the bake off criteria will look like ( i.e. what BPEL constructs are fully/half/not supported, what set of unit tests should be supported, etc ... ). As an example; in looking through the Agila code ( which could have rendered faulty assumptions ) it appears that the BPEL Scope construct is not currently supported. I rate Scope as quite important to have in a BPEL implementation and its not a simple thing to implement. Likewise, I am sure there are criteria that the Sybase donated engine does not fully measure against. While I'm not sure how far along the BPEL engine in Agila is (Twister), I wouldn't be surprised if it wasn't at the same level of completeness as your implementation. geir Lance On 2/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Bill Flood wrote: Geir, approaching Agila was our first avenue. We looked at what they had and I initiated several conversations about donating to that incubator project. We offered a base line upon which to build but there did not seem to be any uptake although both committers said they were happy to have us come in and provide coding help on what they already had. I don't really know. I wasn't part of that conversation, although I did have a few discussions w/ people after this all started. I expect that what you just said might have been the problem. They already had a BPEL engine, and it sounds like you were suggesting they stop and reboot on your codebase. After all, they have some users and wouldn't want to just drop them. I was a little mystified. Jumping in and bringing their stuff up to where we already were seemed counter productive given the large gap in code maturity and capability so we passed. Based on the support we have seen for our contribution from others in Apache thus far, I have to believe that our impression wasn't just the result of our inherent subjectivity I believe we did approach them in good faith and I'm not sure why there was disinterest in our offer via Agila but here we are. We left the previous conversation on good terms. At this point, my preference would be that the Agila folks look at the contribution and see if they want to become part of that larger community for this new baseline. To me, it's not about ownership, it's about critical mass in the community to carry something forward. How about making a fresh start then... If the Agila people are interested, put out a call for any and all other implementations of BPEL that might be donated and build a larger community, mixing the best of anything that is donated to get the best BPEL engine and community we can? In the same way that we built Geronimo from best of breed J2EE-ish OSS projects that are out there, I'm sure we could do a similar thing with BPEL. Maybe do a bake off to help find the best codebase, and have the community collaborate around that? (I'm not sure what that would entail, actually...) Would you be interested in that? geir - 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: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Aaron Mulder wrote: On 2/14/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: In the same way that we built Geronimo from best of breed J2EE-ish OSS projects that are out there, I'm sure we could do a similar thing with BPEL. Maybe do a bake off to help find the best codebase, and have the community collaborate around that? (I'm not sure what that would entail, actually...) Geir, I don't understand this at all. In different threads you seem to be simultaneously talking about bringing it to Agila, bringing it to ServiceMix, having the Geronimo PMC vote on it, and now you're recommending a bake-off where no one does anything with any code until the one true way emerges? I don't know if you've been following this closely, but originally it was suggested that the Sybase engine go to ServiceMix (hence the bringing it to ServiceMix part), which would require the vote of the Geronimo PMC (which is in fact what James did). Today, we were introduced to the ODE Proposal, which is a new podling proposal that is to be sponsored by the Geronimo PMC (hence my question about a vote about that since it would be yet another podling sponsored and overseen by the Geronimo PMC, and we hadn't voted on it), and I wondered if there was interest/synergy w/ the Agila podling, which is already working on an implementation of a BPEL orchestration engine. I hope that clears up the confusion for the first three elements of the above. As for the bake off, I'm not recommending anything - I was asking if it made sense to see what kind of broader community could be assembled around this, without presuming the primacy of one codebase - choosing the best of what shows up. If you've been following the whole soap opera for the past week or so, you might recall that there was considerable concern from various members of the ASF community regarding this subject, with the suggestion (from greg) that we should Erase the lines and create a community that can work on something with a cooperative atmosphere. I won't speculate on your motives, but this strikes me as an... unusual approach. What strikes you as unusual? Bringing multiple groups together to work on a given technology? My motive is to try and get rid of some of the cloud of bad karma thats hanging over this whole discussion because it's the last thing the Geronimo project needs right now. It's also not good for the new people that wish to join our community, the Sybasians. (Sybasers?) I also think that BPEL is an interesting technology and I would like to see a community flourish around a great implementation here at the ASF. What's your motive? Also, I don't at all agree with your comparison of a BPEL Engine to Geronimo. I would compare it to the transaction manager within Geronimo. It's a discrete component, and we're not going to take the best of 20 different projects to make a transaction manager, and I don't see why we'd do the same to make a BPEL Engine. Ok. I'll be the first to admit that I'm no expert on BPEL implementations, but I certainly wouldn't suggest that we'd try to take 20. However, could you imagine taking a few and finding the best aspects of each? Are they really that monolithic that you can't find component parts that you could blend together to make something better? What about clustering? What about management or tooling? Support for different versions of BPEL? How about service hosting? Do they have a container (like PXE) or can they be used to orchestrate external containers (say a mix of services deployed though a heterogeneous environment, say w/ Geronimo, Tuscany and Axis+Tomcat (I dunno...), with the BPEL engine just deployed into Jetty? If anything, the JBI container is like Geronimo, and the BPEL Engine is like the Transaction Manager, and note (everyone) what happened there. We didn't create a separate projects for the transaction manager, we just build a good one in Geronimo and made it intelligently portable. Then, when someone had a fancy to use it in Spring without the rest of Geronimo, they created Jencks, and now we have a standalone projects for that purpose and the best of both worlds, but it was born by putting the code in the container where it would be used, making it solid and portable there, and building outward. Hey - I'm not going to pretend to be an expert on BPEL orchestration systems, so I guess I'll take your word for it that it's like a monolithic transaction manager. In the past, I've built production workflow systems (not BPEL, more like a JMS-driven SOA) that weren't at all monolithic - they got a bit complicated, actually, so that's what's driving my understanding of what a full BPEL orchestration system should be like. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BPEL contribution from Sybase
was there some crosspost dropped here? Mads Toftum wrote: On Mon, Feb 13, 2006 at 02:19:56PM -0800, Dain Sundstrom wrote: If any project inside or outside of Apache wants their own copy of this code to develop they can always fork the code (as is allowed by any open source project). Whoa! Are you actively suggesting forks inside the same community? code duplication and competition between tlps? Somehow that doesn't sound like something that should happen within the ASF - and certainly another point in favor of Ken's suggestion of keeping it outside servicemix. vh Mads Toftum - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
Sanjiva Weerawarana wrote: On Tue, 2006-02-07 at 14:54 +0100, Jochen Wiedmann wrote: What happened to the Starting a java specs project thread? Um, probably the same thing that happens to many threads- like a firework .. goes up with heat, blows up in great color and then falls down silently .. ;-). ... while raining bits of ash and unburnt toxic material on the unsuspecting people below... geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CCLA
Alan D. Cabrera wrote: The requirement for iCLAs is pretty straightforward. What is the rule for requiring CCLAs? For the actual CCLA, no requirement - it's there for employees to use to ensure that they have clear ability to participate from the POV of their employer. IOW, CYA. How do I, on the Apache side, perform due diligence? For what? Do I just point the candidates to the license page and ask them to carefully read the material? yes - the system already requires the ICLA to be in place, and that is all that is required by the ASF for individual participation. geir Regards, Alan - 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: [website] Note a bunch of changes
All thanks go to David. At best, I just kicked a pebble down a hill... geir Leo Simons wrote: Oi! For those who don't read the incubator cvs list, I just spent a few hours on the incubator website. Mostly it was a large amount of small tweaks, fixes and changes; no (serious) content changes except for a bit of a rewrite of the text on the front page. Please do review and change (back) the bits you don't like :-) David, Geir, et al, thanks again for doing so much of the hard work; the workflow for this stuff is much more enjoyable now! cheers, Leo - 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: [VOTE-RESULT] KabukiProposal - PASSED
I realize this is late, but I've been momentarily buried, and because I had also asked that Sam restart the vote, I'd like to symbolically add my +1 to the proposal. geir Sam Ruby wrote: Even though it is only symbolic at this point, I will express my +1 on this proposal. Without delving into the binding/non-binding aspects, this vote has gone on for the customary 72 hours, and clearly passed: +1 Leo Simons +1 Davanum Srinivas +1 Andrew Clark -0.9 Raphaël Luta +1 Martin van den Bemt +1 Justin Erenkrantz +1 Noel J. Berman +1 Sanjiva Weerawarana +1 Sam Ruby - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator site status wrt a move to Anakia?
thx David Crossley wrote: Geir Magnusson Jr wrote: I thought there would be xdocs from the cwiki I could grab - otherwise, I need to convert the html to xdoc. I will 'svn ci' my generated xdocs into site/xdocs2 It would be good if some other people can look over the new source docs and the Anakia side of things. The more that we can get the forrest export to do the better. However we need to trade that off with getting this job done quickly. -David - 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: Incubator site status wrt a move to Anakia?
I thought there would be xdocs from the cwiki I could grab - otherwise, I need to convert the html to xdoc. geir David Crossley wrote: Geir Magnusson Jr wrote: This is great. I've been A-B testing with the example I put on ~geir and things look good. I think some of my hand-done pages look better but that's because a) I did them by hand and b) I ain't gonna admit I was showed up by no fancy machine! :-) We can still do hand-tweaking later of course. Seriously - the cwiki pages were the last bit, I think - is there a place I can find those and try them? Sorry i don't understand what you mean. The current sources are at site-author/projects/*.cwiki Match them with ~crossley/.../projects/*.html -David - 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: [VOTE] Werner as juice committer
feel free to kick me in the head if this is a settled issue, but why is this being done in public since it's about a person? This has nothing to do with Werner or the project - just wondering... geir Davanum Srinivas wrote: As part of reviving juice, can we please VOTE werner as a committer to enable him to continue his offline work? [1] Here's my +1. thanks, dims [1] : http://www.nabble.com/Status-of-my-upgrades-and-so-on-t945224.html -- Davanum Srinivas : http://wso2.com/blogs/ - 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: [VOTE] AJAX Toolkit Proposal - Updated (Again)
Could you please just restart the vote? AND, given the chatter and discussion, could you post the final proposal to the mail list again for a vote? I'm not trying to slow this down, but after all the muss and fuss, 3 more days won't kill it, and it will be clearer (at least to me...) to have what we're actually voting on in the archives. Just my 0.02 geir Sam Ruby wrote: When I originally kicked off this vote, I specified today, midnight, as the 72-hour-and-then-some deadline. Since then the proposal got a substantial revision (in particular, a new name) on Tuesday afternoon, so extending this a few hours to 4PM PST seems in order. I believe that the current wiki page: http://wiki.apache.org/incubator/KabukiProposal addresses all if not most of the concerns expressed by Roy, Leo, and Erik, each of which had expressed an explicit -1, and would be very interested to hear if this is in fact the case or if there are second order concerns that need to be brought forward. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal for OFBiz to Join the ASF
Noel J. Bergman wrote: Geir Magnusson Jr wrote: Can we please have things go to the mail list, as that should be the 'primary institutional memory' of the incubator community. +1 But let's try to say such things to be educational, not chastising. Sorry. The wiki made me do it :) I hope David's been around enough to understand I didn't intend to chasten. I suspect he was following recent examples (and I should have said something sooner...) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator site status wrt a move to Anakia?
This is great. I've been A-B testing with the example I put on ~geir and things look good. I think some of my hand-done pages look better but that's because a) I did them by hand and b) I ain't gonna admit I was showed up by no fancy machine! Seriously - the cwiki pages were the last bit, I think - is there a place I can find those and try them? geir David Crossley wrote: Here is the result of my experiment ... [1] http://people.apache.org/~crossley/incubator-anakia/ The existing Incubator site was converted to Anakia xdoc format. I used a local copy of Geir's previous experiment [2] but with the forrest-generated anakia xdocs. We can tweak the Forrest plugin to match any changes in Geir's xdoc format and stylesheets. Anakia didn't report any errors with the final run. However, please look out for any strangeness. All the filenames and directories are the same as the existing Incubator site. So existing URLs are maintained. As with Geir's, i dropped the learn directory. The projects/*.cwiki files are all converted. If any documents were not linked in to the existing site then they will be missing. Also other resources will be missing. For example, i needed to manually retrieve a local image at Process_Description.html and if there were any directly linked PDF docs then they will be missing. This can be manually fixed later. There is still a strange situation with extra documents in sub-directories of site-author/projects/ e.g. agila, activemq, servicemix ... these seem to be project websites which are supposed to be elsewhere in the Incubator SVN. There is also some additional stuff in geronimo. None of these documents are in the new site. I did a quick 'diff -rq' on people.apache.org and there are differences. Someone should investigate further. The conversion process can be run at anytime. It might take us a while to decide, etc. Now don't let any of this stop you from editing the current sources in site-author, especially in site-author/projects status reports. We can convert again at any time. This site transformation was done with trunk of Forrest (after i check some stuff in). I could check in new commented config to Incubator and describe how to do it. Lets wait a bit. Thanks to the Forrest project for the new abilities. Good result. [1] http://people.apache.org/~crossley/incubator-anakia/ [2] http://marc.theaimsgroup.com/?l=incubator-generalm=113612265423731 Experiment : Incubator site done in xdocs... -David - 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 for OFBiz to Join the ASF
Jacopo Cappellato wrote: Hi Geir (and all), my name is Jacopo Cappellato, I'm one of the developers of the OFBiz project and, as you can imagine, I'm very interested in your feedback about our request to join the ASF Incubator. About the proposal posted to the Wiki instead of to this list... well if you go to the first post in this thread you'll find a mail from David Jones with the proposal attached (in PDF format). The document has essentially the same content of the Wiki page, only the proposed sponsor is different (based on feedback from this list, we are now asking that the Incubator PMC be our sponsor). Of course, we have no problems to repost to the list an updated PDF version as well, if PDF is good for you (and we'll probably do this if there are no more comments from this list that we should take into account). Hi Jacopo, First and most importantly, welcome! :) The following is my personal opinion, and shouldn't in any way be assumed to be Incubator Policy. Personally, I do like PDF but it still is one step away from LCD and makes it a *little* harder, for example for people who use non-GUI tools or on cellphones and such (I do get work mail to a phone, and I do have a PDF reader on it, but I think that I'm in a small minority...) It also makes searching mail content harder - you couldn't take an incubator archive mbox and grep for something. (Yes, modern tools will open and digest it, but use of those tools is more the exception than the norm...). Also, if you were keeping revisions of the docs in something like SVN, diffs would be easier. For example, you talk about how the PDF is essentially the same. If they were two emails, I could diff them. Now, w/ a PDF and a wiki page, one would have to examine the two manually to know the difference. Anyway, enough of a rant on this. Thanks for getting involved in this. The ASF is a fun place. really :) geir Thanks for your time and suggestions, Jacopo Geir Magnusson Jr wrote: Is this becoming the current de-facto process, posting to a wiki? (or @)#!)#@ wiki, as I tend to think of them...) Can we please have things go to the mail list, as that should be the 'primary institutional memory' of the incubator community. Feel free to also have on a wiki for collaboration to get it done, but after that, the final proposal should, IMO, go to the mail list. Does anyone else feel this way? Mail archives will live for years in distributed places. Wiki's seem to be single-sourced and a lot more ephemeral geir David N. Welton wrote: David N. Welton wrote: I guess it should be placed on the wiki? I'll do that later today if no one else beats me to it. Here we go: http://wiki.apache.org/incubator/OFBizProposal I changed the proposed sponsor to the Incubator PMC, as that's apparently the done thing. Ciao, - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
how about AJAX? :) Yoav Shapira wrote: Hola, I'll chime in with some name ideas just for consideration ;) And fwiw, I like 'Jambaloo' as a name but probably that's just me ;-) Mmm, yeah, maybe that's just you ;) natural preference towards Japanese names, though, so I'll suggest Kabuki. :) Kabuki is not bad, though somewhat old-fashioned, no? Here are a couple of Japanese ones: - abarenbo (a hooligan ;)) - aite (the person/entity with which you share something: nice for AJAX since it does depend on some server-side stuff, whatever language you choose) - gumbai (ancient, hand-crafted fan used by sumo referees, and yes, most of my knowledge of japanese comes from being a sumo fan) - haru (spring, as in rebirth) - ketsudan (determination) - yukata (summer kimono, connotation of lightweight, airy...) -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator site status wrt a move to Anakia?
I thought all of it was pretty much done except for the project pages in cwiki, but you said those are HTML, so just waiting for a shipment of Round Tuits Sounds cool, though. geir David Crossley wrote: David Crossley wrote: I am investigating creating a Forrest output plugin to do the complete conversion. If Geir or others come up with another solution then fine, this will still be a useful tool for Forrest. Update: We now have a Forrest output plugin working to generate Anakia xdocs from the current Incubator site. Needs more work on the plugin to transform the output and adjust some xml attributes. We should be able to do a repeatable process. So the rest of you keep on editing content. Later we will do a batch conversion. -David - 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 for OFBiz to Join the ASF
Is this becoming the current de-facto process, posting to a wiki? (or @)#!)#@ wiki, as I tend to think of them...) Can we please have things go to the mail list, as that should be the 'primary institutional memory' of the incubator community. Feel free to also have on a wiki for collaboration to get it done, but after that, the final proposal should, IMO, go to the mail list. Does anyone else feel this way? Mail archives will live for years in distributed places. Wiki's seem to be single-sourced and a lot more ephemeral geir David N. Welton wrote: David N. Welton wrote: I guess it should be placed on the wiki? I'll do that later today if no one else beats me to it. Here we go: http://wiki.apache.org/incubator/OFBizProposal I changed the proposed sponsor to the Incubator PMC, as that's apparently the done thing. Ciao, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator site status wrt a move to Anakia?
David Crossley wrote: Geir Magnusson Jr wrote: I thought all of it was pretty much done except for the project pages in cwiki, but you said those are HTML, so just waiting for a shipment of Round Tuits Yes but Anakia doesn't deal with HTML, does it? Right - so I have to convert them all... I am not sure what you were waiting for. I think that we were all expecting for you to continue. My shipment of Round Tuits was delayed. Others can pitch in though :) Like i said in another thread, don't wait for me to provide a solution. Anyway i have fast-tracked my work because the delays cannot be sustained. Sounds cool, though. Yes i am really pleased with the new Forrest ability. -David geir David Crossley wrote: David Crossley wrote: I am investigating creating a Forrest output plugin to do the complete conversion. If Geir or others come up with another solution then fine, this will still be a useful tool for Forrest. Update: We now have a Forrest output plugin working to generate Anakia xdocs from the current Incubator site. Needs more work on the plugin to transform the output and adjust some xml attributes. We should be able to do a repeatable process. So the rest of you keep on editing content. Later we will do a batch conversion. -David - 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: Experiment : Incubator site done in xdocs...
David Crossley wrote: What is happening now? There was a flurry of +1 from PMC members. What is the next step in moving to Anakia? I was going to do the /project docs (as they seem to be critical). At that point, I think all is there, and we could go forward. I may be inspired today to put in a little block of time to just get that done. I figure they don't have to be perfect - each podling can nip and tuck to fix any minor errors that happened. geir -David Geir Magnusson Jr wrote: I realize that many might have checked-out of this thread about 200 messages ago... if there's any interest or comment... (Note, this is just an experiment) Original Message Subject: Re: [RT] Super Simple Site Generation Tool Date: Sun, 01 Jan 2006 03:39:35 -0500 From: Geir Magnusson Jr [EMAIL PROTECTED] Reply-To: general@incubator.apache.org, [EMAIL PROTECTED] To: general@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] Roy T. Fielding wrote: [SNIP] I don't see any point in having this conversation every year. Whoever is willing to fix the content on incubator, please feel free to remove the entire site (except the project status files) and start over with whatever tool you deem suitable. I have four other sites to work on that have higher priority, so chances are good that I won't be deleting the incubator site any time soon. Out of some sense of insomnia-driven inquisitiveness, I converted a good bit of the site to xdoc/Anakia. It took about 2.5 hours or so. http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/site/ It's not done. I have to convert all the project stuff - I didn't have the internal fortitude and wherewithal to face cwiki - and there's a few other odds and ends. It became clear that we need to rework some of the content. If you want to see it : http://people.apache.org/~geirm/incubator/ Happy New Year geir - 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: Collecting Proposed changes
Davanum Srinivas wrote: Brett, Let's take Tuscany, If the WS PMC had voted on the proposal before it hit [EMAIL PROTECTED], it would have probably passed the pmc VOTE. No - if the WS PMC was actually sponsoring it, it wouldn't need a PMC vote. and incubator would have had to accept it as-is. however fortunately, the proposal was sent directly to [EMAIL PROTECTED] and Roy (and others) had quite a few problems with it which got fixed. So it was a good decision in hind sight that the people who proposed tuscany went to [EMAIL PROTECTED] first. Because it wasn't a WS-sponsored project. I still don't think it needs to be WS sponsored :) geir thanks, dims On 1/2/06, Brett Porter [EMAIL PROTECTED] wrote: Some thoughts: # [ ] - Any proposal should hit [EMAIL PROTECTED] first, No PR before that. # [ ] - Any PR should be vetted by PRC, No Excuses. Agree, for the Apache side of things. I'm not sure we can stop companies doing what they are going to do, but we can certainly say that that they shouldn't be doing so and list the reasons why (because it mighr not be accepted, might have a different name, etc). Also, please define PR. Recent examples seem to think that an individual member of the proposal's personal blog is PR, which I'm not sure I agree with. # [ ] - A sponsoring PMC should hold their VOTE to sponsor a proposal or IP Clearance 72 hours *AFTER* it is posted on [EMAIL PROTECTED] Seems back to front to me. How can you propose anything to the incubator that you haven't decided you want to do? - Brett On 1/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, Please review the items here: http://wiki.apache.org/incubator/ProposedChanges Please feel free to add/modify/delete or start a new thread here on any issue that you care about. Let's give it a week and then ask the incubator PMC to VOTE on items on that page. thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - 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: Collecting Proposed changes
Davanum Srinivas wrote: How does a PMC agree to sponsor a thing w/o a VOTE? It wouldn't need an *Incuabtor PMC* vote. secondly, the guys who wrote the proposal asked me to check with WS PMC. why would i do that otherwise? I understand. I still don't think it needs WS sponsorship :) geir -- dims On 1/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Brett, Let's take Tuscany, If the WS PMC had voted on the proposal before it hit [EMAIL PROTECTED], it would have probably passed the pmc VOTE. No - if the WS PMC was actually sponsoring it, it wouldn't need a PMC vote. and incubator would have had to accept it as-is. however fortunately, the proposal was sent directly to [EMAIL PROTECTED] and Roy (and others) had quite a few problems with it which got fixed. So it was a good decision in hind sight that the people who proposed tuscany went to [EMAIL PROTECTED] first. Because it wasn't a WS-sponsored project. I still don't think it needs to be WS sponsored :) geir thanks, dims On 1/2/06, Brett Porter [EMAIL PROTECTED] wrote: Some thoughts: # [ ] - Any proposal should hit [EMAIL PROTECTED] first, No PR before that. # [ ] - Any PR should be vetted by PRC, No Excuses. Agree, for the Apache side of things. I'm not sure we can stop companies doing what they are going to do, but we can certainly say that that they shouldn't be doing so and list the reasons why (because it mighr not be accepted, might have a different name, etc). Also, please define PR. Recent examples seem to think that an individual member of the proposal's personal blog is PR, which I'm not sure I agree with. # [ ] - A sponsoring PMC should hold their VOTE to sponsor a proposal or IP Clearance 72 hours *AFTER* it is posted on [EMAIL PROTECTED] Seems back to front to me. How can you propose anything to the incubator that you haven't decided you want to do? - Brett On 1/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, Please review the items here: http://wiki.apache.org/incubator/ProposedChanges Please feel free to add/modify/delete or start a new thread here on any issue that you care about. Let's give it a week and then ask the incubator PMC to VOTE on items on that page. thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] bring in full code history on incubated project?
Jules Gosnell wrote: Geir Magnusson Jr. wrote: Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? I don't see how the incubator can hold a single position on this one. There are good reasons both for and against, depending on your project. We certainly can have a position, and then deal with exceptions. Rather than making a decision which is bound to fly in the face of some potential incubatees, why can it not simply be left to individual projects to decide for themselves? Because IMO the primary purpose of the incubator is to protect and promote the ASFs interests, not of the candidate individual projects. That's SourceForge. My understanding of the incubator's role, was that issues like this did not have to be resolved until a project sought promotion up out of the incubator. Well, things have to be complete by then, but this is a case of where if you don't do it from the beginning, you can't fix it later, unless you've made no changes to the code. At this point, I might reasonably expect to have to shed a project history - if its acceptance into a first-level ASF repo caused problems - and live with a history divided between two repos. Why, though, a passage to this point, via the incubator, should further fragment a project, and leave me with my history in three places, I do not understand. Isn't the incubator meant to lower the bar for projects wishing to migrate into ASF ? Where would the three places be? I can see two if we don't take history and only one if we do - here, at the ASF. geir Jules (WADI) - 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: [policy] bring in full code history on incubated project?
Jules Gosnell wrote: Geir Magnusson Jr wrote: Jules Gosnell wrote: Geir Magnusson Jr. wrote: Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? I don't see how the incubator can hold a single position on this one. There are good reasons both for and against, depending on your project. We certainly can have a position, and then deal with exceptions. Rather than making a decision which is bound to fly in the face of some potential incubatees, why can it not simply be left to individual projects to decide for themselves? Because IMO the primary purpose of the incubator is to protect and promote the ASFs interests, not of the candidate individual projects. That's SourceForge. My understanding of the incubator's role, was that issues like this did not have to be resolved until a project sought promotion up out of the incubator. Well, things have to be complete by then, but this is a case of where if you don't do it from the beginning, you can't fix it later, unless you've made no changes to the code. if you didn't bring your history to the incubator, then you obviously didn't intend to bring it to ASF - case closed. That's true. I would assume that an OSS project moving here would indeed want to keep it though if you did, then you are saying that you want at least one less fragmentation of your project's history, but this does not stop you from leaving your history behind when you are promoted from the incubator. I can't imagine why you'd want to do that. At this point, I might reasonably expect to have to shed a project history - if its acceptance into a first-level ASF repo caused problems - and live with a history divided between two repos. Why, though, a passage to this point, via the incubator, should further fragment a project, and leave me with my history in three places, I do not understand. Isn't the incubator meant to lower the bar for projects wishing to migrate into ASF ? Where would the three places be? I can see two if we don't take history and only one if we do - here, at the ASF. 1. codehaus (history before move to incubator) 2. incubator (history after move and before promotion - many changes will occur to the project which it is in the incubator) 3. geronimo (history after promotion). History is an integral part of any project, an important technical reference, a record of contributions made to the project and much more. Right - so why would you want to abandon the history when going to Geronimo? I can see it happening going from codehaus to incubator if you chose to do that (although I wouldn't), but we should be able to keep it when going to G, right? The incubator is a grey area between outside and inside ASF. No - it's inside the ASF. I don't understand why any constraints (legal, resource-based etc...) should be applied to a project on entry into the incubator, although I would expect them to be applied strenuously before any promotion could occur. Because the incubator is a project of the ASF, and therefore responsible for what happens here. It's not a no-man's land. geir respectfully, Jules geir Jules (WADI) - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Prototype of new (Forrest generated) Incubator site
Seems to have the same issue w/ IE 6 and Firefox 1.5 on WinXP geir Justin Erenkrantz wrote: On Mon, Jan 02, 2006 at 06:45:56AM +, Ross Gardler wrote: It is not (yet) a perfect copy of the main ASF site. We still need some work on the finer details. However, I hope this is enough to give you a feel. FWIW, it doesn't render correctly on Safari. It always goes over the width and height of the window. -- justin - 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: [RT] Super Simple Site Generation Tool
David Crossley wrote: Geir Magnusson Jr wrote: Roy T. Fielding wrote: I don't see any point in having this conversation every year. Whoever is willing to fix the content on incubator, please feel free to remove the entire site (except the project status files) and start over with whatever tool you deem suitable. I have four other sites to work on that have higher priority, so chances are good that I won't be deleting the incubator site any time soon. Out of some sense of insomnia-driven inquisitiveness, I converted a good bit of the site to xdoc/anakia. It took about 2.5 hours or so. http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/site/ It's not done. I have to convert all the project stuff - I didn't have the internal fortitude and wherewithal to face cwiki - and there's a few other odds and ends. Yeah the *.cwiki are difficult. Forrest often had trouble with them too. As you know, i often tried to encourage people not to use it. Today i repeated the process that converts the cwiki files into html via Forrest's plain-dev skin. For each project that still uses the cwiki format, see the html version in site-author/projects/TEMP_HTML/*.html Thanks - that helps :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
Henri Yandell wrote: On 12/31/05, Craig L Russell [EMAIL PROTECTED] wrote: I haven't been involved in any history here, so please forgive my naivete. I think I understand the rationale for developing spec jars here at Apache. Please correct me if I'm wrong. In order to use a spec jar from the JCP, you have to click a license every time you download it. And this can be a real usability problem if every user of a project needs to manually download just to click a license that they don't read anyway (oops, gotta stop that). Yep. Some are a real pain to find too; jdbc-stdext-2.0.jar springs to mind :) I doubt that there is enough in common among the spec jar developers to build a community around spec jars. But certainly there is a community among the developers of Servlet and a different community among the developers of JDO and a different community for MyFaces, etc. You need community for two parts: 1) Someone has to work on said website. 2) There needs to be a place for people to talk about said specs; not in terms of development, but in terms of is anyone working on a Foo spec yet?, here's a patch for the website and what's the best way for us to handle the naming scheme?. The apache-jcp website is well on the way to this [http://www.apache.org/jcp/]. In addition to a simple site, browseable spec javadoc and download links(ibiblio?) would be nicer than having to dig into the particular TLP that happened to develop the code. Then we get onto the details: * Should the source be in a shared location, or in the original TLP. * Do we put it under JCP [ie: www.apache.org/jcp and [EMAIL PROTECTED] or Jakarta [ie: jakarta.apache.org/specs and [EMAIL PROTECTED] I'm +1 to either. I don't think /jcp is the right place. /jcp is about policy, activism and support for the JCP-related efforts of the ASF, of which the technical ones are in the projects themselves. [sales pitch :)] Really the second question is less about specs and more about whether/how we want a Java Federation at Apache. JCP is effectively the 'Java Community Process Federation at Apache', so it's natural that we'll have overlap issues between the two. This very conversation is an example of why I think we need a Java federation; we're using [EMAIL PROTECTED] to discuss the Apache Java strategy because there's nowhere else more fitting. [/sales pitch] The problem is that I don't think you can force it like that. That's my worry. I don't think this is The Apache Java Strategy as much as a sharing problem some Java projects have. I suspect most of the problem could be solved with a naming convention for jars, social awareness about the problem to get people to work together, and making sure they get pushed to ibiblio since many people use Maven to build. I'm rambling a bit; hopped up on flu medication at the moment :) I think we need to step back and carefully reconsider exactly what problem we're trying to solve. Originally, we in Geronimo-land thought that it would be nice to push our spec jars out to a common place so others can share, and we can get others to push their's out too. We had opportunity for inter-project collaboration (like between Geroninmo and Scout on JAXR spec jars) and we also hoped for collaboration between ASF projects and external projects (like Apache Tomcat and Jetty for Servlet spec jars). This discussion has been a useful exercise. There are a bunch of isssues that came up including legal/licensing, location and most importantly, technical reality - what %-age of specs really have clean interface or abstract class APIs with minimal implementation in API classes? JavaMail is clearly the problem child here, but I'm sure there are more than we think So I'm still pro giving it a whirl, but a little more on the fence... geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
Alan D. Cabrera wrote: There are plenty of non-JCP specs, e.g. CORBA. Do they have the same kind of independent artifacts like some of these JCP specs do? I've been thinking about this too - what other specs have a similar kind of mechanism? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
Roy T. Fielding wrote: On Dec 31, 2005, at 7:34 AM, Noel J. Bergman wrote: [SNIP] I don't see any point in having this conversation every year. Whoever is willing to fix the content on incubator, please feel free to remove the entire site (except the project status files) and start over with whatever tool you deem suitable. I have four other sites to work on that have higher priority, so chances are good that I won't be deleting the incubator site any time soon. Out of some sense of insomnia-driven inquisitiveness, I converted a good bit of the site to xdoc/anakia. It took about 2.5 hours or so. http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/site/ It's not done. I have to convert all the project stuff - I didn't have the internal fortitude and wherewithal to face cwiki - and there's a few other odds and ends. It became clear that we need to rework some of the content. If you want to see it : http://people.apache.org/~geirm/incubator/ Happy New Year geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Experiment : Incubator site done in xdocs...
I realize that many might have checked-out of this thread about 200 messages ago... if there's any interest or comment... (Note, this is just an experiment) Original Message Subject: Re: [RT] Super Simple Site Generation Tool Date: Sun, 01 Jan 2006 03:39:35 -0500 From: Geir Magnusson Jr [EMAIL PROTECTED] Reply-To: general@incubator.apache.org, [EMAIL PROTECTED] To: general@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] Roy T. Fielding wrote: On Dec 31, 2005, at 7:34 AM, Noel J. Bergman wrote: [SNIP] I don't see any point in having this conversation every year. Whoever is willing to fix the content on incubator, please feel free to remove the entire site (except the project status files) and start over with whatever tool you deem suitable. I have four other sites to work on that have higher priority, so chances are good that I won't be deleting the incubator site any time soon. Out of some sense of insomnia-driven inquisitiveness, I converted a good bit of the site to xdoc/Anakia. It took about 2.5 hours or so. http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/site/ It's not done. I have to convert all the project stuff - I didn't have the internal fortitude and wherewithal to face cwiki - and there's a few other odds and ends. It became clear that we need to rework some of the content. If you want to see it : http://people.apache.org/~geirm/incubator/ Happy New Year geir - 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: Starting a java specs project
Alan D. Cabrera wrote: Craig, you hit the nail on the head with this. I am running into this now. The impetus for my attempting to start this is that I currently have to go on an easter egg hunt for spec jars. I have no strong feelings how the jars get into a central place for me to find them so long as they are in a central place. That central place cannot be the JCP web site. Why the heck would it be the JCP web site? geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
Craig L Russell wrote: On Jan 1, 2006, at 10:01 AM, Geir Magnusson Jr wrote: Alan D. Cabrera wrote: Craig, you hit the nail on the head with this. I am running into this now. The impetus for my attempting to start this is that I currently have to go on an easter egg hunt for spec jars. I have no strong feelings how the jars get into a central place for me to find them so long as they are in a central place. That central place cannot be the JCP web site. Why the heck would it be the JCP web site? 'cause that's where you can always find the spec jars; no matter how hard it is to download them, it's really easy to find them. And the license just doesn't work. As opposed to Apache, where it's really easy to download/use them but pretty tough to find them. Oh. I thought that Alan was talking about something else. Got it. Never mind. Hey look! Over there! A bird! geir Craig geir - To unsubscribe, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
Niclas Hedhman wrote: On Saturday 31 December 2005 07:36, Noel J. Bergman wrote: In any event, ... an uber-umbrella isn't making sense to me, so far. +1 Don't force things in place. To me, the most logical step forward is that most uninteresting, boring, stenography of specs sits in Geronimo, mainly because they were 'fed up' of the re-distro constraints imposed in the licensing. So, if there are duplication between Geronimo and let's say WS, why doesn't G and WS work out on which side of the fence the 'copy' sits. And since so much already sits with Geronimo, it would make sense to grow there. We did this, actually, with Scout (JAXR), and it actually makes sense to use Scout's IMO because there is running code in the API (a factory) so it makes sense to be maintained by the implementor of the full spec. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
I was going to respond last night, but I'd been incubatored-out. Noel J. Bergman wrote: Davanum Srinivas wrote: this is just for sources of javax.* NOT implementations. One location for a servlet-api.jar, jaxrpc.jar, saaj.jar, xml-apis.jar. Geir wrote: No - the spec jars for those things. Not the implementations. Ah. And JavaMail? There is only one functional JavaMail out there, and it comes from Sun. JavaMail appears to the exception to the Java is a spec-driven ecosystem rule. :) I think that it's a corner case due to the history of it - it was before the modern JCP era, and my understanding is that it was originally done for client side when everyone [at Sun] thought that everything would be java everywhere. Maybe Classpathx's can be considered functional. So we're talking just about interfaces, and dummy stubs of classes without any real functionality? Yes - that's what has been driving my thinking, but the more I think about it, the more I need to go back and figure out what %-age of specs this is relevant - those that are mostly interface. What's the point? To show that you can compile and link against the spec? That actually is near to what is valuable for people, yes. Writing code that works w/ API $foo needs the jar to compile against. And, as Craig noted: There is often what you might call implementation in the javax.spec domain. Yes, sadly. That's the problem. We'd have to decide how much for a given JSR before it doesn't make sense. And how does this square with Geir's comment: What we're trying to avoid is for those projects that are doing compatible implementations, when people combine code from other projects, there are collisions. Why would there be collisions if we are talking about a spec jar, except when the spec jars are also the implementation? Yes, that's the problem. I've repeated my JAXR story enough not to have to repeat it here, but I'm sure it happens more than we ever see. I find that I am more in agreement with Craig and ... well ... Craig ... hmmm ... odd coincidence. And both work for Sun. Odder still. In any event, the idea of an map to where the JSRs are hosted makes sense, but an uber-umbrella isn't making sense to me, so far. --- 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: [RT] Super Simple Site Generation Tool
He has been studly about it, but could he be studly today? I updated the main projects page and need that to be published... Noel J. Bergman wrote: Mads Toftum wrote: Whoa! so the workflow is tied to David watching for commits? When someone said that at apachecon, I thought it was a joke - I'm beginning to understand more and more of why people are annoyed. Why? The man has been tremendous about it. He publishes daily. And if you look at plans for site-dev, they don't involve people doing their own builds, they involve a build server. Right now, ours is called David. However, rather than repeat it here, see the tail end of my e-mail to Ross, where I mention some proposals for ease-of-use here in the Incubator. --- 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: Starting a java specs project
I need to catch up, clearly. I thought I suggested we do here in anticipation of a TLP. I've been being lazy the past few days. I'll go read and reply now... geir On Dec 30, 2005, at 9:10 AM, Henri Yandell wrote: On 12/28/05, Alan D. Cabrera [EMAIL PROTECTED] wrote: I still don't see #1. However, I still feel that this all belongs in Jakarta Commons. Of the 6 people involved in the thread here, I'd guess at 3 +1's to start this at Jakarta right away; and nothing from Jochen/Hiram/Geir seems like a -1. Shall I go ahead and call a vote on [EMAIL PROTECTED] and get the ball moving? Would anyone else prefer to be doing that? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
On Dec 27, 2005, at 2:42 PM, Henri Yandell wrote: On 12/27/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Dec 27, 2005, at 11:42 AM, Henri Yandell wrote: My aim for Jakarta is to either promote subprojects to TLP or flatten them into Jakarta Commons, leading to a non-umbrella Jakarta (I know, you didn't think you'd see it in your lifetime). This new Jakarta would have the potential to serve two roles: 1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED] 2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons] Storing the spec source there would be good for everyone I think; it would help bring people to Jakarta to share code and conversation, and the Commons community would make good stewards for the code if the various owners departed. I'm not sure if I buy that last one - do you really think that the commons people are willing to do that? why? Yeah, I've forwarded this to [EMAIL PROTECTED] as well so I can get feedback from both sides. The above meant 'the commons community way' rather than the exact people. ie) I'm expecting the original coders to, in most cases, still be maintaining and working on the code. Yoav pointed out that one problem with this is that some of these things have Expert Group authorization issues. Unsure if we would try to get rid of those or just maintain them. There are no EG authorization issues. We're talking about just doing independent spec jars, right? Not implementations of the specs themselves, but just a place for shared spec jars. Like get the javadoc for JSR-FOO when it's done, and site and type in the interfaces ie) Keep them as a part of Jakarta Commons [the community development at Jakarta] or make a third component in Jakarta [along with Jakarta General, the conversation place] called Jakarta Specs. I'm not sure why Jakarta. Since we've been talking about this (over a year?) in Geronomo, I always saw this really as a depot just to get rid of the collisions, rather than any chance for community - this is really just housekeeping. There are no real opportunities for creative work, and once done, they won't change until the next rev of the specs come out. It's just stenography for the most part. True, there are specs for which there is code in the API, such as factories or in the case of Javamail, deeper implementation, but I'd expect that this would be done by the specific projects that are doing the full impl, such as WS-Scout people doing the JAXR API stuff, $whoever_owns_javamail (G right now) doing the javamail spec jars, etc. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
On Dec 27, 2005, at 10:12 PM, Henri Yandell wrote: On 12/27/05, Alan D. Cabrera [EMAIL PROTECTED] wrote: Seems like an oxymoron, community should be active, but the code may not, no? How can this be? Two ways: 1) The conversation that Brett mentions. General pan-apache Java things. I'm a little worried about any authorization issues where only an EG is able to commit. If they get quiet, the community would be unable to make changes. I'm missing something fundamental. What would a JSR Expert Group have to do with this? We are talking about the API jars for completed JSRs, right, and maybe other specs if there are any that require similar machinations? (I can't think of any...) I agree with Brett on the worry about 'how do I do servlets' questions. My recommendation would be to avoid a specs-users list until there are people asking relevant questions. Just make a specs-dev list to start with. This is why I think of it as a depot - it's really about a single storage place than a community project. The problem we're trying to solve (at least the motivation in Geronimo) is not how to get more people working on the specs, because the projects that need them already have a core interested group working - those spec jars are just a secondary requirement of their real charter, which would be doing a flesh-and-blood implementation of the spec in question. The problem we were trying to solve was avoiding *collisions* - Geronimo had JAXR, Scout had JAXR. Geronimo had servlets, Tomcat had servlets. Etc. It could be an unholy nightmare when you crossed the beams, especially for things like JAXR that have factory methods, and it wasn't clear which factory was getting called So I wouldn't imagine there would be much mail traffic at all. Maybe I'm wrong and there is some latent interest in participating in rote implementation from JavaDoc, but I can't see it myself. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
On Dec 28, 2005, at 11:26 AM, Alan D. Cabrera wrote: On 12/27/2005 4:25 PM, Brett Porter wrote: Discussion of upcoming specs, discussion of usage of the specs, a users list that helps people use the specs (this is necessary, but worries me about getting how do I do servlets type questions). I guess there is also scope to innovate in addition to the specs and work on commons components that do things the specs missed. Is there much non-code activity around specs in Geronimo right now? There is no activity. Once the specs have passed the TCK, people are really only interested in the implementation that's on top of the specs. Right- and I don't think of it as the spec passing the TCK. The spec jars we're doing here are really (for the most part, for modern JSRs done by clueful EGs) just copying what we read in the API docs, right? geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
Yoav Shapira wrote: Hi, I'm missing something fundamental. What would a JSR Expert Group have to do with this? We are talking about the API jars for completed JSRs, right, and maybe other specs if there are any that require similar machinations? (I can't think of any...) I raised the EG commit point for cases of completed JSRs that later have corrections or errata, or simply things like typos in the JavaDocs or even implementation bugs in the examples if any are included with the APIs themselves. We've seen this happen every now and then (not often at all, but it does happen, maybe once per year) with the Servlet and JSP APIs in the Tomcat world. Sure - but in that case, the EG should/is required to do an update on the spec itself, that would be somehow labeled, and we'd update from there, right? It would be great to get EGs to come fix our code, but I don't think that would happen except in rare cases, and those would be just because we happen to have a community member on the EG. For a long time the relevant CVS modules (jakarta-servletapi, jakarta-servletapi-5) only granted commit access to Servlet/JSP EG members, not all Tomcat committers, and if some of the EG members were busy elsewhere, typos and corrections to the spec stuff would take forever to fix. This is unfortunate because when these rare things do occur, they are a high-visibility issue that should be addressed immediately. Right. Agreed. Maybe we don't have external EG-only commit rights in the future ;) ? (The situation is now better for these specific APIs since we moved to SVN and I believe the entire Tomcat PMC may have commit privilges to the tomcat/servletapi tree, but I'd like to ensure it doesn't happen in this new specs project). I see. Thanks. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
Justin Erenkrantz wrote: On 12/29/05, Greg Stein [EMAIL PROTECTED] wrote: If another PMC decides a project should be incubated, they must provide the people to make that happen (so we achieve proper scaling and to put the effort on those who want the results). The Incubator can't refuse the project outright, but if the STATUS page or proposal/charter or whatever doesn't meet the guidelines, then the Incubator can certainly require that it be amended. But you should not simply be able to kill it outright. +1. I think that's an important distinction to make. Proposals should require the advice and consent of the Incubator PMC. I agree that while the Incubator PMC shouldn't be able to kill the project, they can and should be able to say Your charter sucks. Rewrite it. We won't sign off until that happens. It's about the form than the content. Roy's comments about Tuscany proposal are what I'd characterize in this mold. Agreed, but the Tuscany proposal was an independent proposal, not sponsored (at the time) by any PMC. The Incubator PMC should also be able to make a judgment (certification?) of the process proposed by the PMC - such as whether a code base should be under full incubation or just use the IP clearance form. I think that making it clear that the Incubator PMC can do this would go a long way to addressing some of the concerns already mentioned. Agreed - although in general, if a PMC just ignored the input of the Incubator PMC on a PMCs suggested incubation, it's an indication of a problem anyway... geir -- justin - 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: [RT] Super Simple Site Generation Tool
I disagree in trying to put the kibosh on the thread. It was very healthy to bring out the frustration that had been simmering, and I think that we all learned something. What shall we do then in incubator? Any idea for a productive outcome? geir Leo Simons wrote: OK ok ok ok. Enough already. Done and done. The incubator has more pressing things to worry about right now besides site generation tools. Please drop this thread or take it elsewhere (I suggested site-dev@ before). Gaah. Apologies to all for opening up a can of worms. My goal with spending time on this was to remove some frustration, not add to it. LSD - 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: Starting a java specs project
Noel J. Bergman wrote: Alan D. Cabrera wrote: There has been some discussion on creating a Java specs project which would hold all the specs jars from the various JSRs as well as other standards, e.g. CORBA. Often, there are many duplicate copies of the source code for the same JSR floating around in different Apache projects. It would be a great idea to move them all into one project. This idea, so far, has been met with much enthusiasm. What exactly does this mean? That the source for Tomcat, JackRabbit, Geronimo, WS, Directory and all of the others will be moved to one place? No - the spec jars for those things. Not the implementations. Geir says: The point of this was that this is shared code as well as code that causes collisions. Apache Geronimo had to implement this stuff for J2EE, but it's a dupe of what we find elsewhere, like in tomcat and in web-services land. We just did the spec jars. The actual implementations of course come from Tomcat, WS, etc. I agree that this is a problem, but turning Geronimo into something worse than Jakarta ever was, or turning Jakarta back into its old self is not a solution. Getting projects to stop rolling their own, and to collaborate with the other projects is one solution. For example, if those Geronimo built artifacts are dupes, then why were they built instead of re-used? And we have similar situations all over the ASF. Probably for completeness. We have 17 spec modules. We needed a complete set. We all agree that it's dumb to have this implemented in multiple places. Hence the idea. Geronimo was never intended to build everything. It was intended to build the infrastructure for pulling together all of the parts from around the ASF and elswhere as necessary that were required to build a J2EE server. If you want to have an ontological map of where each JSR is implemented around the ASF, for that I would be +1. http://www.apache.org/jcp (not complete yet, btw, but getting there) We've discussed that idea before. If we want to make sure that these jars can be separately accessed, rather than just in a big release package, +1 of course. If we want a common distribution repository for the binaries, OK. But to have a single uber-umbrella for every JSR implementation? That's not the point of the suggestion, at least as we've been thinking about in in Geronimo for the last year :) geir --- 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: Starting a java specs project
Niclas Hedhman wrote: On Friday 30 December 2005 22:52, Geir Magnusson Jr. wrote: I'm missing something fundamental. What would a JSR Expert Group have to do with this? We are talking about the API jars for completed JSRs, right, and maybe other specs if there are any that require similar machinations? (I can't think of any...) Not sure if the JDO spec is being referenced, but that is a spec+TCK project only, where a portion of th EG are ASF committers and the spec development happens on the ASF infrastructure. I think it was just coming out of incubation, but yes, that's something we should point to somehow. It would be nice to have a JDO2 impl here as well... geir Cheers Niclas - 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: Starting a java specs project
IIRC, they are going to be the RI for JDO2. I think that an indep impl that isn't the RI would be healthy. Maybe we could base on the JPOX2 codebase as a start. It won't be a fork, IMO. I don't have the time though... geir Thomas Dudziak wrote: On 12/30/05, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Not sure if the JDO spec is being referenced, but that is a spec+TCK project only, where a portion of th EG are ASF committers and the spec development happens on the ASF infrastructure. I think it was just coming out of incubation, but yes, that's something we should point to somehow. It would be nice to have a JDO2 impl here as well... If I remember correctly, we asked the JPOX guys unofficially some time ago whether they would consider becoming an Apache project, but in the end they didn't want to. Perhaps Craig knows more. Tom - 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: Starting a java specs project
Craig L Russell wrote: 4. Apache JDO (which notwithstanding information on the incubator web site has graduated;-) Hey, I fixed the source page. Didn't the magical process happen to get it published? :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
is not simple or clean enough
* the validation step is not complete enough
* the transformation is not predictable enough
* changing the stylesheet is not simple enough
* if maven is upgraded your entire look and feel may change as
well as other things (eg the xdoc plugin is not stable enough)
* anakia
* the source xdoc format is not simple or clean enough
* the validation step is not complete enough
* the transformation is not predictable enough
* managing navigational elements is not simple or clean enough
* others
* no doubt there are many that could be used
== Possible steps forward? ==
Given the above, fixing forrest seems like a lot of work. I think
its a
fundamentally bad fit, being built on top of many many layers of
java code
and several frameworks makes it too heavy by definition. However,
since
it is very easy to customize forrest to output the source format for
another tool, and we have ready access to forrest experts,
migrating away
from forrest is probably not very painful (I think it involves
writing some
XSLT). As long as the source format stays XML, moving back to
forrest later
is also not painful. Standards-based. Lack of lock-in. Good.
Moving back to anakia is possible, but satisfying the validation
requirement
is always going to be hard because of its use of velocity rather
than real
XML parsing.
Moving forward to maven 2 is probably possible but I think the same
argument
against anakia still applies to its document generation process.
One big
advantage with maven is that its easy to also automate many of the
other bits
of workflow, eg doing things like the 'svn commit' too.
Step 7 and 8 depend on what the site-dev at apache.org people come
up with;
right now this is more like having to do an svn up remotely,
setting up
a HTTP proxy, etc, or skip 7, and just do 8, with x == 2. But
that'll be
fixed. Lots of plans made, apparently. Haven't been able to figure
out what
the status is right now (seems there's no code for steps 1-6 at the
moment),
but its definitely going to be compatible with any tool satisfying
the above
use case. See:
http://people.apache.org/~rgardler/site-dev/Site-Build.html
The site-dev people have been working on some other kinds of tools,
including
one that uses Perl+XSL, which shows just how simple step 4 at its
core really
is:
#!/usr/local/bin/perl
use strict;
my $xdocdir = xdoc;
my $htmldir = html;
my $xslfn = xsl/xdoc2html.xsl;
opendir(XDOC, $xdocdir) || die(Couldn't open directory $rdfdir);
while (my $r = readdir(XDOC)) {
next unless $r =~ /^[a-zA-Z].*\.xml$/;
my $infn = $xdocdir/$r;
print Processing $infn\n;
my $outfn = $htmldir/$r;
$outfn =~ s/\.xml$/\.html/;
`xsltproc $xslfn $infn $outfn`;
}
closedir(RDF);
Some things to notice...
* needs xsltproc to be installed
* error reporting not so intuitive (just the output from xsltproc)
* no clear abort on error
* doesn't walk directories (I think perls readdir reads the current
directory only)
* specification of navigational elements not easy enough (eg no
maven-style site.xml)
(* also note some of the use case being addressed depends on the XSLT
file)
But these kinds of things aren't exactly hard to address. So I think
I'm going to spend a day or maybe two writing a dedicated script that
does the above, and a little more, and then once done I'll spec up
what forrest should be spitting out, and ask for a volunteer to write
the neccessary stylesheets and do the conversion.
The code for this is probably going to end up somewhere inside
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk
Unless there's lots of discussion resulting from the above on site-dev
(there seems to be a lot of history to this topic), then it'll end up
somewhere else.
Its probably going to be written in python and will probably use
minidom
and the Kid template language. Its probably going to have a source XML
format that is a subset of XHTML 1.1 and specified as a DTD file. I
think
I'll do away with a site.xml or anything like that and just specify
the menu as an XHTML snippet, since I've never ever seen site.xml
files
used for anything but generating websites. I'll try and write the
critter
so that its easily thrown away and replaced by something written in
Perl
or Java.
I think I'll call it xdok.
I'll send another email once I have something working and ready for a
demo.
From there, we'll see where it goes.
- LSD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
On Dec 27, 2005, at 9:14 PM, David Crossley wrote: Leo Simons wrote: Thomas Dudziak wrote: since I'm rather new to this, I don't have a deep understanding of the problems you're trying to solve. None is needed, the problem is very simple. The problems are not simple, or they would have been solved years ago. Follow the site-dev discussions from mid-2004. It seems that the publishing step is the hardest. No matter what the tool, that step trips people up. It seems that committers just will not do it. It could perhaps be automated, however the requirement to check the generated docs into svn prevents that (need a committer's svn credentials).\ I don't understand. Publshing to me should be svn commit after I look at the site with my local browser as a QA step. And yes, committers should be the only ones able to do it. Another complex issue is being able to run doc tools on Apache servers. We have all been asked to not use people.apache.org for that. Sure we will soon have the zones.apache.org machine (currently still in testing phase). However, that is not scalable. For example we don't want to run various forrest instances there for everybody to use. Our project is too small to be able to support other projects in that way. Why not run doc tools? Isn't it really about which doc tool? Running the generation for the geronimo site takes under 10 seconds wall clock for a full render. That's seems fairly unintrusive. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
On Dec 28, 2005, at 12:52 PM, Noel J. Bergman wrote: In any event, there are a variety of ways forward. Alex, Ted, Serge and others appear to like the idea of a authentication restricted Confluence to use for generating HTML. I think that we should have a neutral open format that our docs and sites are in. Confluence isn't that, and you can't work offline. PLease, lets not solve this with a wiki. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
On Dec 29, 2005, at 8:34 AM, Tim Williams wrote: On 12/29/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Dec 27, 2005, at 10:03 PM, David Crossley wrote: Davanum Srinivas wrote: Example: last apachecon, Geir was trying to update geronimo.html, it took 30+ mins before asking for help. It took me 15+ minutes to figure out that geronimo.html was not being linked from any page in the web site. So we lost close to an hour of hackathon time trying to do something really simple and silly - add a line of text to the geronimo.html asking folks to go to the geronimo actual web site. Steady on. Just prior to that, someone made a change that removed geronimo.html from the /projects/ area. The normal process with such a sudden break, is to investigate the prior changes that caused it. My problem was that I didn't understand how things worked. I thought that all content in the tree got rendered, and was just baffled when my changes to the cwiki file didn't get added. Yes, it was my fault, I suppose, but please, add a feature in Forrest to show a list of files it found that it won't process. I think that really help users. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] The Forrest project uses a tool called JIRA [1] so that users like you can add feedback/feature requests like this one. Your request is much more likely to get addressed there than on the incubator mailing list. For the next one, I'll do that. For this one, I'll assume it's in safe and responsible hands. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
On Dec 29, 2005, at 9:58 AM, Ross Gardler wrote: Geir Magnusson Jr. wrote: On Dec 27, 2005, at 9:14 PM, David Crossley wrote: Leo Simons wrote: Thomas Dudziak wrote: since I'm rather new to this, I don't have a deep understanding of the problems you're trying to solve. None is needed, the problem is very simple. The problems are not simple, or they would have been solved years ago. Follow the site-dev discussions from mid-2004. It seems that the publishing step is the hardest. No matter what the tool, that step trips people up. It seems that committers just will not do it. It could perhaps be automated, however the requirement to check the generated docs into svn prevents that (need a committer's svn credentials).\ I don't understand. Publshing to me should be svn commit after I look at the site with my local browser as a QA step. And yes, committers should be the only ones able to do it. That is exactly what it is, when using ForrestBot (in fact you don't even have to type svn commit since the tool does it for you). The problem is that it requries SVN passwords or user interaction and so can't be part of an automated tool. What's the ForrestBot? I just want to a) edit b) render c) examine. if not right, GOTO a) d) commit e) deploy a,c are entirely my choice of tool, so it's easy. d,e use one standard common tool. it's easy. b needs to be simple and easy Another complex issue is being able to run doc tools on Apache servers. We have all been asked to not use people.apache.org for that. Sure we will soon have the zones.apache.org machine (currently still in testing phase). However, that is not scalable. For example we don't want to run various forrest instances there for everybody to use. Our project is too small to be able to support other projects in that way. Why not run doc tools? Isn't it really about which doc tool? Because the ASF have to support the chosen tool and there are many different site generation tools in use within the ASF (now the Incubator is about to get its own). I hope not. I hope we reuse what is simple and easy and already working. geir See http://people.apache.org/~rgardler/site-dev/Site-Build.html and bring any suggestions/contributions you have to the site-dev list. Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Super Simple Site Generation Tool
Noel J. Bergman wrote: Geir Magnusson Jr. wrote: I am +1 for dumping Forrest. I never grok why something so simple as our static website needs something so complicated to build it. Forrest does do some things for us, such as generating what I do consider to be a somewhat nicer looking site with collapsable menus and tabbed navigation than we have for the main site, JAMES, httpd, et al. YMMV. What's wrong with the xdoc/Anakia approach? Nothing, necessarily. David Crossley tried to put together a constructive discourse regarding site construction almost two months ago, and got almost no feedback. I'll go back and try to find that. We all seemed to miss it, and it sounds like it deserves a read. I'll grub, but it might help all of us if someone or David reposts. And honestly, besides poking in the ApacheCon logo at the appropriate times of the year, who ever edits the Anakia doc? I do, every time I need to change the side menu, or other global item. Right- but compared to the general content changes, how often is that? geir --- 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: [RT] Super Simple Site Generation Tool
I don't mean to beat a dead horse here, but this reminds me of the old joke : Patient : Doctor, my arm hurts when I life it like this... Doctor : Don't lift it like that... I needed to lift my arm. I had a page that I didn't wish to have as part of the site (i.e. I didn't want the site to have a live link to it) but I wanted to change the content for anyone out there that still had a link (like Google!). So I needed to modify and render a page that wasn't part of the formal site tree. The solution? After hours of beating my head against the wall, the solution was to Link something to it, render (go for coffee...), then change the link back, re-render (go for coffee...) Oh, and since we're on this subject, one more thing - when running Forrest in local server mode, it **WILL** render things that aren't linked when you browse them. IOW, letting forrest render everything to disk as a batch didn't fix my page because nothing linked to it. Running forrest and me hitting it on localhost with a browser *did* render it when I put the URL in. (And then it didn't write the rendered output to disk... Imagine my bafflement...) So I think that you should choose one mode. And it would be very useful if I had gotten a message in the online mode that said you are looking at a resource that currently isn't linked to by any of the control documents (or whatever) it would have saved *heaps* of time geir David Crossley wrote: Geir Magnusson Jr. wrote: Tim Williams wrote: [EMAIL PROTECTED] The Forrest project uses a tool called JIRA [1] so that users like you can add feedback/feature requests like this one. Your request is much more likely to get addressed there than on the incubator mailing list. For the next one, I'll do that. For this one, I'll assume it's in safe and responsible hands. http://forrest.apache.org/docs/faq.html#crawler -David - 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: Starting a java specs project
On Dec 27, 2005, at 11:13 AM, Alan D. Cabrera wrote: There has been some discussion on creating a Java specs project which would hold all the specs jars from the various JSRs as well as other standards, e.g. CORBA. Often, there are many duplicate copies of the source code for the same JSR floating around in different Apache projects. It would be a great idea to move them all into one project. This idea, so far, has been met with much enthusiasm. We've been talking about it for a while in geronimo - so yeah, might be a good thing to get started. (I took jcp-open off as this really isn't JCP specific...) How about here? geir How do we get this started? Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
On Dec 27, 2005, at 11:42 AM, Henri Yandell wrote: One idea was to collate them as a part of Jakarta. I'd never heard that one ;) My aim for Jakarta is to either promote subprojects to TLP or flatten them into Jakarta Commons, leading to a non-umbrella Jakarta (I know, you didn't think you'd see it in your lifetime). This new Jakarta would have the potential to serve two roles: 1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED] 2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons] Storing the spec source there would be good for everyone I think; it would help bring people to Jakarta to share code and conversation, and the Commons community would make good stewards for the code if the various owners departed. I'm not sure if I buy that last one - do you really think that the commons people are willing to do that? why? The point of this was that this is shared code as well as code that causes collisions. Apache Geronimo had to implement this stuff for J2EE, but it's a dupe of what we find elsewhere, like in tomcat and in web-services land. The point was to get people to stop maintaining it within their project boundaries and do it in common - I don't think that people would move on as it's key to what's happening w/in each TLP. I.e. WS needs JAXR for Scout (and so does Geronimo). Tomcat needs servlet for tomcat (and so does Geronimo). Portals needs JSR168 for portlets, etc... IOW, there are people already working on this stuff. This was the same motivating factor for Jakarta Commons when we started it - have subprojects (w/in Jakarta) bring forth things that they will share but will continue to work on as they are fundamental to the subproject. IOW, the contributing [sub]project had a very compelling interest to keep going w/ the software. Some other pluses are that it would help be a part of an attempt to rejuvenate Jakarta in 2006 (as a kind of federation) and that non- JCP specs could be stored there too. Not trying to intrude on the JCP stuff though, so I can see if it's preferred to keep things under a strictly JCP-oriented environment. I don't think that it should be considered JCP specific - IOW, there's no reason to keep cc-ing jcp-open, but rather [EMAIL PROTECTED] is a fine a spot as any. geir Hen On Tue, 27 Dec 2005, Alan D. Cabrera wrote: There has been some discussion on creating a Java specs project which would hold all the specs jars from the various JSRs as well as other standards, e.g. CORBA. Often, there are many duplicate copies of the source code for the same JSR floating around in different Apache projects. It would be a great idea to move them all into one project. This idea, so far, has been met with much enthusiasm. How do we get this started? Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project
Dropped jcp-open cross-post. On Dec 27, 2005, at 12:00 PM, Hiram Chirino wrote: Hi, I think this would be great! I know it's silly, but I get annoyed at the fact that many of the J2EE spec jars that I use from apache have geronimo- in the jar name but It's just the ASL 2.0 spec jars that I'm using and not really a geronimo implementation. In general, I think that this would make a good TLP since it would provide a good area for cross project involvement. I agree - I think also that it would be as good a TLP as any. Very specific charter, very clear goal. That said, Henri had some things to offer w/ Jakarta. What we could do is do it in the incubator for now, get it going, and then make that decision later depending on how we all feel... geir Regards, Hiram On Dec 27, 2005, at 11:13 AM, Alan D. Cabrera wrote: There has been some discussion on creating a Java specs project which would hold all the specs jars from the various JSRs as well as other standards, e.g. CORBA. Often, there are many duplicate copies of the source code for the same JSR floating around in different Apache projects. It would be a great idea to move them all into one project. This idea, so far, has been met with much enthusiasm. How do we get this started? Regards, Alan -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Growth
On Dec 22, 2005, at 2:51 PM, Rich Bowen wrote: Alan D. Cabrera wrote: On 12/21/2005 7:22 AM, Davanum Srinivas wrote: Folks, Right now any PMC can automatically ok projects into incubator. How about we change that rule? So that the only pmc that can approve a proposal is the incubator PMC. ++1 I also agree, after some thought. Without putting too much thought into my response I think that the Incubator PMC wields enough control given that they have the final say on Incubation graduation. Having a no vote in what enters the incubator, but only on what leaves: 1) sets up the folks doing the work for burnout due to the possibly large numbers of projects in at any one time. Controlling throughput is important. My so-called Denial of Service Attack on the Incubator :) 2) sets up a larger number of projects for failure. If there is (hypothetically) some compelling reason that a project isn't going to be graduated, then isn't it better to be able to say that at the start, rather than waiting for a certain number of hoops to be jumped through? Yes, but we can't think of incubation failure as failure - that's actually a successful outcome for the incubator, as it's doing its job in that case. Not everyone will want to work our way, not every project will catch a diverse community interest, etc. I'd prefer we call it something else - like retired from incubation or something. A job a long time ago taught me very well that you should never be afraid to fail if you go at things with good intentions and good effort. geir Yes, absolutely, I believe the incubator should have a vote up front to approve what enters the incubator. -- Rich Bowen [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
On Dec 22, 2005, at 6:23 PM, Roy T. Fielding wrote: On Dec 22, 2005, at 10:53 AM, Erik Abele wrote: On 21.12.2005, at 21:57, Roy T. Fielding wrote: On Dec 21, 2005, at 11:04 AM, Ted Leung wrote: How is this possible when any other PMC can vote to bring a project in without approval of the incubator PMC? Just look at the raft of projects being brought in via Geronimo and the WS PMC. There's not a thing I can do, regardless of the merits. The only thing I can say is whether or not their community is good enough to merit graduation. Right, and that's the only thing you are qualified to do. You don't have the right to tell other people what they can or cannot do at the ASF. You don't have the right to say that one project is more deserving of our resources than some other project. What you do have is the right to be involved, to help their incubation (or not), and to vote against their graduation if you so desire. So nobody has the right but you do? Or how can your smack-down of the Tuscany proposal be interpreted? Because Tuscany was proposed to the incubator PMC (not another PMC) and I do have a vote here. In any case, I objected to the proposal because it was empty of significant content, and removed by objection once it was filled. I did not prevent them from working on an architecture that I still believe to be a waste of time -- I only made sure that they all agreed on what they wanted to work on, because I think that is a minimum for any collaboration. As the sponsor/champion of Tuscany, I'll be the first to admit that Roy was actually right on with his criticism. The proposal didn't reflect what the proposers were actually thinking, and it forced the team to review and rewrite, and the result is IMO a stronger, clearer proposal and statement of intent. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
On Dec 23, 2005, at 12:19 AM, Ted Leung wrote: On Dec 21, 2005, at 12:57 PM, Roy T. Fielding wrote: That's because an Apache project is an EFFORT of the ASF. It is not some diploma that people receive at the end of graduation. Everything done at the ASF is an Apache project. Some are organized better than others, and some are allowed to make their own release decisions, but all of them are collaborative projects using ASF infrastructure and following the literal meaning of Contributor as defined in our license. And, when needed, the board can terminate a project whether it is in the incubator or not. To us an Apache project is an effort of the ASF. To the majority of people out there, being an Apache project (rightly or wrongly) is branding stamp. You might not like it, but that's how many people treat it. And that's why one of the first things a company wants do when it proposes incubation is issue a press release. There are lots of bad reasons to come to the ASF and high on my list is to take advantage of the brand. Maybe then we address that issue head-on, and simply ask that a contributing company doesn't do a press release for n months after entering incubation? And when the project graduates, we do a good job assisting them with a joint release or something as the reward. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
Every TLP has an explicit charter when created by the board in the resolution that creates them. How they interpret that and change with the shifting sands of technology style is up to them geir On Dec 23, 2005, at 10:31 AM, Davanum Srinivas wrote: Sounds good to me (hopefully all our TLP's will have charters soon!!). -- dims On 12/23/05, Sam Ruby [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Sam, it's not just a question of content and significance. It's also a question of fitting with existing projects and check to make sure that the project still adheres to the the charter of the PMC. These are better checked by outsiders (Incubator PMC), since the insiders (WS PMC) may be biased. I don't believe that it is the incubator's job to watch to make sure that existing projects stay to their charters - that's the job of the board. Another thing i can think of is, for example, when HTTPComponents (by internal people) was being set up there was resistance from tomcat folks. But the scope got resolved by active participation by folks from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC already voted to accept something even before Incubator PMC knows about it (not to mention the other PMC's who may significant input). Again, I don't believe that it is the incubator's job to enforce scope. Furthermore, acceptance by the incubator is the start of a process, not the end of it. There should be adequate opportunity for people to provide input during the course of incubation. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
On Dec 23, 2005, at 10:57 AM, Justin Erenkrantz wrote: On Fri, Dec 23, 2005 at 09:11:55AM -0500, Geir Magnusson Jr. wrote: I am no longer convinced of this. Having the Incubator PMC there as a check and balance is a good thing as it requires engagement from others interested in this aspect of ASF life. It prevents one individual or one PMC from being able to make significant social or technological change, or at least ensure that there is a theoretically impartial observer keeping track. It allows interested members and other community members to put their money where their mouth is on this topic, and join the Incubator PMC to help out. I don't think that can scale appropriately. Why would the Incubator PMC know more about whether mod_ftp is a good fit for the Foundation than the entire HTTP Server PMC? I certainly agree that in 99% of the cases, this would be the case, and I would never expect the Incubator PMC to ever stand in the way of any proposal unless there is good reason of broader scope. Healthy PMCs will IMO always do the right thing. I was thinking more along the lines of the Incubator having to vote and therefore do some due-diligence. It also does give the Incubator PMC some control over rate of growth. I'm worried about growth, but not anti-, but certainly worry about the incubator being stretched too thin to effectively provide the legal oversight and community shaping. Our incoming rate is faster than the outgoing rate - at what point do we have more than we can handle? Imagine if every PMC did what the Geronimo PMC just did, and invited in say 5 new projects (as is their right). That's about 150 new podlings at once. How would we deal with that? I don't expect this to happen, but maybe you can see my point. I think that there's little downside to this. A check on the Incubator PMC is the board - any member or PMC could appeal to the board in the event that they believed their proposals were not being treated fairly, or if the Incubator PMC was behaving in general in a way they disagreed with. And the board has to answer to the membership. I believe that there is *major* downside to having the Incubator PMC second-guess the decisions of other PMCs. If someone doesn't like the decision of a PMC, they shouldn't be able to use the Inucbator PMC as cover for their attacks. People who don't like what's going on in that PMC should confront that PMC directly. If they don't like what's going on in that PMC and have tried to redress their grievances directly, they can go to the Board. I'm assuming a healthy Incubator PMC here - not one in which one person can leverage to attack a PMC. Although, the Board is rightly wary of interposing itself in technical decisions. We have no idea what makes technical sense or not either. Right - I wouldn't think that the Incubator PMC would want to make decisions based on technical merit either. That's a non-starter - we have to assume that each PMC is the most clueful in their technology domain. But code sources, committer diversity, availability of volunteer resources in and around the incubator all are things we can consider. Like it or not, the INcubator PMC is the locus of these efforts, and it's real resources that are needed for each podling. Cynics like me are the *worst* possible judges of what's cool and what's not. That's the fundamental problem I have with this entire thread: people are trying to limit the growth or exclude projects. How? On what basis? I agree here - I would never want to exclude based on technology. I do the thought experiment from time to time and ask myself which projects I would have excluded if ordered to limit growth at the ASF, and I never have a good answer. Maybe not let those toaster language bytecode people in? I think our current java communities are a *huge* asset. How about the pointy-bracket folks? We need to actually increase our technical diversity here - we have no real Ruby-oriented communities, nor any coherent .NET identity, and I think that's going to hurt us in the long run. That's why this talk about limiting growth is so dangerous. The foundation should go where our PMCs and our members want. -- justin It's dangerous, but it's also a consideration of a vocal and active part of the membership. It can't be ignored. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
On Dec 23, 2005, at 11:26 AM, Davanum Srinivas wrote: Hmmm...But the deal is if the PMC wants a change to its charter it needs to VOTE on it and formally adopt it. right? AND if the PMC does not have one then it needs to adhere to the board resolution. right? You know where i am going with this, if you read between the lines... There's lots of places to go with this :) I guess we need to clarify if we are talking about the charter as from the baord Thou shalt do webservices which I do think is up to the board to change (in conjunction with the PMC) or the project bylaws/guidlines setup entirely by the PMC We shalt to webservices in this manner I believe that many projects do not conform precisely to their project charter but still work in healthy and collaborative ways... geir -- dims On 12/23/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Every TLP has an explicit charter when created by the board in the resolution that creates them. How they interpret that and change with the shifting sands of technology style is up to them geir On Dec 23, 2005, at 10:31 AM, Davanum Srinivas wrote: Sounds good to me (hopefully all our TLP's will have charters soon!!). -- dims On 12/23/05, Sam Ruby [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Sam, it's not just a question of content and significance. It's also a question of fitting with existing projects and check to make sure that the project still adheres to the the charter of the PMC. These are better checked by outsiders (Incubator PMC), since the insiders (WS PMC) may be biased. I don't believe that it is the incubator's job to watch to make sure that existing projects stay to their charters - that's the job of the board. Another thing i can think of is, for example, when HTTPComponents (by internal people) was being set up there was resistance from tomcat folks. But the scope got resolved by active participation by folks from tomcat and jakarta pmcs. IMHO, this will not happen if a PMC already voted to accept something even before Incubator PMC knows about it (not to mention the other PMC's who may significant input). Again, I don't believe that it is the incubator's job to enforce scope. Furthermore, acceptance by the incubator is the start of a process, not the end of it. There should be adequate opportunity for people to provide input during the course of incubation. - Sam Ruby --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[policy] bring in full code history on incubated project?
Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubating java projects
On Dec 21, 2005, at 6:40 AM, James Strachan wrote: I think the package name change is currently not mandatory, but perhaps it should be. I'm not so sure. There's already various stuff at Apache that breaks this rule (SAX, DOM, JCP APIs such as stuff in geronimo- spec, the SCA specification in the Tuscany project; I'm sure there are other examples, this was off the top of my head). Seems a bit silly to introduce a new rule that we can't ever fully comply with for no technical reason. To be clear, the other namespaces are required by specs (SAX, DOM, J2EE, SCA...) its not a choice. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is the incubator out of control?
In theory, the sponsor and mentors are doing that continuously. geir On Dec 21, 2005, at 10:51 AM, Rob Davies wrote: I Also share these concerns - is there currently a process to have continuous reviews throughout the entire life-cycle of all new and existing projects - to ensure that everything under the 'apache' brand is and will continue to be 'worthy' ? Sorry if there's already a process in place - I'm new :) cheers, Rob On 21 Dec 2005, at 15:18, Mads Toftum wrote: On Wed, Dec 21, 2005 at 01:50:28AM -0800, Ted Leung wrote: The merits of the particular proposal aside, I wanted to comment on this paragraph. This year at ApacheCon I was surprised to find that a number of people also feel that the ASF is growing far too quickly. I know that are some people who believe that the growth that we are experiencing is indicative of our success. Unfortunately, I don't agree with that.I think that the incubation process is setting an incredibly low bar for access to the Apache brand name, and this is a bad thing. Very much agreed - I've been worried about the same for quite a while. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall - 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] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] @domain for Incubator mailing lists
On Dec 20, 2005, at 1:09 PM, Dain Sundstrom wrote: Offering an alternate proposal as part of a vote thread after the discussion has taken place already where one did not participate *is* anything else by the way. What I didn't like is the very fact that someone out-of- the-blue proposes an alternate, since that derails the vote thread, takes time and energy of everyone, and is just counter-productive in the end. You may notice that both Cliff and I have some reservations but we're not getting in the way of making progress. My proposal is not out-of-the-blue. I brought this up a few days ago in the @domain for Incubator mailing lists thread to which there was one completely useless response from Geir To what end? Which you ignored for some reason. Why was it 'useless'? I was trying to figure out why you wanted all podling email domains to switch to @incubator, not just the new/recent ones. I'm still confused on what you actually want, because you voted against your own suggestion. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubating java projects
It's not actually a dumb question, but rather one that I always took for granted... I realized when asked by Alan that we never had the need to codify it... On Dec 20, 2005, at 2:16 PM, Alan D. Cabrera wrote: Dumb question, is it a requirement that the incubating project move to the org.apache package? Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubating java projects
Right - I would assume you provide some kind of adapter package so existing code works, and deprecate it... On Dec 20, 2005, at 5:12 PM, Brett Porter wrote: Of course, the answer may not be that simple if you have an existing user base that programs against your APIs. I think it would be wise to do this as soon as possible and judge the impact. We found we had to write a couple of compatibility interfaces under the old package scheme to retain binary compatbility, while requiring those upgrading to change package names. - Brett On 12/21/05, Davanum Srinivas [EMAIL PROTECTED] wrote: Yes :) -- dims On 12/20/05, Alan D. Cabrera [EMAIL PROTECTED] wrote: Dumb question, is it a requirement that the incubating project move to the org.apache package? Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX Toolkit Framework Proposal
On Dec 20, 2005, at 10:32 PM, Mike Milinkovich wrote: It's rather like saying what the heck is the Apache web server doing with a JVM project? I say that about once a week these days ;) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] @domain for Incubator mailing lists
+1 Helps keeps things organized... anything that helps there is good these days... On Dec 17, 2005, at 11:49 PM, Noel J. Bergman wrote: Please vote on the following: New mailing lists should be created under the @incubator.apache.org domain, just as all of the other project resources, e.g., the web site and SVN subtree. +1 from me. --- Noel -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 16:02 To: general@incubator.apache.org Subject: @domain for Incubator mailing lists There has been some discussion and confusion over where to put mailing lists for projects that are in the Incubator. As the person who argued for the current approach, which had to do with infrastructure issues, I'm also going to suggest that it change. We are finding that it is more and more important to highlight when a project is in the Incubator, and to ensure that there is no confusion in the mind of the public about that status. The current approach is to put the mailing lists under the domain of the TLP into which it was expected that they would go, and THE REASON for this had to do with the difficulty of moving the mailing lists and the eyebrowse archives. HOWEVER, Roy has since written a script to move mailing lists, and we no longer use eyebrowse. And unlike the prior setup, it is fairly straightforward to redirect an old archive location to a new one. THEREFORE, new mailing lists should be created under the @incubator.apache.org domain, just as all of the other project resources, e.g., the web site and SVN subtree. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DONE : Re: WADI mailing lists
done On Dec 15, 2005, at 12:07 AM, Matt Hogstrom wrote: Geir, You can add me to the volunteer list. Matt Geir Magnusson Jr. wrote: Done. As per the wiki, http://wiki.apache.org/incubator/ WadiProposal, created wadi-dev@incubator.apache.org [EMAIL PROTECTED] wadi-user@incubator.apache.org wadi-commits@incubator.apache.org And put jgenender and myself as moderators. Any other moderator volunteers welcome. On Dec 14, 2005, at 10:12 AM, Geir Magnusson Jr. wrote: I'm looking at doing the mail lists for WADI. The wiki says wadi-dev wadi-user etc... but is this @incubator or @geronimo? Yes, the G PMC is the sponsor, but WADI could potentially be a TLP... Let me know... geir -- Geir Magnusson Jr +1-203-665-6437 [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] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DONE : Re: WADI mailing lists
All of the developers? I asked clearly before I made the lists, and there seemed to be some interest in keeping it @incubator in the event that it was a TLP when done. Has that now been ruled out? If you are sure this time, and it is actual consensus, please just post an infra JIRA. geir On Dec 15, 2005, at 6:21 PM, Bruce Snyder wrote: On 12/15/05, Bruce Snyder [EMAIL PROTECTED] wrote: On 12/14/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Done. As per the wiki, http://wiki.apache.org/incubator/ WadiProposal, created wadi-dev@incubator.apache.org [EMAIL PROTECTED] wadi-user@incubator.apache.org wadi-commits@incubator.apache.org And put jgenender and myself as moderators. Any other moderator volunteers welcome. Thanks, Geir! The WADI developers would like to have these lists changed to @geronimo.apache.org instead of @incubator.apache.org. Geir, can you take care of this or would you prefer that I ask someone else? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DONE : Re: WADI mailing lists
BTW, where was that discussion? On Dec 15, 2005, at 6:21 PM, Bruce Snyder wrote: On 12/15/05, Bruce Snyder [EMAIL PROTECTED] wrote: On 12/14/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Done. As per the wiki, http://wiki.apache.org/incubator/ WadiProposal, created wadi-dev@incubator.apache.org [EMAIL PROTECTED] wadi-user@incubator.apache.org wadi-commits@incubator.apache.org And put jgenender and myself as moderators. Any other moderator volunteers welcome. Thanks, Geir! The WADI developers would like to have these lists changed to @geronimo.apache.org instead of @incubator.apache.org. Geir, can you take care of this or would you prefer that I ask someone else? Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' The Castor Project http://www.castor.org/ Apache Geronimo http://geronimo.apache.org/ -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @domain for Incubator mailing lists
since it's so easy to move them, should we move the latest projects coming into incubator to @incubator? geir On Dec 16, 2005, at 4:01 PM, Noel J. Bergman wrote: There has been some discussion and confusion over where to put mailing lists for projects that are in the Incubator. As the person who argued for the current approach, which had to do with infrastructure issues, I'm also going to suggest that it change. We are finding that it is more and more important to highlight when a project is in the Incubator, and to ensure that there is no confusion in the mind of the public about that status. The current approach is to put the mailing lists under the domain of the TLP into which it was expected that they would go, and THE REASON for this had to do with the difficulty of moving the mailing lists and the eyebrowse archives. HOWEVER, Roy has since written a script to move mailing lists, and we no longer use eyebrowse. And unlike the prior setup, it is fairly straightforward to redirect an old archive location to a new one. THEREFORE, new mailing lists should be created under the @incubator.apache.org domain, just as all of the other project resources, e.g., the web site and SVN subtree. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @domain for Incubator mailing lists
On Dec 16, 2005, at 5:35 PM, Dain Sundstrom wrote: My personal preference is to have incubated sub-projects use mailing lists and websites within the TLP containing a notice header that the project is under incubation (and may die). My understanding is that you feel having the email address containing the word incubator will warn users, and I believe that we can achieve the same (or better) with a mail footer that contains the notice. Note: we already have footers automatically added to every email. Regardless, my desire for consistency vastly out weighs my arguments above, so if the this policy change is approved by the incubator community, I would like to see all mailing lists (with the exception of the few that are about to graduate) be changed to @incubator. To what end? -dain On Dec 16, 2005, at 1:30 PM, William A. Rowe, Jr. wrote: Geir Magnusson Jr. wrote: since it's so easy to move them, should we move the latest projects coming into incubator to @incubator? If the list is relatively new, then yes. It would seem silly to do this to a project that's been around 6 mos+ and is nearing graduation (or the -other- alternative disposition). On Dec 16, 2005, at 4:01 PM, Noel J. Bergman wrote: The current approach is to put the mailing lists under the domain of the TLP into which it was expected that they would go, and THE REASON for this had to do with the difficulty of moving the mailing lists and the eyebrowse archives. HOWEVER, Roy has since written a script to move mailing lists, and we no longer use eyebrowse. And unlike the prior setup, it is fairly straightforward to redirect an old archive location to a new one. THEREFORE, new mailing lists should be created under the @incubator.apache.org domain, just as all of the other project resources, e.g., the web site and SVN subtree. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
