Re: Graduating a part of an incubating project into an existing TLP
Justin Erenkrantz wrote: On 9/13/06, robert burrell donkin [EMAIL PROTECTED] wrote: however IMO the IP clearance document should still be created and committed so that it's easy to track the origins of the code. questions about provinence can sometimes be raised years later and it has sometimes proved difficult to track down old email discussions. the document should be trivial but at least it'll be in the right place in case anyone needs it down the line. Here's another case where I'm not seeing the IP clearance form either on our site. Was the Graffito clearance only faxed to Jim? -- justin Yes, I was not even aware of an IP form when this was done (I would guess it probably didn't exist at that time). The external base code was a simple software grant from a single vendor. Everything else has been developed in SVN by existing committers. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduating a part of an incubating project into an existing TLP
Jukka Zitting wrote: Hi, There's recently been interest within both the Graffito and Jackrabbit communities to graduate a part of the incubating Apache Graffito project, an object-to-content mapping tool called Graffito JCR Mapping, into a part of the Apache Jackrabbit TLP. This move would both allow the Graffito project to better focus on the higher-level Graffito framework and bring the mapping tool development within the larger JCR developer community in the Jackrabbit project. I'd like to get feedback on how to best achieve this. Is there already an example on something like this having been done? Any good advice? The original plan was to graduate Graffitto into Portals since the orignial submission was strongly tied to Jetspeed. Since then, the evolution of code and community make me feel that Portals would *not* be the best home for Grafitto. Jackrabbit could be a nice host community for at least part of the project (JCR mapping tool). I'm unsure how the rest of the CMS would fit into Jackrabbit. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduating a part of an incubating project into an existing TLP
Niclas Hedhman wrote: On Tuesday 12 September 2006 17:07, Jukka Zitting wrote: No. As I wrote (emphasis added): to move the codebase *and* to bring the mapping tool developers in as Jackrabbit committers The purpose is not to change who is actually working on the code, but to bring the development into a community that probably has more willing and able new users and contributors for the codebase in question. Hmmm... That is not for Incubator to decide. If you transfer the codebase to Jackrabbit, it is for the JackRabbit PMC to apply meritocracy-based acceptance of committers into JackRabbit TLP. I.e. it sounds to me that the most natural way forward is that JackRabbit PMC makes a proposal to the Incubator PMC for IP clearance of the said codebase, and then deal with the committership in their PMC. Just to clarify things: IP clearance into the ASF for the original submission is done and dusted. All additionnal code has been developped and committed by project committers with an iCLA on file so I would consider IP not an issue here. Discussions have already happened in both the Grafitto and the Jackrabbit communities to move development of the JCR mapping functionality into the Jaskrabbit community and the feedback seemed positive on both ends. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Looking for help mentoring Graffito.
I'm currently the only mentor for the Graffito project that has been under incubation for nearly 2 years now. Graffito is a CMS system now built on top of Jackrabbit and providing a portlet based user interface. As such it is mostly suited to integrate with portal containers like Jetspeed but some of the services provided (like JCR mapping) can be useful outside of portal context. While we've managed to slowly build a community around the initial 2 men codebase, we're still very far from having a sustainable independant community around Graffito. Due to my numerous other activities, I feel I cannot provide alone the adequate mentoring required by this project and I am looking for additionnal mentors to help grow the Graffito community and graduate it. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [incubator docathon] podling proposal template
robert burrell donkin wrote: here's a basic outltine. please dive in and post comments, annotations, corrections, enhancements. i'll pull together a document from the consensus --- PROJECT PROPOSAL 0. Rationale 0.1 Criteria Meritocracy: Community: Core Developers: Alignment: I think it's important to stress that above criteria should describe *the current situation* of the project being proposed and not some lofty ideal goals/boilerplate statements lest we always come with gems like: Meritocracy: Apache was chosen for an incubator primarily because of the guidance the community can provide. which are completely unhelpful. 0.2 Warning signs Orphaned products: Inexperience with open source: Homogenous developers: Reliance on salaried developers: No ties to other Apache products: A fascination with the Apache brand: I personnally have an issue with the above warning sign. It's a very important one but no proposer (unless they are terminally stupid) will write that they want to be incubated mainly because they like the Apache brand. I think all these warning signs should not (and actually can't meaningfully) be filled out by the proposed project. They need to give us the information weneed to evaluate the project against those criteria/warning signs but can't really give us a ready answer. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] XAP (Extensible Ajax Platform) Proposal (was XAP (Extensible Ajax Platform) Proposal)
Coach Wei wrote: Raphaël Luta wrote: Before voting, I just have one (set of) question: Where's the source code ? Does it actually exist as a standalone, downloadable entity ? Is it possible to assess its current status before voting ? We are still a few days away from completing our due diligence process on the initial code base before being able to license it all under the Apache-compatible License. Once this process finishes up, we will be able to make the code available (or check it in to svn if the proposal is approved). I wish this process would have already been done by now, but it's important to us to be 100% certain that there are no surprises with the IP. I was under the impression that a review of the code base was not a requirement for incubation, especially since the code base could significantly change as soon as others are involved with it -- remember, this isn't about keeping the code the way it is now -- it's about using it as a jumping off point for whatever is the best cross-browser, declarative Ajax framework we all can come up with. AFAIK, a code review is not a requirement but it *is* usual practice to provide a code drop along the proposal when the code is not public yet. The IP work can be done after incubation is accepted. I was just trying to get a sense of the current maturity of the projet: is it working/functional, how full featured, etc... The fact that no demo is available makes me think it's probably not fully usable yet. It's not a problem for incubation but it sure is nice to know beforehand. However, if I was wrong about that, I'll understand if the vote needs to wait until the due diligence is completed. In any case, I can provide anyone whatever details they would like about the shape of the code base now. For instance, the project currently consists of about 8000 to 1 lines of Javascript, a few thousand lines of unit tests, plus over 1 lines of library files. 10k lines of Javascript in addition to whatever toolkit you're using (Dojo, etc..) !? mewonders where all the web *lightweight* clients have gone... /me -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] XAP (Extensible Ajax Platform) Proposal (was XAP (Extensible Ajax Platform) Proposal)
Cliff Schmidt wrote: Since this project was proposed a couple weeks ago, it now has a champion, three mentors, and has further diversified its initial committership. Additional details about the project have been discussed on this list, and I don't believe there are any unresolved concerns. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end in the middle of the weekend; so I'll propose extending that by an additional day, with the vote closing on Monday May 22, 2006 18:00 UTC (see http://www.timeanddate.com/worldclock/fixedtime.html?month=5day=22year=2006hour=18min=0sec=0p1=0) Please vote on the XAP proposal (rev 12 on the wiki and copied below). Before voting, I just have one (set of) question: Where's the source code ? Does it actually exist as a standalone, downloadable entity ? Is it possible to assess its current status before voting ? The XAP idea is intriguing but I'm trying to figure out the maturity and usability of current codebase vs stated goals and I couldn't find anything on the nexaweb site to point me to a working example, all demos available seem to be based on Java client and not AJAX client. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ADF faces proposal
Martin Marinschek wrote: Hi *, Craig has already mentioned that there is the ADF faces proposal of a JSF component library donation to the ASF - we, the Apache MyFaces PMC would love to take this component set in. We have already voted positively - does the incubator PMC according to the new rules need to vote, too? I'm not sure the Incubator PMC has to vote on it too, however I have a question on the proposal: from the paragraphs quoted below, it looks like the ADF codebase comes with no committer. Is it just a code dump ? If some external initial committers are going to be added, can you please provide a list ? snip Core Developers: ... Three PMC members from the MyFaces project are currently planning to become active ADF Faces developers, others will hopefully follow: * Matthias Wessendorf * Martin Marinschek * Bruno Aranda snip Reliance on salaried developers: Although ADF Faces was built by Oracle developers, initial interest from the MyFaces community seems strong. We anticipate several MyFaces community members to join the ADF Faces effort which will dilute this project's reliance on Oracle developers overtime. Meanwhile, Oracle will continue to support the project by dedicating full time resources, to ensure a smooth transition into Apache. snip Source- and binary downloads can be found at: [WWW] http://people.apache.org/~bdudney/apache-drop.zip snip (4) identify the initial set of committers (4.1) Already ASF committers (4.2) Scheduled Apache users (4.3) Not scheduled, Contributors (4.4) Unknown -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ADF faces proposal
Manfred Geiler wrote: On 3/9/06, Raphaël Luta [EMAIL PROTECTED] wrote: Martin Marinschek wrote: Hi *, Craig has already mentioned that there is the ADF faces proposal of a JSF component library donation to the ASF - we, the Apache MyFaces PMC would love to take this component set in. We have already voted positively - does the incubator PMC according to the new rules need to vote, too? I'm not sure the Incubator PMC has to vote on it too, however I have a question on the proposal: from the paragraphs quoted below, it looks like the ADF codebase comes with no committer. Is it just a code dump ? If some external initial committers are going to be added, can you please provide a list ? * John Fallows [EMAIL PROTECTED] * Jonas Jacobi [EMAIL PROTECTED] * Omar Tazi [EMAIL PROTECTED] * Adam Winer [EMAIL PROTECTED] OK. I really think you should update to proposal to include the complete initial committer list, including any current MyFaces (or other existing) committers that wish to participate in ADF. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Mission of the incubator
Sam Ruby wrote: snip/ As I said, my perspective is different than yours. What I see is people who try to move the goalposts and establish ad-hoc rules to exclude people and proposals they don't intend to participate in. Most such efforts are self-defeating, so I don't get too worked up about it. I don't know exactly what you mean by the moving the goalposts but it's quute clear we have a much different point of view on incubation how it can best serve the ASF. I'll develop my pont of view in another reply but I just want to address the following point: One attempt to move the goalposts was to disqualify Andy as he was in the pay of the project sponsor. The clear implication being that Andy isn't one of us, he is one of them and can't be trusted. I defy anybody to attempt to apply that particular standard to Roy Fielding and JackRabbit. You have misunderstood my concern about Andy being in the pay of the sponsor. It's not an issue of us vs them, but the fact that he's both one of us, one of them and also the *only* ASF representative in the original proposal. This would put him in the awkward position of possibly having to chose a side in case the ASF and Zimbra ever have diverging interests. To illustrate my concern and contrast with Roy Fielding's situation in Jackrabbit: A # before a name represents employees of the sponsor A single * after a name is an existing ASF committer A double ** after a name is an ASF member. AjaxTk/Kabuki initial community: 1st proposal 2nd proposal 3rd proposal 4th propsoal Mentors: - #A.Clark**#A.Clark**#A. Clark** S. Ruby** P. Freemantle** S. Weerawarana** Committers: C. Becker #A. Clark** #A. Clark** #A. Clark** L. Bustelo#C. Damon #C. Damon #C. Damon #A. Clark** #R. Dargahi #R. Dargahi #R. Dargahi #C. Damon #R. Schemers #R. Schemers #R. Schemers #R. Dargahi #P. Shah #P. Shah #P. Shah B. Gibson #G. Solovyev #G. Solovyev #G. Solovyev J. PedemonteM.Marinschek* M. Marinschek* A. Peller #R. Schemers D. Sedota #P. Shah #G. Solovyev Jcr/Jackrabbit initial community: = 1st proposal Mentors:#R. Fielding** Committers: #R. Fielding** #S. Guggisberg* S. Mazzocchi** #D. Nuescheler #P. Piegaze G. Rabellino** T. Reilly* #M. Reutegger P. Russell* A. Savory* #T. Strasser S. Wallez** As you can see from the above table, the AjaxTk 2nd proposal was entirely composed of # people, mentor included. AFAIK, that's something that never happened in the Incubator and something I'm keen not to see happening as a precedent. I see a clear risks in such case of creating a jboss-like community where one company has full control on the destiny of the project. Kabuki 4th proposal addresses that concern by adding more diversity in mentors, I'd still wished they took time to field more diverse initial committers as Roy did in the initial Jcr proposal. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RANT] Mission of the incubator
Daniel John Debrunner wrote: Raphaël Luta wrote: As you can see from the above table, the AjaxTk 2nd proposal was entirely composed of # people, mentor included. AFAIK, that's something that never happened in the Incubator and something I'm keen not to see happening as a precedent. Actually Derby had all IBM committers initially and an IBM mentor (Ken Coar). We used the incubation process to successfully increase the diversity of the community, even when IBM bought the company employing our first (and then only) non-IBM committer. :-) I think everyone worked hard to ensure that it was an ASF project and not an IBM one. Good point, I should have double checked all my facts before stating something *never* happened :( It's still something I'm very unconfortable with and would not like to see established as a pattern. Also, if I remember correctly the graduation discussions on [EMAIL PROTECTED], developper community diversity was one of the key issues raised upon graduation. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Andrew Clark wrote: Raphaël Luta wrote: - no source control access We have read-only CVS access[1] already for the entire project. The details should definitely be more visible, though. I'll talk to someone about getting it more prominent on the main site. I missed the link. It should indeed be more visible :) I understand that you wouldn't want to setup your own public dev infrastructure but using sf.net, codehaus, tigris or whatever public infra wouldn't have been very onerous. My concern here is if no resources have been dedicated so far to really build the AjaxTk into an OSS project why would that change once it is in incubation ? Let me try to summarize what I think your point is and you can tell me if I'm wrong. You would feel better about the submission if it were already a fully formed OSS project on an external site with full development infrastructure and long-time active community. Is this accurate? The long time active community is not accurate and building such a community is a main reason for the Incubator. As far I can tell, what needs to happen to fully OSS AjaxTk is something like this: - cleanup the code/doc/install so that Tk can be consumed by a public community - rework a clear internal separation between AjaxTk and ZCS with different repos, dependency management, indep release cycle, and so on... - adjust internal dev processes to deal with the public infra (and possibly some early external dev) - start building a long term external community by actively attracting new committers I would feel more comfortable if the first 3 steps would be done somewhere else before any incubation starts so that incubation can really focus on the last point. Apache does not bring any value in the first 3 steps that you can't bring by yourself as an ASF member and the amount of work and risk of failure in those 3 first steps is IMO significant. The benefit of such a 2 step process is that this gives you an actual public track record before incubation is decided and voids most concerns about incubation being a pure branding exercicse since a significant amount of work would already have been spent in making the AjaxTk OSS independantly of any Apache commitment. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] KabukiProposal
Sam Ruby wrote: http://wiki.apache.org/incubator/KabukiProposal Contents of proposal reproduced below: snip / -0,9 -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Sanjiva Weerawarana wrote: On Mon, 2006-01-23 at 13:38 +0100, Raphaël Luta wrote: Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. My admission bar for such proposals is set much higher than usual. With all due respect Raphael, I find this unreasonable. You can't make random admission bars for projects based on personal prejudices. What I suggest is that you join the project as a mentor and make sure push them hard to make sure they come out clean as whistle or hold them in incubation until its killed. That way you convince yourself that the project is good *from the ASF points of view* (community, meritocracy etc.) but not from things like visibility point of view which by no means are a requirement. I would agree with this if there was no immediate percieved benefit when you are in Incubator, unfortunately it seems projects under incubation are still perceived by the larger community as endorsed by Apache. As long as this is true, accepting a project in the incubator even if it stays there indefinitely *does* matter to me. In the end, I don't think it's a personal prejudice but more a lack of trust in the motivations of the proposal. What's the status of the vote? I'm confused by calls to repeal the vote and modifications to the vote and all that. I thought we were spsed to be a simple bunch of, um, people but it sure doesn't look like it! ;-) I'm confused too by the voting process and repeated proposals even before the discussion has died down. Am I spsed to vote my choice at this time or is there no vote going on? So confused. Must be the freezing weather in Sri Lanka these days. Its been like 65F in Colombo at nite. Brr. 27F here in Paris, It sure wakes you up in the morning :) -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Andrew Clark wrote: Raphaël Luta wrote: Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. Thanks for your answer Andy. It sure helps flesh out your motivations. The Zimbra product owes much of its success to open- source products, especially from Apache. The Kabuki submission for incubation is an attempt to give back to the community that's given us so much coupled with the fact that we believe browser-based client coding with Ajax is a natural fit with the web-centric theme of Apache projects. Here we completely agree that Ajax certainly has a place in the ASF. Our core business is collaboration and competing against Exchange server; we aren't a tools or toolkit company. As such, we are not associating the Zimbra brand with the toolkit and aren't planning on making money from this effort. I hope that goes a little way towards easing some people's concerns regarding the submission. I completely understand that you're not a toolkit company however I can't understand why the AjaxTk is currently in such a sore open-source state: - the code dumps on the site are not functional out of the box - no source control access - the sourceforge site is half configured and no links have been created to this tk (freshmeat, etc...) I understand that you wouldn't want to setup your own public dev infrastructure but using sf.net, codehaus, tigris or whatever public infra wouldn't have been very onerous. My concern here is if no resources have been dedicated so far to really build the AjaxTk into an OSS project why would that change once it is in incubation ? It could be done now in sf or codehaus. That would trigger all the zimbra internal changes that will have to happen to make such a task work (like how to manage the internal and external source repositories, commit access, bug reporting, public design decisions, etc...). You will pick an initial community then but most importantly work out the internal issues that are bound to happen. Proposing an to enter incubation from that situation would be a no-brainer for me. One last note... the Zimbra marketing guy is well aware that PR for incubated projects will not be allowed and he's completely cool with that. Zimbra wants to do the right thing and are willing to commit resources to try to make that happen. However, if the Apache community is still uneasy about the submission and denies its entry to incubation, so be it. But I would love to see Apache take a role in crafting the future of AJAX programming (with the added personal benefit of being paid to work on Apache technology again :). I think it's hard to speak for the Apache community ;) In the end, we're all individuals and certainly don't agree on everything. I'm not completely comfortable with the current proposal mostly because I am concerned by recent PR issues and I got concerned by the amount of boilerplate text in the different proposals (reading the current line on meritocracy still makes me cringe). -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Noel J. Bergman wrote: Raphaël Luta wrote: Do we have other incubating projects following the Kabuki pattern, ie all initial committers from a single company with the mentor salaried by the same company ? I'd sure like to know how these evolved if we have any. Hmm ... I'd have to check, but XMLBeans, Beehive and Derby? Certainly Derby, which was brought in by IBM and Mentored by Ken and Sam. Interesting. Derby had 3 mentors so they would pass the 3 members check although they are all tied to the sponsor. Beehive seems to have had 2 members from the get go (dims and craig) none of them associated with the sponsor. XMLBeans had only 1 member/committer from the beginning but not affiliated with the sponsor. As far as i know, it has never been reviewed on the mailing-list probably because it didn't show up on the radar. So should we take the lack of use as a critique against anything other than visibility? No but should the ASF provide instant visibility to any framework without having the sponsor to work at least a little on the community before coming to the ASF ? Isn't AjaxTk already open-sourced ? If you want to try something, go on sf.net, freshmeat, etc... and try *finding* AjaxTk. It sure helps understand why it's not on anybody's radar. Seeing Zimbra current OSS efforts with this toolkit (even with an ASF member in their team), I have a hard time believing this proposal is anything but a branding exercise to help this toolkit stand out in the crowd of Ajax toolkits. My admission bar for such proposals is set much higher than usual. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Noel J. Bergman wrote: Raphaël Luta wrote: do you really feel comfortable when the main point of oversight for the ASF in an incubated project is in the pay of the project sponsor and quite possibly internally reporting to one of the project committer ? The potential for conflict is huge and I would personnally hate to be in such an awkward position. I can think of examples supporting your view, but most probably support Roy's. By trying to get at least 3 ASF Members as active Mentors, perhaps we can better address the concern. Do we have other incubating projects following the Kabuki pattern, ie all initial committers from a single company with the mentor salaried by the same company ? I'd sure like to know how these evolved if we have any. I'm glad Martin has been added as a commmitter to Kabuli but I would feel much better about it if other existing memebrs/committers willing to work on that project would join. others from Portals may wish to give it a try but I somehow doubt it given that the toolkit didn't even show up in the short list when we first investigated the field for our AJAX support. Was it reviewed? Or just didn't show up on the radar? As far as i know, it has never been reviewed on the mailing-list probably because it didn't show up on the radar. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Roy T. Fielding wrote: On Jan 19, 2006, at 12:36 AM, Raphaël Luta wrote: We're doing loops here. My point in this thread is that initial code quality does matter in a code grant incubation because it is often burdened by backward compatibility with existing applications and thus major restructure may require a revolution which can hardly safely happen in the early months of the project open-source life. And all those points are wrong. There is no burden of backward compatibility because it must be an entirely new product -- all of the names change anyway. A major restructure is a good idea; that is, after all, why we founded Apache as a project to replace NCSA httpd 1.3R, which was replaced by Shambhala within 6 months. And it certainly doesn't have to happen safely -- the project is going to be shooting for TLP status, which means about a year or more under incubation before it can even do real releases, and the more hard decisions the group has to make (in public), the better they will learn how to collaborate. I fail to see how you can apply the httpd situation (standalone server, initial community with independant contributors, most downstream users relying on standard http/cgi) to the current proposal (development toolkit/framework, community with hierarhical relationships and downstream users code-dependant on toolkit). You take the optimistic view that the community would work as expected; I have a pessimistic view that it will not without some cost to the ASF if at all. Honestly, once the name is changed to something neutral like Kabuki, none of your objections make any sense. Especially the ones about code quality, since most of our projects started with code that needed a serious re-arch almost immediately. I would love to see three or four different ajax toolkits under the ASF, each with its own architectural focus, and let them compete for developers, but we can only approve one podling at a time. +1 I just wish they would join with a least a nucleus of public community. Meanwhile, I do think that any proposal to the Incubator needs at least three active Apache committers involved, preferably members that are willing to do infrastructure tasks. Incubator podlings are seriously infrastructure dependent and the existing volunteers are already tapped-out. +1 -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Le 19 janv. 06 à 02:57, Noel J. Bergman a écrit : Raphaël Luta wrote: I thought it would be safe to assume that Zimbra collaboration suite uses the AjaxTk. If it doesn't then I'm even more worried about that codebase ;) Why? Because then I would have to reconsider the orphaned product statement of the proposal. Anyway, as far as I can tell froom looking at Zimbra collaborative suite, it does depend on the ajaxTk. An established codebase is *much* more difficult to restructure than starting from scratch. Apache SOAP - Apache Axis Tomcat 3 - Tomcat 4 - Tomcat 5 - Tomcat 5.5 ... Jetspeed 1 - Jetspeed 2 ;-) My point exactly ! Most of these transitions have not been a smooth ride even though they are successful: it takes time and a resilient community to manage these. No one said that doing it was necessarily easy, but isn't creating resilient, healthy, communities a major part of our purpose? We're doing loops here. My point in this thread is that initial code quality does matter in a code grant incubation because it is often burdened by backward compatibility with existing applications and thus major restructure may require a revolution which can hardly safely happen in the early months of the project open-source life. -- Raphaël Luta - [EMAIL PROTECTED] Apache Jetspeed - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Sam Ruby wrote: Raphaël Luta wrote: Erik Abele wrote: It's just the initial code, nothing more :) I don't agree with this statement. The code itself is indeed only the initial codebase but along with this codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility snip I think my point is simply that in a code grant incubation scenario, initial codebase and initial community *do* matter because they'll act as natural forces towards stability and are likely to shape the community and codebase for a long time. Hopefully, at some point, these somewhat abstract discussion of concerns that are relevant to all proposals will solidify into concrete concerns regarding this specific proposal. I was simply in disagreement with Erik statement that initial code is not that important. It's tangential to the actual zimbra proposal. Is code irrelevant? That would be absurd. That's why the code has been made available for all to download, inspect and comment on. I think a more neutral restatement of what Eric and Noel are trying to say is that while good communities always overcome bad code, no amount of good code can make up for a bad community. While I more or less agree with this statement, I think that bad code can prevent a good community from happening in the first place, especially when good communities exist elsewhere. DisclaimerI've not reviewed the code so that statement above does not reflect any quality judgement on the proposed zimbra toolkit/Disclaimer On the other had, Raphaël, I see you making implicit assumptions that the committers will have entrenched interests that will be difficult to overcome, and that the existing community is mature. What evidence do you have of that? I'm sure that you can give examples of other communities where that was a problem, and I can give examples of other communities where that was NOT a problem. What do either examples prove? Nothing. What specific concerns do you have with this community and this codebase? If we're talking explicitly about the Zimbra proposal, here's my current understanding of the proposal : Of the 4 Criteria listed in the proposal, only 1 is met by the proposal: Alignment to ASF All 3 others are filled with boilerplate statements that indicate: - the project does not use at all a meritocratic model right now - there's no community - the core developers are strongly bound to a single entity with only Andy being easily traced to prior open source activity Of the 6 warning signs listed: - 1 is defintitely not met: the Zimbra toolkit is not an orphaned product - 1 is possibly met: Inexperience with open-source, again 30 minutes of Googling for the zimbra team show little oss credentials - 1 is probably met: fascination with Apache brand, but I'll admit it's a personal interpretation - 3 are definitively met: - reliance on salaried developers - homogenous developers (I'll admit that IMO if the 2 are often linked) - no ties to other apache products Additional personal expectations: - the Zimbra collaboration suite uses the AjaxTk so there will be some backward compatibility burden attached to the codebase. - if incubation is accepted, I expect a lot of PR noise around it due to hype surrounding AJAX and aggressive communication profile of Zimbra Positive signs: - the updated proposal has attempted to fix some of the issues raised after the first proposal that could be fixed (scope, number of initial committers) Negative signs: - the mentor for this project is salaried by the project sponsor ! - I can trace no public attempt to meet other possible user apache communities (myfaces, portals, cocoon, etc...) even after first proposal rejection - I see negative technical feedback on the proposal from ASF people I trust left unanswered When you put all this together, you can understand I'm hardly enthusiastic about this proposal. What would change my opinion ? 2 must have: - no PR before graduation - an independant mentor 1 nice to have: - some ties with a possible downstream community, possibly adding some of their committers in the initial committer pool -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Noel J. Bergman wrote: Raphaël Luta wrote: along with [a] codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility That carries a fairly large assumption, and really should be posed as a question, not an answer. I thought it would be safe to assume that Zimbra collaboration suite uses the AjaxTk. If it doesn't then I'm even more worried about that codebase ;) An established codebase is *much* more difficult to restructure than starting from scratch. Apache SOAP - Apache Axis Tomcat 3 - Tomcat 4 - Tomcat 5 - Tomcat 5.5 ... Jetspeed 1 - Jetspeed 2 ;-) My point exactly ! (and you could add httpd 1.x - httpd 2.x) Most of these transitions have not been a smooth ride even though they are successful: it takes time and a resilient community to manage these. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
Erik Abele wrote: Oh, of course - but for now there's no community yet so he is complaining into the blue sky :) I'd certainly like to see a response to the concerns raised by Martin but OTOH I don't think that it should evolve into a discussion about basic architectural principles or even impact the final consideration of incubation. It's just the initial code, nothing more :) I don't agree with this statement. The code itself is indeed only the initial codebase but along with this codebase come an established group of committers with an interest in keeping their current architecture or at least backward compatibility An established codebase is *much* more difficult to restructure than starting from scratch. Even if someone would be willing to contribute to this projet to help address major technical issues, it would require a huge amount of effort to effect a significant architectural change because of community inertia and backward compatibility requirements. From what I've seen at Apache, major rearchitecture work always happen as a revolution with an entirely new implementation being built and these revolutions are dangerous to a project communiy health. Given the frictions created by revolutions, it's important that these do not happen before the community is mature else they may simply split it. I think my point is simply that in a code grant incubation scenario, initial codebase and initial community *do* matter because they'll act as natural forces towards stability and are likely to shape the community and codebase for a long time. Just my 2 eurocents, -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX Toolkit Framework Proposal
Martin Cooper wrote: snip Personally, I am less than happy at seeing yet another large project proposed from a corporate source (and IBM at that), along with a dozen new committers who have not earned their merit at the ASF as most committers have. I feel the ASF is losing its way, and becoming a repository for corporate open-sourcing along with taking on responsibility for building communities around corporate code bases. I suspect I'm in the minority at the ASF, and I'm undoubtedly in the minority here in the incubator. But there doesn't seem to be a way for the incubator to say no thanks, other than by a podling failing the incubation process, and that seems wrong to me. You may be in the minority but you're not alone, I'll admit to being *very* uneasy on this proposal. To me it raises all the possible incubation warning bells: Criteria * Meritocracy: I don't believe it looking at the committer list. Who's going to argue with his VP of engineering ? To create a real meritocracy, you can't have an established hierarchy in the committership. * Community: none * Core developers: no existing Apache committer or Apache member * Alignment: no simple mission statement but trying two roll out 2 complementary sub projects into a single community. Warning signs = * Orphaned products: Apparently no * Inexperience with open-source: Limited experience if I judge by the number of OSS related hits tied to the proposed committer names on Google. Only 3 names get some hits. You can also how Zimbra as a corp currently gets it here: http://www.zimbra.com/community/ * Homogenous developers/salaried developers: Definitely yes, all work for 2 companies with strong hierarchical ties in the proposed committer base * No ties to Apache products: True * Fascination with Apache brand: True, just see prc@ activity. As is, I can't see a single reason to support the proposal ans see several to vote a strong -1 on it in its current form : - The proposal is too large to incubate, it's hard enough to create a community from scratch around a single well-defined goal and codebase, rolling 2 together is suicide in my book. - I don't see any benefit for the ASF and several drawbacks (more hard work and strain on resources, possible PR complications, additionnal strain on friendly relations with other OSS groups like Eclipse) - There's no mentor yet ! Bad sign... - The odds of this project of successfully exiting the Incubator based on the diversity of community criteria seem very low to me: there are too many initial committers and most of them will have strong internal communication channels which will be invisible from the community. - I don't believe most of the proposed committers would get committership on their own merit and I would hate the Incubator to become an easy way to bypass the meritocratic model of the ASF: work at IBM and get a free committership when they donate the codebase to the ASF ! Most of the time you end up with paid-for-committers that only last as long as they're told to work on the project. (This is not pure paranoia ;) just look at Pluto if you want to see it in effect) In summary I see this proposal as a high risk, low value offer to the ASF and would definitely pass on it. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX Toolkit Framework Proposal
Sam Ruby wrote: Raphaël Luta wrote: snip Overall, there is clearly strong interest in AJAX at the ASF, whether it be based on Zimbra or Dojo or whatever. Furthermore, the proposal needs to be revised, particularly to incorporate the people who have expressed an interest in participating and creating ties to other projects. I completely agree that there's a strong interest in AJAX from many Apache communities, Portals included. It's something many people in many communities are trying to figure out how to best tackle, however so far I've never seen Zimbra mentioned in an Apache community in this regard. --- Criteria sniping some parts to keep mail shorter * Community: none A bit overstated. There is a community, but it has yet to be incubated and certified as following the Apache way. I can't see any existing community described in the proposal, I can't find any public forum about Zimbra AJAX toolkit and everything I get from Google is press releases, whitepapers and conferences. If you could point me to an existing online public community, I'll gladly admit I am overstating the current situation. * Core developers: no existing Apache committer or Apache member That's the initial proposal. The proposal was immediately was met with several volunteers. It was indeed met with interest from several Apache committers, that doesn't make them core developers though since they are not part of the current development effort. It does show a potential for community building. Warning signs = * Orphaned products: Apparently no I'm not certain what you are trying to say here. Trying to express that the toolkit doesn't seem to be orphaned as it is probably actively used by Zimbra other products. * Homogenous developers/salaried developers: Definitely yes, all work for 2 companies with strong hierarchical ties in the proposed committer base Again, the proposal was immediately met with volunteers. I will state that everybody involved fully understands that the current level of diversity certainly would not meet the incubator's exit criteria for a project - and everybody supports the goal of building a diverse community. My point was more than given the huge number of initial committers I would expect it to grow to at least 35-30 committers with all new committers from external parties before such a community could be called balanced. Starting from scratch and getting to this level is a *huge* task, especially if you don't have another established community as a userbase. To help you see it another way, take a look at the following link: http://ajaxian.com/archives/2005/12/apache_ajax_too.html AJAX is hot. People outside are watching. IBM and Zimbra will undoubtably get a lot of press people asking questions. My experience has been that such people are well trained in saying no comment, but the fact is that there is interest, and at some point it makes sense to meet such interest with facts. I'm seeing and am actually actively looking because Ajax has some critical impact on web applications and portals in particular. One of the key comments I frequently see is: Why does this/that project have to be in the ASF ? and frankly I can't think of a good reason why the ASF would want to kickstart a brand new AJAX community. Several other exists, are working well and are compatible with our IP, why create something new within the ASF rather than join those existing communities ? As is, I can't see a single reason to support the proposal ans see several to vote a strong -1 on it in its current form : - The proposal is too large to incubate, it's hard enough to create a community from scratch around a single well-defined goal and codebase, rolling 2 together is suicide in my book. I don't mean to minimize the concern, but we have incubated larger. As we have seen in this and other donations - IP lawyers are very interested in clearly delineating the precise origins of each component. As such, we've overstressed the separate nature of these pieces. Just to be clear: the goal is to build one community. Yes we have incubated larger but not always to very good results and tackling something with as many different pieces is definitely a big challenge. - I don't see any benefit for the ASF and several drawbacks (more hard work and strain on resources, possible PR complications, additionnal strain on friendly relations with other OSS groups like Eclipse) There definitely is interest in AJAX at the ASF. If not Zimbra, then Dojo. And as Sanjiva and Dims have eloquently put it I have no patience for any kind of this space is mine, you keep to yours type nonsense. I totally agree that the only discussion here should be does ASF want to take this on or not, not on whether
Graffito report
This is the (short) quaterly report for Graffito: * The main news in this quarter is that we have expanded the committer base beyond the original contributors with the addition of Oliver Kiessler and Sandro Boehme. * Both are busily working on building support for JCR (through Jackrabbit). * Work is also underway to use Graffito as a native CMS engine in Jetspeed 2. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Graffito report
Graffito Report 25/04/2005 -- 1) Any legal, cross-project or personal issues that still need to be addressed? no 2) What has been done for incubation since the last report? * The most important work was made on the Jetspeed 2 integration building some JSR-168 portlets. There is a content tree view, a document viewer and an admin browser portlet. Futhermore, we have integrate an HTML editor (Kupu). * Some work has been done for the security management (fine grain access control, permission management, JAAS support, ...). * We have started raising awareness and promoting the project on some other Apache and non-Apache lists in order build further the community. * New developers have started collaborating with the core team on Graffito work, especially JCR mapping tools. 3) Plans and expectations for the next period? * Implementing our JCR mapping framework with Jackrabbit. * XML editor integration. * A Graffito implementation for the Jetspeed 2 page manager. * Continue our work on the JSR-168 portlets (search version management). * Start a site demo with a Jetspeed integration * We expect the committer base to expand during next period given the current developer participation on the dev mailing-lists. 4) Any recommendations for how incubation could run more smoothly for you? None so far. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Graffito incubation status report 05/01/14
1) Is the STATUS file up to date? Yes 2) Any legal, cross-project or personal issues that still need to be addressed? * Software grant has been recieved by the ASF. * All trademark issues with project name have been resolved. * We have renamed the JCMS project as Graffito to avoid naming confusion with Jalios JCMS, another Java based CMS system. 3) What has been done for incubation since the last report? * We cleaned up repository, site, build process, site deployment and publishing to help new users and developers jump into the project. * Christophe Lombart account has been created and karma granted * ASF Infrastructure has been set up for Graffito * We are working on the Jetspeed 2 integration building JSR 168 portlets. 4) Plans and expectations for the next period? * Add more info in the Graffito site * WEBDAV integration * More work on Jetspeed 2 integration, building portlets. * Introduce Graffito to some important related projects: Slide, JackRabbit, Jetspeed ... in order to grow the development community 5) Any recommendations for how incubation could run more smoothly for you? None so far. -- Raphaël Luta - [EMAIL PROTECTED] Aptiwan, l'intelligence du réseau - http://www.aptiwan.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Announce] Graffito (ex JCMS) has entered Incubator
On behalf of the Graffito team and the Apache Portals PMC, I'm please to announce that Graffito, formerly known as JCMS, has completed its transition to the Apache Incubator. The main objective of Graffito is to create a portal oriented content management system. It's currently build on top of Apache Slide and the team also plans to support access to JCR content repositories through Jackrabbit. Graffito user interface is managed with a set of JSR-168 portlets that can be deployed in compatible portal systems such as Apache Jetspeed. If you are interested to learn more on Graffito, please consult the project website at: http://incubator.apache.org/graffito/ To join the user and developper community, please subscribe to [EMAIL PROTECTED] by sending a mail to [EMAIL PROTECTED] To checkout the current codebase, you can download it through our Subversion repository: https://svn.apache.org/repos/asf/incubator/graffito/trunk/ -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please check/post your PROJECT RESOURCE REQUESTS
Noel J. Bergman wrote: Folks, Project resources (mailing lists, etc.) are being created tonight. Please remind us ASAP of any pending requests. JDO and Agila mailing lists should be done. I have the following requests pending for Graffito: Mailing-lists: -- Name: [EMAIL PROTECTED] Archives: public, Eyebrowse Moderator: [EMAIL PROTECTED] Name: [EMAIL PROTECTED] Archives: public, Eyebrowse Moderator: [EMAIL PROTECTED] I don't believe we need a ppmc list since gaffito will be part of Apache Portals and is monitored by Portals PMC. Repository: --- It's set up and authorization is configured in SVN but not in live file. Commit mails need to be configured. JIRA: - Creation of a Graffito module (id: GRFT) Module administrator: David Sean Taylor ([EMAIL PROTECTED]) Thanks. -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NameProtect (www.nameprotect.com)
Ted Husted wrote: Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. Do we have an account with NameProtect? A prior post mentioned using the free internet search, but I don't see one of those now. -Ted. I didn't find any neither. You can always use directly the USPTO site to research the US Federal trademarks. http://tess2.uspto.gov/bin/gate.exe?f=tessstate=fk3cds.1.1 -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can 'Graffiti' be used for a software project ?
Working with the JCMS team on the existing IP, we found that JCMS was not a good name because a CMS package with this name already exists even though it's not trademarked in the US (Jalios JCMS). The team wants to change the name to 'Graffiti' but of course there's already a Palm trademark on this name. (registered as IC:09 US:38) at USPTO. My question is: what are the relevant trademark US classes to sort out which names are acceptable and which names are not ? -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can 'Graffiti' be used for a software project ?
Noel J. Bergman wrote: As soon as I saw the message subject, I thought of the other project, which actually pre-dates Palm, and was first available on the Apple Newton. Yes me too. The question was more from a legal standpoint would a Java based CMS software and a hand-recognition system embedded in physical devices be considered in the class and thus infringing or separate applications and thus be non-infringing ? Palm registration is in IC 09 (Electrical Apparatus) and US 38 (Prints and Publications) Is this the standard classes for software trademarks in the US ? -- Raphaël Luta - [EMAIL PROTECTED] Apache Portals - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can 'Graffiti' be used for a software project ?
Le 23 déc. 04, à 17:59, Noel J. Bergman a écrit : The question was more from a legal standpoint would a Java based CMS software and a hand-recognition system embedded in physical devices be considered in the class and thus infringing or separate applications and thus be non-infringing ? You'd have to check with our lawyer(s), but I'd think that another name might be a good idea. You might look at the etymology of graffiti, and see if you like something related: graffito grapheion graphion ref: http://dictionary.reference.com/search?r=2q=graffiti Yeah, I'll advise Christophe and David in this direction. :( I still think a generic guideline on which trademark class we should look would be useful for future projects though... -- Raphaël Luta - [EMAIL PROTECTED] Apache Jetspeed - Enterprise Portal in Java http://portals.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
