Re: [ANNOUNCE] Apache JSPWiki 2.9.1-incubating released
I'll be the first to admit that I haven't been following along with the progress of this project at all, but I happened to notice that, according to the incubator projects page, this project has been in incubation for almost 6 years. That's an awfully long time in the incubator. What are the prospects of JSPWiki ever making it out of incubation? -- Martin Cooper On Wed, May 15, 2013 at 3:04 PM, Juan Pablo Santos Rodríguez juanpa...@apache.org wrote: The Apache JSPWiki team is pleased to announce the release of JSPWiki 2.9.1-incubating from the Apache Incubator. This is the second release of Apache JSPWiki, a feature-rich and extensible WikiWiki engine built around the standard J2EE components. The release is available here: http://www.apache.org/dyn/closer.cgi/incubator/jspwiki/ The full change log is available here: https://issues.apache.org/jira/browse/jspwiki/fixforversion/12321249 We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at http://incubator.apache.org/jspwiki/ The Apache JSPWiki Team
Re: [DISCUSS] Apache OGNL
On Fri, Apr 8, 2011 at 12:57 AM, Jeremias Maerki d...@jeremias-maerki.ch wrote: I'm sorry that I can't help out but when reading this I thought that using the spec name as the project name is probably not ideal. How about calling it Apache (Commons) Ogranal? Hopefully, this doesn't have any strange meaning in some language. Just a thought. Commons has a policy of using descriptive names. Yes, there are a few existing projects that don't fit this - ones that were grandfathered in when the policy was introduced - but it would be better to start incubation with a name that would meet Commons' criteria rather than one that will need changing yet again on graduation. A lot of people both within and outwith the ASF know the name OGNL, so unless there's a pressing need, it would make sense to keep it. -- Martin Cooper On 08.04.2011 09:26:43 Simone Tripodi wrote: Hi all guys, I'm almost ready to submit a new proposal I'm preparing on Wiki[1] for Apache OGNL. The idea is importing the OGNL project under the Apache umbrella and, once/if ready, be promoted in Apache Commons - the Commons PMC already voted to be the Sponsor. All legal issues have been resolved, we have the Champion - Lukasz Lenart - and a great Mentor - Olivier Lamy - what we miss are 2 more mentors... any volunteer? :) It would be nice also if you can provide your feedbacks, once raw the proposal. Many thanks in advance, have a nice day!!! Simo [1] http://wiki.apache.org/incubator/OGNLProposal http://people.apache.org/~simonetripodi/ http://www.99soft.org/ Jeremias Maerki - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Poddling new committer process
On Fri, Nov 12, 2010 at 12:20 AM, ant elder ant.el...@gmail.com wrote: I'd like to propose that the process for Incubator poddlings to make someone a new committer is simplified so that all that is needed are votes from poddling committers and that there is no longer any need for votes from Incubator PMC members or a separate Incubator PMC vote. What makes me uneasy about this is that, notwithstanding the one mentor vote, we are basically saying that the bar for ASF committership can now be defined solely by a group of people who might have no knowledge, as yet, of the Apache way in general and the way meritocracy works in particular. -- Martin Cooper As justification, this is the process that was in place some years ago and it worked fine like that, there is the experiment currently in place with some poddlings doing this which seems to be working ok, and the board has said they're ok with it. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Latest incarnation of site update?
On Sun, Apr 11, 2010 at 4:20 AM, Joe Schaefer joe_schae...@yahoo.com wrote: We switched the hourly find script from ctimes to mtimes to cut down on the rsync traffic by 10x. Since there have been so many complaints about this I will switch it back now. Should I expect that it would be updated by now, then? My changes are still not live. -- Martin Cooper - Original Message From: sebb seb...@gmail.com To: general@incubator.apache.org Sent: Sun, April 11, 2010 7:17:48 AM Subject: Re: Latest incarnation of site update? On 11/04/2010, Martin Cooper href=mailto:mart...@apache.org;mart...@apache.org wrote: What is the current mechanism for getting the live web site to update after committing the changes? There was some discussion of svnpubsub a while ago, so at first I thought it might be magic, but nothing happened. I waited an hour for an automatic update, but no luck. I logged in to people@ and 'svn up'ed - nothing. Still nothing after another hour. I even looked for instructions, but didn't find them beyond what's in the README, which stops at committing the changes. Now I'm stumped. We've been seeing much longer site replication times in Commons - upto 19 hours - so perhaps that is what is happening. You can use the proxy trick to view the site on people - just set the proxy to 140.211.11.10:80. -- Martin Cooper - To unsubscribe, e-mail: ymailto=mailto:general-unsubscr...@incubator.apache.org; href=mailto:general-unsubscr...@incubator.apache.org;general-unsubscr...@incubator.apache.org For additional commands, e-mail: ymailto=mailto:general-h...@incubator.apache.org; href=mailto:general-h...@incubator.apache.org;general-h...@incubator.apache.org - To unsubscribe, e-mail: ymailto=mailto:general-unsubscr...@incubator.apache.org; href=mailto:general-unsubscr...@incubator.apache.org;general-unsubscr...@incubator.apache.org For additional commands, e-mail: ymailto=mailto:general-h...@incubator.apache.org; href=mailto:general-h...@incubator.apache.org;general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] XWork
(This has been a long time in coming, since the process was largely completed a few months ago.) The Apache Struts project has received a contribution of the XWork framework from OpenSymphony. The IP Clearance process has been followed, and the completed documentation is available for review here: http://incubator.apache.org/ip-clearance/struts2-xwork.html Lazy consensus concludes sign-off in 72 hours. -- Martin Cooper - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Latest incarnation of site update?
What is the current mechanism for getting the live web site to update after committing the changes? There was some discussion of svnpubsub a while ago, so at first I thought it might be magic, but nothing happened. I waited an hour for an automatic update, but no luck. I logged in to people@ and 'svn up'ed - nothing. Still nothing after another hour. I even looked for instructions, but didn't find them beyond what's in the README, which stops at committing the changes. Now I'm stumped. -- Martin Cooper - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Switching incubator.apache.org to svnpubsub?
On Wed, Feb 3, 2010 at 8:56 AM, Justin Erenkrantz jus...@erenkrantz.com wrote: On Wed, Feb 3, 2010 at 7:41 AM, Martin Cooper mart...@apache.org wrote: Unless I'm missing something, using svnpubsub will only remove the need for the second part (checkout on p.a.o), but not the first part (Anakia). People will still need to run Anakia to generate the HTML pages from the XML sources, but when they check in the HTML, it will go live immediately instead of being delayed. Right? Yup - you've got it. -- justin In that case, +0 from me. We gain the elimination of the p.a.o bit but lose the benefit of the delay, so it's basically a wash, as far as I'm concerned. -- Martin Cooper - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Switching incubator.apache.org to svnpubsub?
On Wed, Feb 3, 2010 at 6:51 AM, Upayavira u...@odoko.co.uk wrote: On Tue, 2010-02-02 at 22:57 -0800, Justin Erenkrantz wrote: Hi general@, I'd like to suggest switching incubator.apache.org over to svnpubsub. (We can do so by filing a JIRA like INFRA-2349: http://issues.apache.org/jira/browse/INFRA-2349) This would mean that any commits made to the site-publish tree would automatically be deployed to the site. No more delays, no more SSH and SVN up fun. Yay. This does mean you trade off the fact that you can't delay anything - but, in general, I think that's fine for the incubator site and would substantially lower the barrier of entry to folks working on the Incubator site. Often times, people's first experience with the ASF is through the podlings, so I think it would be nice if we could make it a bit easier to publish the incubator.a.o site. What do folks think? -- justin P.S. On IRC, Paul mentions there may be some complications with respect to podling sites as sub-directories, but he promises that it is feasible to address. *grin* While I'd like to see a decent CMS set up, pubsub is here now, and much better than what we currently have. Also, as has been said, few podlings will opt for the current Anakia/checkout on p.a.o approach, so there's little argument that making them use it for the incubator site is 'educational'. Unless I'm missing something, using svnpubsub will only remove the need for the second part (checkout on p.a.o), but not the first part (Anakia). People will still need to run Anakia to generate the HTML pages from the XML sources, but when they check in the HTML, it will go live immediately instead of being delayed. Right? -- Martin Cooper So, here's my +1. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
+1 -- Martin Cooper On Wed, Nov 4, 2009 at 12:12 PM, Greg Stein gst...@gmail.com wrote: Subversion is a version control system. You probably know it well as it is the version control system employed by the Apache Software Foundation. The Subversion project would like to join the Apache Software Foundation to remove the overhead of having to run its own corporation. The Subversion project is already run quite like an Apache project, and already counts a number of ASF Members amongst its committers. Work on Subversion was originally started at CollabNet; Karl Fogel was hired in January 2000. Jim Blandy, at RedHat, already had an initial design for the storage system, which was incorporated into the FS design. In February Brian Behlendorf invited Greg Stein to contribute his WebDAV experience to Subversion. Ben Colins-Sussman was hired in April 2000 to work on the project. In that same month the first all hands meeting was held, where a number of interested people came together to talk about the project. Subversion was run as an open source project since the early days. Now, more than nine years later, it retains a healthy community, and has a good number of committers. In the life span of Subversion, several committers have switched employers and have maintained involvement. The committership is diverse, both geographically as well as in terms of employment. The equivalent of the PMC consists of all the full committers to the Subversion project (currently around 55 people). The community uses the voting process also used at the ASF. Releases are signed off by gathering votes/digital signatures of each committer who verified the release candidate. We feel the ASF and Subversion communities are very compatible, witness the cross interest that already exists. There is both a vibrant developer as well as a large and active user community. Technology-wise, Subversion builds on APR, and implements two Apache HTTP Server modules. Note that Subversion has a number of related projects, which are not part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse). More information on Subversion can be found at http://www.subversion.org/ and http://subversion.tigris.org/. The Subversion Corporation has a license to all source code, and has CLAs on file for nearly all it's committers. That is, we have all but one or two full committers, and some percentage of partial committers. We have a number of *user-configurable* dependencies which are not compatible with the AL: - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL. (An alternative HTTP client library, libsvn_ra_serf uses the Serf library under ALv2.) - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is under Academic Free License 2.1 or =GPL-2. (This support is for integration for KDE and GNOME's authentication providers.) - libintl (This library provides translation support for systems without a proper internationalization library.) - BDB (This is used by the libsvn_fs_base system which stores its data in BDB; an alternative repository system called fs_fs does not have this dependency.) --- Required Resources - Mailing lists - dev - issues - users - private - commits - announce - breakage (see http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552) - We will work with the Infrastructure team to transfer the subscriber listings to the new destinations. - Subversion: - We have not made a decision whether we prefer Subversion should be imported into the main ASF Subversion repository or be hosted as a separate repository to enable early testing of the repository code. We intend to discuss this during the Incubation process before the code is imported. It is also understood that ASF infrastructure team may be willing to run custom pre-release Subversion server builds for the entire ASF, so this separate repository option may not be required. - The Subversion source code can be found at: http://svn.collab.net/repos/svn/. - Issue tracking - We haven't made a decision between JIRA or Bugzilla at this time and expect this decision to be made as part of the Incubation process. Our current issue tracking system uses Issuezilla (a fork of Bugzilla) and we have not yet decided whether we want to import our previous issues into the new system and will decide this in the course of the Incubation process. - Our current issue tracker is at http://subversion.tigris.org/issue-tracker.html. - Buildbot - We currently use buildbot across a number of platforms and configurations for automated builds and testing. Over time, we would like to migrate these services to Apache infrastructure where appropriate. - Our current buildbot
Re: [PROPOSAL] Apache OpenMeetings incubator for Web Conferencing
2009/10/28 Alexei Fedotov alexei.fedo...@gmail.com: Hello Paul, Thanks for a good question! Openmeetings is red5 application which is very close to ordinary web application. AFAIU, the last change by Sebastian makes them even closer by implementing .war deployment. The code of the projects does not overlap in any way, and projects are connected via dynamic linking. AFAIK, dynamic linking of separate modules is permitted by LGPL. Digging this deeper, most dynamic linking is with a web server (i.e. Tomcat or Jetty) embedded into Red5, which is Apache licensed. To the best of my knowledge openmeetings communicate with a media server mostly using sockets, so some distribution re-packs may eliminate even dynamic linking. I don't believe you've answered what Paul was really asking, though. Is it not true that OpenMeetings requires Red5 in order to function properly? So that, if we cannot distribute Red5 as part of an ASF distro, because of the license, we also cannot distribute a functional OpenMeetings product? Or is there some alternative to Red5 that could be distributed instead? -- Martin Cooper On Wed, Oct 28, 2009 at 1:01 AM, Paul Querna p...@querna.org wrote: On Tue, Oct 27, 2009 at 4:22 AM, Sebastian Wagner seba.wag...@gmail.com wrote: hi, we would like to propose Openmeetings project to join the incubator. Full Proposal: http://wiki.apache.org/incubator/OpenmeetingsProposal Quick summary: OpenMeetings is Web Conferencing application that fits into educational or business sector. You can make conference sessions in different room-types with up to 100 peoples in a Room. It contains all main features of Web Conferencing: Audio/Video, Whiteboard, Screen Sharing, Chat and Moderation System. It is translated into more then 20 languages and its a basic goal of OpenMeetings to be easy to embed into existing environments. It already uses many of Apache Technologies like Tomcat, Mina, Velocity, Commons, ... You may find all existing documents and further material on the GoogleCode pages: http://code.google.com/p/openmeetings/ Sounds cool! I do have a question about how the project uses Red5 Media Server. Red5 is licensed under the LGPL, how exactly does OpenMeetings use it? Thanks, Paul - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- With best regards / с наилучшими пожеланиями, Alexei Fedotov / Алексей Федотов, http://www.telecom-express.ru/ http://harmony.apache.org/ http://www.expressaas.com/ http://openmeetings.googlecode.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Aries proposal for incubation
On Tue, Sep 22, 2009 at 5:56 AM, Kevan Miller kevan.mil...@gmail.com wrote: On Sep 22, 2009, at 12:09 AM, Niclas Hedhman wrote: On Tue, Sep 22, 2009 at 2:36 AM, Jeremy Hughes hugh...@apache.org wrote: If it IS a goal to become a large component registry for anything OSGI enterprisey then my -1 vote will stand. Really it isn't. I mentioned earlier in this thread that Aries will seek to use components from other projects where they exist. I rest my case. Your argument is that the text is sufficient, I mean it is not (too inclusive). Let's adjourn this for the graduation. I am urging that the community along the way think long and hard on the formulation of project mission. Thanks Niclas. I certainly will be expecting (and prodding) the community to work at addressing your (and any other IPMC member's) concern. This vote has been open for a week, now. There's a lot of interest and support for the project. Concerns about the scope of the project have been raised. Addressing these concerns should be an important objective for the community. I think it's time to call this vote. Jeremy, since you initiated the VOTE, best for you to do the honors... I'd be interested in what people thought they voted for. The list of participants seems to have been constantly changing throughout the vote, but we can only be voting on one proposal, so which one was it? Did people who voted early implicitly vote for people who were not on the list at the time they voted? That doesn't sound right to me. -- Martin Cooper --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release PhotArk M1-incubating (RC4a)
I voted on the dev@ list already, but here's my +1 as an IPMC member as well. -- Martin Cooper On Sun, Sep 13, 2009 at 10:06 AM, Luciano Resende luckbr1...@gmail.com wrote: The PhotArk community has completed a vote on it's first milestone release (PhotArk M1-Incubating) and is now looking for IPMC approval to publish the release. Please review and vote on approving the M1-incubating release artifacts of PhotArk. The artifacts are available for review at: http://people.apache.org/~lresende/photark/M1-incubating-RC4a/ This includes the signed binary and source distributions, the RAT report, and the Maven staging repository. The release tag is available at : https://svn.apache.org/repos/asf/incubator/photark/tags/M1-incubating-RC4a/ The vote thread from PhotArk dev list: http://www.mail-archive.com/photark-...@incubator.apache.org/msg00150.html Previous release candidate review in general list http://www.mail-archive.com/general@incubator.apache.org/msg21108.html -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
On Tue, Sep 1, 2009 at 10:51 AM, Richard S. Hallhe...@ungoverned.org wrote: I'm not sure I understand the issue here. Whether Aries becomes its own TLP, or a sub-project of Felix or some other TLP, isn't relevant until the project is ready to exit incubation. Why does it warrant such apparently intense discussion before the project is even accepted into incubation? -- Martin Cooper As I said on d...@felix and will repeat here: I don't agree about renaming the [Felix] TLP. There are so many examples of similar situations. I cannot believe we are truly in a unique situation here: * Apache typically means the HTTP Server project, but it also refers to the foundation and all of its independent projects. * Eclipse typically means the IDE, but there is also a runtime and foundation with independent projects. Acting like this isn't normal or something that is too confusing to ever resolve seems a bit preposterous. While I don't believe the situation is as confusing as is contended, I have no issue with coming up with a different name for the Apache Felix Framework (its name is technically Framework right now), so that the Apache Felix project can continue to pursue its original charter. - richard On 9/1/09 12:58, Niclas Hedhman wrote: I'm not subscribing to d...@felix.a.o at the moment, but would still like to hear the outcome of this... Richard, we (you and I at least) have discussed this more than once in the past and I totally agree with Guillaume that the perception is there, it is everything and near impossible to change. I ALSO agree with Richard that spec implementations should reside with Felix. Now, I think name manipulations are going to be necessary. My take is; Apache Felix = a OSGi framework, runtime, installers, binaries, bells and whistles. The whole kitchen sink if you like. The framework implementation itself probably lives here, with the Core spec service implementations. Apache Foo = a foundry to dev OSGi spec implementations. One or many. Most will be dependencies to Felix, but the detach shows that they are intended for all. Apache Bar = a component foundry outside the spec suite. And let Aries, Karaf, Ace and what else in future to go TLP if/when they are ready. I think ServiceMix has with its friends shown how nice eco-systems can work, and with OSGi's modularity strengths it should be even more so... In fact, instead of seeing this as a weakening of Felix position (which is what I think Richard sees), I think it will strengthen OSGi's natural place in the Apache Landscape. Don't forget, you are free to participate at as many places as you wish. -- Niclas P.S. Sorry for poor quoting. On mobile... On Sep 2, 2009 12:14 AM, Guillaume Nodetgno...@gmail.com wrote: On Tue, Sep 1, 2009 at 18:06, Richard S. Hallhe...@ungoverned.org wrote: Creating another pr... Well, the problem I see here is that we *need* to educate non-techies. This obvisouly mean that there is a confusion. Education is just a work around the need to remove the confusion imho. So let's discuss that on d...@felix.a.o, I don't think this thread belongs here. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ --... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: XAP?
On Mon, Aug 10, 2009 at 8:07 AM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, So who's going to do what about XAP? I tried understanding the related threads, but I couldn't figure out why it's so complicated. AFAIK, the only complication is an outstanding trademark issue. It's not clear to me how that should be addressed when the podling is about to be retired, but since the retired podling will still be using the XAP name, I'd assume that we cannot just ignore it. -- Martin Cooper If it were up to me, I'd simply follow [1]. In fact, unless someone takes some action on XAP by the end of this month, I'll do just that based on the already passed suspension vote. [1] http://wiki.apache.org/incubator/RetiringPodlings BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: photark project (was: Re: Stepping down as mentor for PhotArk)
On Sat, Aug 1, 2009 at 4:35 PM, Angela Cymbalak a.cymba...@nechtan.orgwrote: I've been spending more than my fair share of time on Facebook lately. Are we allowed to set up a Facebook page for the project? Just not sure since we are in incubation? What about a Twitter feed? Can we do those without breaking any of the incubation rules? I can do them if I know what my guidelines are... What would be the benefit of a Facebook page? I can see a Twitter feed might be useful assuming there's some project activity to twitter about, but I'm not sure I see a purpose to a Facebook page. I'm certainly open to hearing about how it might help, though. -- Martin Cooper Thanks, Angie At 03:05 AM 7/29/2009, Luciano Resende wrote: On Tue, Jul 28, 2009 at 4:07 PM, Angela Cymbalaka.cymba...@nechtan.org wrote: Carsten - Sorry to see you go. Same feeling here Carsten... and Thanks for all the help so far All - I have been thinking a lot about the project and part of my problem is being unsure of what documentation needs to be included in the project so we can get a release out. Luciano has done a fabulous job so far and I would hate to see the project go any more dormant than it has. Are there any suggestions on how we can get the project back on track? Good to hear from you Angela I believe we are almost there with the release, and I'll try to get a release candidate in the next week or so (after I get freed up from work related tasks)... Once the release is out, we should try to advertise the project together with it's first release trough blogs, facebook, twitter, etc and a quick getting started article..., and also spend some time working on growing the community.. -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: photark project (was: Re: Stepping down as mentor for PhotArk)
On Mon, Aug 3, 2009 at 11:28 AM, Luciano Resende luckbr1...@gmail.comwrote: On Mon, Aug 3, 2009 at 10:09 AM, Martin Coopermart...@apache.org wrote: On Sat, Aug 1, 2009 at 4:35 PM, Angela Cymbalak a.cymba...@nechtan.org wrote: I've been spending more than my fair share of time on Facebook lately. Are we allowed to set up a Facebook page for the project? Just not sure since we are in incubation? What about a Twitter feed? Can we do those without breaking any of the incubation rules? I can do them if I know what my guidelines are... What would be the benefit of a Facebook page? I can see a Twitter feed might be useful assuming there's some project activity to twitter about, but I'm not sure I see a purpose to a Facebook page. I'm certainly open to hearing about how it might help, though. The idea would be to use the Facebook page to share some project announcements, such as releases, participation on conferences, etc I believe this is the same idea we are using for the main The Apache Software Foundation page in Facebook. That Facebook page hasn't seen a wall post for five months, or a discussion since 2007... OK, so let's say we set up a Facebook page for PhotArk. Maybe we announce it by writing on the ASF page's wall. Don't people have to become a fan of the page to see updates to it without proactively going to the page? That's the part I don't get - how does this help us reach out? Surely people who don't already know about it are only going to hear about it if, for example, you or I say something about it in our 'status'. (I'm talking about Facebook here.) But we don't need a Facebook page before we can say something in our 'status'. So how does the page help? I'm sure I must be missing something here. ;-( -- Martin Cooper This would really be another channel to reach for people while we still don' t have enough traffic on the PhotArk website. http://www.facebook.com/home.php#/group.php?gid=2399716752ref=ts -- Luciano Resende Apache Tuscany, Apache PhotArk http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Wookie - a W3C widget engine with Google Wave extension
+1 -- Martin Cooper On Tue, Jul 14, 2009 at 3:15 AM, Ross Gardler rgard...@apache.org wrote: I would like to formally present the incubator proposal for Apache Wookie, a W3C widget engine with Google Wave extension The full proposal can be found at http://wiki.apache.org/incubator/WookieProposal Vote will close in a little over 72 hours at mid day (BST, UTC + 1) Friday 17th July. http://www.timeanddate.com/worldclock/fixedtime.html?month=7day=17year=2009hour=12min=0sec=0p1=136 Ross -- Ross Gardler OSS Watch - supporting open source in education and research http://www.oss-watch.ac.uk - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Chemistry
On Mon, Apr 20, 2009 at 3:48 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Tue, Apr 21, 2009 at 12:33 AM, Ross Gardler rgard...@apache.org wrote: No comments on the proposal, but I do have a comment on the name. Coming from the academic sector my heart soared when I saw this name. I thought there was a proposal that would be of interest to my target domain. Obviously it doesn't have anything to do with Chemistry. I'm not objecting to the name (I actually quite like it given what the proposal is), but I do think it might cause some confusion. For additional background on the name, we went through a few iterations already on the Jackrabbit dev@ list: 1) Apache CMIS (the name is already used for the standard) CMIS is a trademark of OASIS, though: [...] the names and common abbreviations of OASIS specifications are trademarks of the consortium. They should be used only to refer to the organization and its official outputs. http://www.oasis-open.org/who/trademark.php -- Martin Cooper 2) Apache CloudMist (mist has a negative meaning in German) 3) Apache Camaïeu (hard to pronounce and spell for many of us) 4) Apache Chemistry So far everyone has liked the last name, though your point about potential confusion is valid. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Ace
On Thu, Apr 2, 2009 at 12:52 PM, Marcel Offermans marcel.offerm...@luminis.nl wrote: Hello all, I would like to formally present the incubator proposal for Apache Ace, a software distribution framework based on OSGi that allows you to manage and distribute artifacts, like e.g. software components. The full proposal can be found on the wiki at: http://wiki.apache.org/incubator/AceProposal I'm looking forward to all questions and feedback, positive or negative. Could you comment on how this compares to Equinox p2? It'd be interesting to understand the similarities and differences. -- Martin Cooper Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Suspending Projects -- XAP
On Mon, Feb 16, 2009 at 11:23 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On 2/16/09, Noel J. Bergman n...@devtech.com wrote: In August 2008, it was discussed that XAP had been inactive for at least 4 months. In November 2008, we again saw issues with XAP and discussed suspension. Having reached, now, February 2009, and still nothing with XAP, I am raising this as a vote. -1 Suspension implies wrongdoing and fault, and that this disciplinary process is temporary IMO XAP should be archived into an Attic Oversight on inactive projects does not worry me. The lack of activity makes this a very easy task. An issue related to XAP was raised last September and the PPMC was asked to address it. AFAIK, the PPMC has done nothing at all since then to address that particular issue. -- Martin Cooper Oversight problems in the incubator are more likely to occur when a project is too active for energy available from the mentors. Robert --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Suspending Projects -- XAP
+1. I see little chance of XAP being resurrected at this point. -- Martin Cooper On Mon, Feb 16, 2009 at 10:56 AM, Noel J. Bergman n...@devtech.com wrote: In August 2008, it was discussed that XAP had been inactive for at least 4 months. In November 2008, we again saw issues with XAP and discussed suspension. Having reached, now, February 2009, and still nothing with XAP, I am raising this as a vote. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the 2.0.1 release of Apache Click
On Wed, Feb 4, 2009 at 10:06 AM, Kevan Miller kevan.mil...@gmail.comwrote: On Feb 4, 2009, at 10:00 AM, Bob Schellink wrote: New snapshots are available and contains the incubation disclaimer. Thanks to Kevan for picking this up. The disclaimer can be found in the distribution root while for maven artifacts the disclaimer can be found under META-INF. New distribution is available here: http://people.apache.org/~sabob/click/click/2.0.1/dist/http://people.apache.org/%7Esabob/click/click/2.0.1/dist/ New Maven artifacts are here: http://people.apache.org/~sabob/click/click/2.0.1/maven2/http://people.apache.org/%7Esabob/click/click/2.0.1/maven2/ +1 In the future, would be helpful to include the svn url of the code being voted on... AFAIK, you're voting on the bits in the distro, not the source code. -- Martin Cooper --kevan
Re: [PROPOSAL] ESME - The Enterprise Social Messaging Experiment
Sounds very interesting. I'd especially like to see this mix of languages and clients at the ASF. -- Martin Cooper On Mon, Nov 3, 2008 at 3:22 PM, Darren Hague [EMAIL PROTECTED] wrote: I would like to propose ESME as a project for the Apache Incubator. Enterprise Social Messaging Experiment (ESME) is a secure and highly scalable microsharing and micromessaging platform that allows people to discover and meet one another and get controlled access to other sources of information, all in a business process context. ESME is written in Scala and uses the Lift web framework. Please see http://wiki.apache.org/incubator/ESMEProposal for details. Since this is my first Apache project, any and all feedback is welcome - I will call for a vote a few days after relevant messages on the list reduce to a trickle and people seem happy with the proposal. Best regards, Darren Hague - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [IP Clearance] Velocity-Tiles integration - Software grant acknowledgment
A grant named velocity tiles 2 plugin for spring myc was recorded on October 15th. (I assume myc should actually be MVC.) There's no other information than that in the grants file, and I'm not sure where the actual faxes are stored. Not sure if that's enough information for you. -- Martin Cooper On Mon, Oct 27, 2008 at 8:02 AM, Antonio [EMAIL PROTECTED] wrote: Hi all, I'm again here to discuss about the Velocity-Tiles IP clearance, that has been committed by Greg Reddin: http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/velocity-tiles.xml Now I wish to know if the software grant sent by Sergey Zolotaryov about this plugin has been received. It has been sent both on 21st and 24th October 2008 via e-mail to secretary@ and legal-archive@ The package that has been donated is here: https://issues.apache.org/struts/browse/TILES-170 Thanks Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Checking trademarks
The status page template includes a bullet item that states, in part: check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product How do we go about this? The CSC web site wants me to call them to have an account set up, but surely we're not all setting up accounts for one-time use, are we? I just want to complete the check for the PhotArk podling. TIA. -- Martin Cooper
Re: site updated
Done. -- Martin Cooper On Thu, Sep 11, 2008 at 8:06 AM, Matt Benson [EMAIL PROTECTED] wrote: ...for IP clearance; could someone push the updated site out to p.a.o? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Web20Kit: A Web 2.0 technology evaluation kit
Yeah, an association with WebKit was my first assumption as well. My greater concern, though, is purporting to compare technologies using one application with a very specific purpose. Certain technologies may shine in one application scenario and suck in others, while other technologies may show quite the opposite characteristics. Picking one application with which to demonstrate and, especially, compare a set of technologies doesn't tell a particularly useful story unless you happen to be building just that type of application. Sadly, many people don't take that into account, so that a technology demonstration such as this may lead them in non-optimal directions. Incidentally, there also appear to be assumptions about the architecture. For example, it looks like the use of a database is assumed, whereas in certain applications, a content repository might be more appropriate. Similarly, the use of a server-side web framework versus directly calling web services. There are many, many more options to consider. -- Martin Cooper On Tue, Aug 26, 2008 at 7:13 PM, Brett Porter [EMAIL PROTECTED]wrote: Without too much thought into the rest of it just now, the first thing I thought was that this would have something to do with WebKit, which it doesn't and would probably be very confusing? - Brett 2008/8/27 Craig L Russell [EMAIL PROTECTED]: This is a proposal to incubate http://wiki.apache.org/incubator/Web20KitProposal We're looking for a couple more mentors. Web20Kit Abstract Web20Kit is a web 2.0 toolkit to help developers evaluate the suitability, functionality and performance of various web technologies by implementing a reasonably complex application in several different technologies. Proposal Web20Kit will develop an example application to understand the benefits, performance, and scalability of popular web technologies. Multiple implementations of the application are planned - each providing the same functionality but staying true to the philosophy of its base language/framework. Background Most web 2.0 sites today use open source languages and frameworks such as PHP, Ruby on Rails, and Java EE to develop their applications. Deployments of these applications also use popular open source servers such as Apache httpd, Tomcat, MySQL, Memcache, and Glassfish. Many other servers/technologies such as lighttpd, mogileFS, mongrels, JRuby are also gaining popularity. With the myriad technologies available, it is not easy to understand how they differ, especially in terms of performance and scalability. With varied levels of documentation available for some open source applications, it is also quite difficult for a web 2.0 startup to understand the correct usage of these technologies so that they don't become a bottleneck as their site grows. Rationale Web2.0kit is a toolkit that will attempt to address the above issues. What it does Web20Kit defines an example web 2.0 application (the initial implementation uses an events site somewhat like yahoo.com/upcoming) and provides three implementations: PHP, Java EE, and Ruby on Rails. The toolkit will also define ways to drive load against the application in order to measure performance. As developers join the project, they can implement the same application using their favorite web frameworks and compare their implementations to others. What you can learn from it a) Understand how to use various web 2.0 technologies such as AJAX, memcached, mogileFS etc. in the creation of your own application. Use the code in the application to understand the subtle complexities involved and how to get around issues with these technologies. b) Evaluate the differences in the implementations: PHP, Ruby on Rails, Java EE, and other contributed implementations to understand which might best work for your situation. c) Within each language implementation, evaluate different infrastructure technologies by changing the servers used (e.g: apache vs lighttpd, MySQL vs PostgreSQL, Ruby vs Jruby etc.) d) Drive load against the application to evaluate the performance and scalability of the chosen platform. e) Experiment with different algorithms (e.g. memcache locking, a different DB access API) by replacing portions of code in the application. A robust, community-developed standard implementations of a web 2.0 application using different technologies will enable developers to compare and contrast these technologies in a manner that does not exist today. By providing excellent sample implementations of a concrete application that is available to everyone, we will enable faster and easier application development for users. Although we list three implementations in this proposal, we encourage others to come up with many more using other language stacks and/or frameworks e.g. Spring framework, Python etc. Current
Re: [VOTE] Accept project PicaGalley into the Incubator
--8 [X] +1 Accept PicaGalley for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : It will be interesting to see how this comes together; I hope to see the crystallisation of both an idea and a community develop into a thriving project here at the ASF. -- Martin Cooper
Re: Multiple concerns reviewing BlueSky podling website
On Thu, Jul 31, 2008 at 1:26 PM, Andrus Adamchik [EMAIL PROTECTED]wrote: On Jul 31, 2008, at 4:18 PM, Luciano Resende wrote: - The BlueSky podling website have a download page, that is pointing to non-apache bluesky released artifacts. I think this is at least very confusing, as it can allude users to think this is a endorsed ASF release. Is this OK ? I don't see a problem with links to pre-ASF releases. BlueSky is not unique in this respect. There are a number of Apache projects with long pre-ASF history. So including links to such releases is totally appropriate. However a clear indication on the page that those are the releases made outside Apache is a good idea. Not only is that not being done, but if you follow the link to, for example, Learn more about XPlayer, you will land on an ASF page all about XPlayer that has a License link that displays the Apache License 2.0, whereas XPlayer is, as I understand it, GPL licensed. That seems like a pretty serious no-no to me. -- Martin Cooper Andrus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: photo gallery software (previously called Caitrin)
I'm a little confused, because the wiki says that the proposal is being put on hold and that the goal is to work with the Roller community. http://wiki.apache.org/incubator/CaitrinProposal Nevertheless, if there's interest in building a Flex front end, let me know... -- Martin Cooper On Tue, Jun 24, 2008 at 11:09 AM, Angela Cymbalak [EMAIL PROTECTED] wrote: Hi All, I haven't forgotten about wanting to create an open source Photo Gallery and there has been some sporadic interest as I have discussed it. A quick update as to where we are at for anyone who is interested. 1. Name change No one but me knows where the name Caitrin came from and it isn't obvious what the software would do. A proposed solution (thanks Noel for the path suggestion) would be PhosLibrarius 2. Code Bases There are 2 code bases that we can draw from and discard that I have heard of. Always a good start 3. Design Right now thought is being put into the high level design to improve the Proposal. The current proposal is bad. I take credit for that because I haven't done the Apache thing before and I am tripping all over while trying to stay on the right path. The current thought is to defiantly write the application in Java. Its secure, it scales well, we like it. The thought is to look into Sling and the JCR as well as different databases. I have to do reading on Sling to figure out how it all fits together. Pretty much, we are focusing on the back end first with the possibility of a Web service for the front end to start. This lets anyone out there write nice pretty display pieces. I like AJAX as a front end but others who I have talked to don't. We can agree on the Web service for right now. If anyone has anything that they would like to contribute or if you have comments/suggestions about this proposal please let me know. The interest seems to be lurking out there, we just need to get it organized. Thanks, Angie -- Angela Cymbalak Nechtan Design http://www.nechtandesign.com/ 412.931.4663 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Confluence Based Website Access Control
On Mon, Mar 24, 2008 at 2:50 PM, Craig L Russell [EMAIL PROTECTED] wrote: IIRC, write access to wiki pages, distinct from write access to an svn repository, is not currently covered in the Incubator policy or guides. The policy on wikis is ASF-wide. I don't believe any separate Incubator policy is required. Basically, it comes down to this: Q: Is the wiki going to be used for generating a web site? A: Yes -- A CLA must be on file for each person who has write access to the wiki space. No -- There are no restrictions on who can register and edit pages in that space. http://cwiki.apache.org/CWIKI/ -- Martin Cooper If nothing happens in the interim, I propose discussing this corner case at the Incubator Hackathon in ApacheCon EU Amsterdam in a couple of weeks. Craig On Mar 24, 2008, at 2:45 PM, Noel J. Bergman wrote: Luciano Resende wrote: Based on previous discussion [1], the Tuscany PPMC has voted to grant some some community members, with proper CLA on file, to have write access to the Confluence wiki website. Is this NOT acceptable anymore? PMC must vote, so let's be clear on this: minimum of 3 binding votes, like everything else. But with the vote AND the CLA, they *are* Committers. You just don't have them committing code. This is not new; there are non-coders who are HTTP Server Project Committers. They commit docs. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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!
Re: [VOTE] Approve Apache XAP 0.5.0 Release
On Thu, Mar 13, 2008 at 4:01 PM, sebb [EMAIL PROTECTED] wrote: snip/ There seem to be several copies of some files, e.g. dojo.js.uncompressed.js custom_rhino.jar flash6_gateway.fla Hmm, custom_rhino.jar is an interesting one. Prior to version 1.6R5, I believe Rhino was MPL licensed, and as of 1.6R5 it is dual licensed under MPL and GPL. It is coming to XAP through Dojo. Do we know which version of Rhino this is? If it's 1.6R5 or later, how does a dual MPL / GPL license work in an ASF project? Does the ASF have to pick one of the licenses, and are we allowed to do that? Can we distribute something that's potentially GPL licensed? -- Martin Cooper
Re: Projects in trouble or otherwise needing help
(I just rediscovered this thread as part of a year-end mail cleanup...) On Nov 14, 2007 4:32 PM, James Margaris [EMAIL PROTECTED] wrote: I am one of the pimary committers on XAP. As far as the board report, I just plain missed it until it was too late. As far as the community building is concerned, yes the lists are basically dead. However work does continue on the project, for better or worse. This is the part that both baffles me and concerns me. How is it that a group of developers can continue to work on a project without any discussion on what they're working on? The only way I could see that happening is if the project is effectively done and people are just fixing the odd bug that gets submitted, but my impression, at least, is that XAP is not a project that is close to being done. Perhaps I'm wrong about this. So where is the discussion on what happens next? The roadmap, on the web site, stops at a year ago, and XAP 0.3.0 was released early in 2007. Is there a plan to get from 0.3.0 to, say, a 1.0 release? Where can I read about that? One question that I would ask the XAP folks who work for Nexaweb (which is a majority of them, I believe): Is there any discussion at all within Nexaweb about XAP, its status, its future, and its development? Frankly, this has always seemed to me the most likely reason for the lack of discussion on the lists - the discussions are happening, but happening in person between people who work for the same company. Part of the reason I stopped using the lists is that substantive responses were rare. The only thing I ever got comments on were things like naming and copyright notices. Of course that is a chicken and egg problem to some degree, there is no community so nobody uses the lists to discuss so there is no community. It would help me if someone could help me understand how to make XAP more appealing and interesting to the Apache community. Is the problem that there are no good samples and demos? The website isn't good? Nobody understands what the point is? I like discussing technical issues with people but I don't like posting technical thoughts only to be met consistently by silence. At that point it becomes busywork, just going through the motions for the sake of appearances. Let's flip that around. If you were looking at a project with a view to getting involved in it, how likely would you be to post your thoughts and ideas if not even the people already involved are discussing anything in the open? I understand that it can be hard to bootstrap the discussion. But without a track record of discussion on the lists, there's little reason for anyone not already involved to even subscribe to those lists. People need to see that *something* is happening on the project. The threads don't all need to be deep technical discussions. For example, where's the thread on what should go into the 0.4.0 release? How should the 1.0 release be defined? Is everything - architecture, design, dev process, testing, documentation - so well nailed down for this project that the people involved don't need to talk about it? I've been involved with Struts, for example, for 7 years, and we *still* have discussions about all of those! -- Martin Cooper The XAP project is not like projects like Kabuki that never did any development and never responded on the lists. There is active development and if someone ever posted to the lists I'm sure someone would respond. Right now posting on the lists feels like playing to an empty theater. James Margaris From: Robert Burrell Donkin [mailto:[EMAIL PROTECTED] Sent: Wed 11/14/2007 2:42 PM To: general@incubator.apache.org Subject: Re: Projects in trouble or otherwise needing help (forgive the rambling reply) On Nov 12, 2007 4:47 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: XAP - mailing lists show almost no discussion, mostly JIRA issues and commits XAP is an interesting case. in some ways, i think that XAP has always been short of just one independent developer showing up to scratch an itch. there was no end of endeavour in the early days from the team to try to fit in. the atmosphere has always been open, polite and encouraging to outsiders but the volumes of people turning up on list have just too far too low. i've tried to figure out some rational explanation for this but i don't have one. at apachecon EU, rob gave a very well attended session on XAP and many people had questions. but no one really showed up on list to follow up afterwards. not sure why. martin tried hard for quite a while to encourage the team to talk a lot more on the list without long term success. it's tough, though. i find it hard to explain why talking is vital for community building. most of the time, no one is listening but sometimes, just sometimes a few words flung out into the ether will connect with someone. one connection with someone who goes onto become a long
Re: [PROPOSAL] Shindig, an OpenSocial Container
+1 for the name alone ;-) but it sounds like an interesting project to boot. -- Martin Cooper On Nov 9, 2007 10:03 AM, Brian McCallister [EMAIL PROTECTED] wrote: Shindig Proposal -- = Abstract = Shindig will develop the container and backend server components for hosting OpenSocial applications. = Proposal = Shindig will develop a JavaScript container and implementations of the backend APIs and proxy required for hosting OpenSocial applications. = Background = OpenSocial provides a common set of APIs for social applications across multiple websites. With standard JavaScript and HTML, developers can create social applications that use a social network's friends and update feeds. A social application, in this context, is an application run by a third party provider and embedded in a web page, or web application, which consumes services provided by the container and by the application host. This is very similar to Portal/Portlet technology, but is based on client-side compositing, rather than server. More information can be found about OpenSocial at http://code.google.com/apis/opensocial/ == Rationale == Shindig is an implementation of an emerging set of APIs for client-side composited web applications. The Apache Software Foundation has proven to have developed a strong system and set of mores for building community-centric, open standards based systems with a wide variety of participants. A robust, community-developed implementation of these APIs will encourage compatibility between service providers, ensure an excellent implementation is available to everyone, and enable faster and easier application development for users. The Apache Software Foundation has proven it is the best place for this type of open development. = Current Status = This is a new project. = Meritocracy = The initial developers are very familiar with meritocratic open source development, both at Apache and elsewhere. Apache was chosen specifically because the initial developers want to encourage this style of development for the project. === Community === Shindig seeks to develop developer and user communities during incubation. = Core Developers = The initial core developers are all Ning employees. We hope to expand this very quickly. = Alignment = The developers of Shindig want to work with the Apache Software Foundation specifically because Apache has proven to provide a strong foundation and set of practices for developing standards-based infrastructure and server components. = Known Risks = == Orphaned products == Shindig is new development of an emerging set of APIs. == Inexperience with Open Source == The initial developers include long-time open source developers, including Apache Members. == Homogenous Developers == The initial group of developers is quite homogenous. Remedying this is a large part of why we want to bring the project to Apache. == Reliance on Salaried Developers == The initial group of developers are employed by a potential consumer of the project. Remedying this is a large part of why we want to bring the project to Apache. == Relationships with Other Apache Products == None in particular, except that Apache HTTPD is the best place to run PHP, which the server-side components Ning intends to donate have been implemented in. == A Excessive Fascination with the Apache Brand == We believe in the processes, systems, and framework Apache has put in place. The brand is nice, but is not why we wish to come to Apache. = Documentation = Google's OpenSocial Documentation: http://code.google.com/apis/opensocial/ Ning's OpenSocial Documentation: http://tinyurl.com/3y5ckx = Initial Source = Ning, Inc. intends to donate code based on their implementation of OpenSocial. The backend systems will be replaced with more generic equivalents in order to not bind the implementation to specifics of the Ning platform. This code will be extracted from Ning's internal development, and has not been expanded on past the extraction. It will be provided primarily as a starting place for a much more robust, community- developed implementation. = External Dependencies = The initial codebase relies on a library created by Google, Inc., and licensed under the Apache Software License, Version 2.0. = Required Resources = Developer and user mailing lists A subversion repository A JIRA issue tracker = Initial Committers = Thomas Baker[EMAIL PROTECTED] Tim Williamson [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Thomas Dudziak [EMAIL PROTECTED] Martin Traverso [EMAIL PROTECTED] = Sponsors = == Champion == Brian McCallister [EMAIL PROTECTED] == Nominated Mentors == Brian McCallister [EMAIL PROTECTED] Thomas Dudziak [EMAIL PROTECTED] Santiago Gala [EMAIL PROTECTED] Upayavira
Re: [PROPOSAL] JSPWiki
On 9/6/07, Janne Jalkanen [EMAIL PROTECTED] wrote: What do you mean? Apache does not have needed lower level projects to run JSPWiki? How about Tomcat+Harmony? Well, let me put it this way: it would be kinda dumb to run our public wiki site on another wiki engine. ;-) Dumb? So we must already be dumb, then, to be running other things like JVMs that don't come from the ASF, rather than our own. Is there a roadmap for when JSPWiki will have all of the features and functionality of both Confluence and MoinMoin, including the Confluence macros we use, and the migration tools so that we can move all the existing data from these existing wikis to JSPWiki? Without that, I don't see us replacing our existing wikis with JSPWiki, and I'm absolutely not in favour of adding a third wiki flavour to our infrastructure. Is this the real reason JSPWiki wants to come to the ASF? To be the wiki that the ASF runs on? We also have separate documentation and sandbox wikis. http://www.jspwiki.org/wiki/ApacheJSPWikiProposal#section- ApacheJSPWikiProposal-RequiredResources It's not at all clear from that list that those are wikis and not just regular web sites. Does JSPWiki have an auto-export capability, like Confluence does, so that pages can be offloaded to static resources, instead of hitting the wiki all the time? A tomcat instance is fine (preferably non-shared; JSPWiki cannot be deployed simply from a war file right now), and I can offer to run some of the wiki sites (e.g. the sandbox, which is wiped out regularly) myself. You'll need a dedicated team of people, not just one person, that is committed to doing this on an ongoing basis. -- Martin Cooper /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] JSPWiki
I'm concerned about all of the 3rd party dependencies that use quite a variety of other licenses. The relicensing page says Category B: Keep for many of these. I'm not clear on where the Category B part comes from, but I don't believe that some of these can be kept. Some of the licenses, such as CPL, have IP provisions in them that are most likely incompatible with the Apache License 2.0, so I believe those components would have to go as well. Am with most folks here, IANAL, but this is something that would have to be looked at closely to make sure that JSPWiki can in fact end up under an Apache License. -- Martin Cooper On 8/29/07, Janne Jalkanen [EMAIL PROTECTED] wrote: Hello all! I am Janne Jalkanen, the lead developer of the open source wiki engine called JSPWiki, and I have a proposal for your enjoyment. This proposal is available in the web at http://www.jspwiki.org/wiki/ ApacheJSPWikiProposal, should you wish to help us to make it better. /Janne - Abstract Apache JSPWiki will be a modular and user-extensible wiki-engine, based on the open source JSPWiki software. Proposal JSPWiki is a wiki engine available under the Lesser General Public License. It has a very modular construction, and integrates relatively nicely with a bunch of enterprise systems. It is also inherently embeddable, and has been incorporated as a component in a few different commercial and open source products. The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable backends, pluggable editors, an expressive markup, a plugin framework, a filter framework, and built-in URL rewriting. JSPWiki also has a nice unit test set of over 700 unit tests which have been invaluable in keeping compatibility between releases. Background In the past few years, wikis have become a common collaborative tool. They are light-weight, open, and easy to deploy. The English Wikipedia, currently the largest public wiki site, contains nearly two million pages. Wikis were originally designed to be small group collaboration tools, but they have proven to be scalable to a large number of users, as evidenced by the Wikipedia example. However, their most common use is still within companies and other entities which deploy them as collaboration tools, augmenting and even replacing traditional CSCW tools. JSPWiki was originally created to address the same group collaboration tool needs as so many other wiki engines. Its goals were from the start to provide extensibility and user power, while keeping the core functionality clear. Since it's inception in 2001, it has grown to be one of the more popular open source wikiengines, at least in the Java arena. It currently ships with the Sun Portal Server 7, and features as an integral part of the Intland Codebeamer development environment. Rationale JSPWiki has grown nicely over the past few years, and currently averages around 2000 downloads monthly. The users-list has at the writing of this 207 members, and the developers mailing list has 34 members. There are currently six people with commit access to the CVS codebase. However, there is a chasm to how large an open source project can grow under a benevolent dictator –model. Many corporations are relying on the JSPWiki code base, and joining Apache would lessen the risks involved in using it, thus giving more entities an opportunity to use this advanced project. Joining Apache would make us less dependent on individual developers and would strengthen our community. We also feel that the introduction of Apache processes would increase the code quality, as well as bring more interested developers to this project. Apache is also lacking a wiki engine. It is currently using either commercial software (Confluence) or Python-based wiki software (MoinMoin) as its own projects. As wikis are becoming the workhorse of many projects, we feel that it would bring a good addition to the Apache community. Initial Goals The initial goals of the project is to release JSPWiki 2.8 under the Apache license: * Bring in the JSPWiki 2.6 stable code base into Apache and apply Apache licensing and remove incompatible dependencies (see ApacheRelicensing for more discussion.) * Release JSPWiki 2.8 as a clone of JSPWiki 2.6 - with some bug fixes and Apache licensing, however keeping compatibility with JSPWiki 2.6. This means that we cannot e.g. change the package naming from com.ecyrd.jspwiki or else all old plugins will fail. It is yet unclear whether this will be acceptable to ASF. After that, we will start working on JSPWiki 3.0: * Clean up our metadata and backend support by adding JSR-170 repository support * Adoption of a more flexible web framework (Stripes, an Apache- licensed project) * Multi-wiki support (so-called WikiFarms, or WikiWebs or WikiSpaces) * Move to org.apache.jspwiki -structure, breaking compatibility with 2.x series
Re: [PROPOSAL] JSPWiki
On 9/6/07, Gwyn Evans [EMAIL PROTECTED] wrote: While agreeing that it's something that needs looking at closely, I'm not I'm not sure it's downbeat as I think you're suggesting. The 3rd-party licencing policy at http://www.apache.org/legal/3party.html redirects to the draft at http://people.apache.org/~rubys/3party.html, but that suggests that, especially for use in binary form, licences such as CDDL or CPL aren't necessarily incompatible... Right. However, as you noted, that's a draft, so it may change. I hope it does. My concern is that as soon as we bundle components with other licenses into distributions of ASF projects, we compromise the integrity of the ASF itself in the eyes of the outside world. For one thing, not all consumers of those projects see the different licenses in the same light. For another, many many consumers of ASF projects assume that something coming out of the ASF will be licensed under the Apache License *only*. As a concrete example, look at Axis. At some point in its lifetime, WSDL4J was added to the distribution, and that's licensed under the CPL. Someone coming in and looking at Axis might reasonably assume that it's licensed under the Apache License, and not be aware that there's another license hiding in there. If that someone was a company (e.g. my employer) that forbids the use of CPL-licensed software, that can have very serious consequences, especially if the package was already in use before the dependency was introduced. -- Martin Cooper /Gwyn On Thursday, September 6, 2007, 3:49:09 PM, Martin [EMAIL PROTECTED] wrote: I'm concerned about all of the 3rd party dependencies that use quite a variety of other licenses. The relicensing page says Category B: Keep for many of these. I'm not clear on where the Category B part comes from, but I don't believe that some of these can be kept. Some of the licenses, such as CPL, have IP provisions in them that are most likely incompatible with the Apache License 2.0, so I believe those components would have to go as well. Am with most folks here, IANAL, but this is something that would have to be looked at closely to make sure that JSPWiki can in fact end up under an Apache License. -- Martin Cooper On 8/29/07, Janne Jalkanen [EMAIL PROTECTED] wrote: Hello all! I am Janne Jalkanen, the lead developer of the open source wiki engine called JSPWiki, and I have a proposal for your enjoyment. This proposal is available in the web at http://www.jspwiki.org/wiki/ ApacheJSPWikiProposal, should you wish to help us to make it better. /Janne - Abstract Apache JSPWiki will be a modular and user-extensible wiki-engine, based on the open source JSPWiki software. Proposal JSPWiki is a wiki engine available under the Lesser General Public License. It has a very modular construction, and integrates relatively nicely with a bunch of enterprise systems. It is also inherently embeddable, and has been incorporated as a component in a few different commercial and open source products. The latest JSPWiki, 2.6, supports AJAX and full I18N, pluggable backends, pluggable editors, an expressive markup, a plugin framework, a filter framework, and built-in URL rewriting. JSPWiki also has a nice unit test set of over 700 unit tests which have been invaluable in keeping compatibility between releases. Background In the past few years, wikis have become a common collaborative tool. They are light-weight, open, and easy to deploy. The English Wikipedia, currently the largest public wiki site, contains nearly two million pages. Wikis were originally designed to be small group collaboration tools, but they have proven to be scalable to a large number of users, as evidenced by the Wikipedia example. However, their most common use is still within companies and other entities which deploy them as collaboration tools, augmenting and even replacing traditional CSCW tools. JSPWiki was originally created to address the same group collaboration tool needs as so many other wiki engines. Its goals were from the start to provide extensibility and user power, while keeping the core functionality clear. Since it's inception in 2001, it has grown to be one of the more popular open source wikiengines, at least in the Java arena. It currently ships with the Sun Portal Server 7, and features as an integral part of the Intland Codebeamer development environment. Rationale JSPWiki has grown nicely over the past few years, and currently averages around 2000 downloads monthly. The users-list has at the writing of this 207 members, and the developers mailing list has 34 members. There are currently six people with commit access to the CVS codebase. However, there is a chasm to how large an open source project can grow under a benevolent dictator –model. Many corporations are relying on the JSPWiki
Re: All licenses in a single file [WAS: Re: [VOTE] Publish the Woden M7b release]
On 7/31/07, Matthieu Riou [EMAIL PROTECTED] wrote: On 7/31/07, ant elder [EMAIL PROTECTED] wrote: +1 from me. Some of the same comments on the previous M7a release still apply, eg, its preferred to have a separate DISCLAIMER file, having all licenses in a single LICENSE file, and have src and binary distro's unpack into different folders. Actually I was wondering about this recommendation of having all (non ASL) license files for dependencies in a *single* LICENSE file. It seems to me that it's a maintenance nightmare when you have a lot of dependencies (very long file, you have to do a search to find anything, checking what could be missing takes a looong time). I'd rather have all the specific licenses each in there file reproduced side by side with the library the license is applied on (with similar namings, i.e. dom4j-1.3.LICENSE) and a simple pointer in the main LICENSE file From: http://www.apache.org/dev/apply-license.html#new you should append their license(s) to the LICENSE file at the top of the distribution, or at least put a pointer in the LICENSE file to the third-party license The second part of this should meet your needs. Yes, you still have to have a pointer in the LICENSE file to each license, but you're not going to get out of that without a lengthy discussion with the ASF legal team, if then. (licenses for each dependency library are reproduced in the lib directory along with the library). That's not viable. As Niclas suggested, the target of all this is lawyers. They can't be expected to dig around in the distribution to find all the relevant licenses, and a clause such as you suggest gives no definitive means of determining whether or not all the relevant licenses have in fact been discovered. -- Martin Cooper So is there a legal justification behind this that I missed? And sorry if I'm rehashing a subject that has already been discussed in the past :) Matthieu ...ant On 7/30/07, Graham Turrell (gmail) [EMAIL PROTECTED] wrote: The Woden incubator project is developing a WSDL 2.0 processor in conjunction with efforts of the W3C to deliver the new WSDL 2.0 specification. The Woden project team would like to ask the Incubator PMC for approval to publish the Woden Milestone 7b release to support the upcoming Apache WS Axis2 1.3 release. Could Incubator PMC members please vote by Wednesday 1st August. Woden M7b is an incremental release of Woden M7 which was released on 19th February 2007. M7b adds to M7 and M7a fixes delivered by JIRAs: * WODEN-33 DocumentationElement should extend NestedElement. * WODEN-149 Update Woden with New WSDL 2.0 Assertions Numbers for Proposed Recommendation. * WODEN-161 Style default from interface not applied to operations. * WODEN-165 SAX attribution in NOTICE file is not required. * WODEN-168 OMXMLElementTest class incorrectly returning the DOMXMLElementTest class as its test suit. Also included is a fix to DOMWSDLReader to set base URI before calling XmlSchema. The Woden M7b release files are at: http://people.apache.org/~gturrell/woden/milestones/1.0M7b-incubating/ This build is based on revision 560591 at http://svn.apache.org/repos/asf/incubator/woden/branches/M7b/ The results of the vote from the woden-dev list was: Davanum Srinivas +1 (WSPMC, IPMC) Deepal Jayasinghe +1 Thilina Gunarath +1 Jeremy Hughes +1 (WSPMC) Graham Turrell +1 John Kaputin +1 -- Kind Regards, Graham
Re: [Vote] Accept JRS project for incubation
On 6/28/07, Phil Steitz [EMAIL PROTECTED] wrote: I have changed the proposal to indicate that initial source will not be made available until the software grant is executed. Other than that, the proposal is unchanged from the original submission. Full text is attached below. Votes, please. The vote will remain open for 72 hours, closing 2 July 0200 GMT. [ X ] +1 Accept this project into the incubator [ ] -1 No, because -- Martin Cooper Thanks! Phil
Re: housekeeping ( was Re: [Vote] Graduate Trinidad (to an Apache MyFaces subproject))
On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: same w/ kabuki, isn't that dead ? Withdrawn. -- Martin Cooper -M On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I noticed that Felix and Roller are still listed as podlings http://incubator.apache.org/projects/index.html I was under the impression, they graduated already. -Matthias On 4/19/07, Noel J. Bergman [EMAIL PROTECTED] wrote: I added a trinidad.xml and removed the adffaces one. the trinidad.xml lays out, that the name was changed. Another thing that you must do upon graduation is to finish the housekeeping here in the Incubator, e.g., move the project to graduated, finalize the status file, etc. Please don't leave it hanging. Best of luck, and congratulations. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Retired? Kabuki? Others?
On 3/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote: Didn't we retire this Kabuki? It was withdrawn by the original proposers. -- Martin Cooper It is still listed as active. I'll check the archives if no one beats me to it. Else we should formally retired it. And we should review, again, the roster (http://incubator.apache.org/projects/) to see if anything else should be moved to dormant status. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clarification on SF license and sandboxes
On 11/6/06, Henri Yandell [EMAIL PROTECTED] wrote: On 11/6/06, Mike Kienenberger [EMAIL PROTECTED] wrote: On 11/6/06, Henri Yandell [EMAIL PROTECTED] wrote: I'm still confused - why do we allow people to upload attachments that are not intended for inclusion? I can see one very reasonable reason from a user point of view - the example they want to upload is business related and so they want to do their best to explain the problem to us, but not to have us publish those details any further. However that reason doesn't hold up as it's public if it's in our JIRA and if we don't know the license on it, then can we even use it to resolve the issue? What makes an attachment special? Why don't we have to do this for comments and the jira issue itself? Not seeing why we don't just say: All issues + attachments are intended for inclusion. There's a difference between I don't want to contribute this code to the project code base versus I don't want my code published. The no option means the code is not for inclusion into the project. It doesn't necessarily mean that the code is confidential. What does 'not for inclusion' mean though? It's probably better to ask this question on the infra@ list, since it's a lot more likely that the discussion surrounding the explicit addition of this checkbox happened there rather than here. I'm sure you'd rather have a definitive answer rather than lots of pure speculation. ;-) -- Martin Cooper If it's marked that way, can I take bits of the code out of it? Do I have to worry about looking at that code and then implementing something in the apache code that does the same thing and getting sued? For example, what if someone posts a bit of Sun's Java source to the Harmony JIRA and marks it 'not for inclusion'. There's a world of meaning in that not for inclusion flag. What's in it for the ASF to have a not for inclusion option? I'm not seeing why we allow it - better to say Anything here is for inclusion. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clarification on SF license and sandboxes
On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: Given that there is a checkbox in JIRA, and the fact that this is confusing at least, could we get the checkbox removed, or the policy documented? The point of the checkbox is that if it's checked, you don't need to ask further. That Bugzilla doesn't have it means that we have to ask, which generally takes longer. Documenting the policy would be fine, but removing the checkbox would be a step backwards, IMO, especially since we specifically asked for it to be added. -- Martin Cooper Craig On Nov 1, 2006, at 4:11 PM, Henri Yandell wrote: On 11/1/06, Craig L Russell [EMAIL PROTECTED] wrote: It's best practice to require that contributions be accompanied by the checkbox to grant the license. I haven't seen any official Apache policy guideline on this subject. Given that Bugzilla doesn't have such a thing - it would seem that it can't be that critical. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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!
Re: JiniProposal - BraintreeProposal
On 10/24/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Jim Hurley wrote: The third preference (braintree) seems fairly clean, so we are going to go with this name for our project proposal. I am looking forward to seeing JINI move into the Incubator, but out of curiosity, did Braintree Software (www.braintree.com) not come up in your search? They appear to be defunct, although the domain still exists, and I was able to pull up the current domain registration via OpenSRS. Didn't we also agree not to use proper nouns and place names? Braintree is a town in Essex, UK. -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Ivy
On 10/23/06, Erik Hatcher [EMAIL PROTECTED] wrote: On Oct 23, 2006, at 6:50 PM, david reid wrote: Erik Hatcher wrote: +1 (binding) Forgive my ignorance, but what does +1 (binding) mean? see here: http://www.apache.org/foundation/voting.html Right, but this is a proposal, not a vote. There is no concept of a binding +1 on a proposal. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BLOWING WIND v.s. VOTING
On 10/23/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Martin Cooper wrote: Right, but this is a proposal, not a vote. screch Break, folks. There is a REALLY basic principal from parliamentary procedure that exists for a very good reason, to avoid long pointless debate without decisions... This isn't parliament, it's [EMAIL PROTECTED] The principal is this; there is NO discussion without a motion on the floor, period. Ever. So you're saying that we should treat every thread on this list as if it had an implicit [VOTE] in the subject line? Even the ones that have [discussion] or [doc] or [jira] in the subject? Why? Because discussion that isn't about the business in front of the body is just blowing wind. It forces the member to stop and define exactly what they want to accomplish, and propose it. Then the body deliberates, and reshapes the motion, and it comes out as something that the majority can agree to, or it's shot down entirely. I suspect everyone on this list has been annoyed by some [VOTE] thread or another straying from a vote into a lengthy discussion. We get annoyed because every thread is *not* a vote, and we like to separate votes from discussion. If you're saying that we can't have a discussion without that also implicitly being a vote, how is this supposed to work? I hope I'm just missing something obvious, or misunderstanding you completely. -- Martin Cooper Getting back to geeks, we all love the axiom Don't ask to ask, just ask about irc and mailing list dev channels. It's the same concept. So please, put your proposal on the floor. It's subject to an immediate vote to adopt for incubation. Put your request for committers / releases / graduation on the floor. Let's get them fixed or get them done. You may get +1 votes (you may get enough of them). You may get -1 votes, requiring you to amend your retract your motion, or see it through to the bitter end of voting. And you will probably get no-vote feedback that you can amend your motion in response to, or ignore altogether. It's up to you, you made the motion. Most of this traffic in the past few weeks has been (in parliamentary terms) out of order. Let's get back to work. Nike and Royal Bank of Scotland have ad campaigns that say essentially this, Just Do It or Make It Happen :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anyone up for a docathon at ApacheCon Austin?
On 10/3/06, robert burrell donkin [EMAIL PROTECTED] wrote: On 10/3/06, Jean T. Anderson [EMAIL PROTECTED] wrote: I've been holding onto posts with good fodder for the incubator site, but haven't had time to incorporate them yet. I'll be at the hackathon on Tuesday Oct 10. Is anyone else up for a docathon? (Or did I miss a post already suggesting one? *chagrin*) i'll be an ocean away but i'm willing to take a day off and hook up remotely might be interesting to try a distributed collaborative documentation tool You could try this: http://www.jotlive.com/ -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On 10/1/06, Mads Toftum [EMAIL PROTECTED] wrote: On Sun, Oct 01, 2006 at 11:32:44AM -0700, Justin Erenkrantz wrote: -1. I think your response is extremely misguided. In this situation, we would accept code without allowing the people who contributed it further access: that is completely unfair. If we do not accept the people, we don't accept the code. -- justin So are you suggesting we boot out a project like xxx? or are you happy with incubator projects being fully open for companies stacking their employees in to own a project? I for one find it quite worrying that it is entirely possible to list something like 10 or 15 of your employees on a proposal and sidestep the whole meritocracy issue. I do too. And with the number of projects coming in with sizeable numbers of committers these days, I wonder how long it will be before the committers coming in this way will outnumber those whose committership is based on (ASF earned) merit. It seems to me that this could change the fundamental nature of the ASF. -- Martin Cooper vh Mads Toftum -- http://soulfood.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RELEASES] any interest in a source audit tool?
On 9/14/06, robert burrell donkin [EMAIL PROTECTED] wrote: i have a basic tool that i've been running against the source releases recently. it's simple but helps to track down some basic issues. no documentation. would this tool be useful for podlings (mentors and release managers in particular)? Depending on what it checks, it might be useful beyond just podlings. if so, would it be appropriate to check the source in somewhere in the incubator public tree? Unless it's really incubator specific, why not check it into the committers area of the repo? -- Martin Cooper - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] are board resolutions ok for http://incubator.apache.org/official/...?
On 8/29/06, Leo Simons [EMAIL PROTECTED] wrote: (moved from [EMAIL PROTECTED] since I imagine some people want to say something who don't read that) ? Um, I don't think you moved it anywhere. ;-) On Mon, Aug 28, 2006 at 11:39:52AM -0700, Justin Erenkrantz wrote: On 8/28/06, robert burrell donkin [EMAIL PROTECTED] wrote: i have one or two board resolutions that it would be a good idea to bring to the attention of new podlings. since it's board policy, i think it'd be better to link to html documents containing the actual content rather a second hand account. can anyone think of any reason why board resolutions should be private...? http://www.apache.org/foundation/board/calendar.html (They should generally be treated as private until the minutes are approved and posted there.) Huh? Why? What kind of data is in there that needs to be private? You mean wait 9 months for a TLP to start operating? Or wait implementing new legal policies for about 6 months are they're ratifieid? If, after a board meeting, there was some kind of (short or long) notification that a particular resolution was made/tabled/rejected, I think you could trust the board@ people to be reasonable and appropriate about disclosing that information, sometimes including the full text of the resolution. That's certainly how I've seen things happen over the last few years (even if the result of board meetings is not always reported informally, when it is, that usually prompts near-immediate action). For example, I think loads of TLPs list their Creation resolution, and I think most of them did that before it was in the official minutes. Similarly, I'll bet we had the ASLv1.1 - ALv2 conversion well underway before it appeared in the minutes. Up to about a year ago, board summaries were sent to committers@, and so were public. Since then, they've been sent to members@ instead, making them private. I don't know the reason for the change, but if they went back to being public again, I would expect that pieces of them could be extracted and used as they used to be. -- Martin Cooper LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 8/15/06, Ian Holsman [EMAIL PROTECTED] wrote: snip/ If a individual doesn't like the method the project is communicating with then it is up to him to convince the rest of the community/project to change. It's not necessarily a question of 'like'. Even if someone likes IRC, they may not have access to it from their work environment, or they may not be able to spend time at their day job chatting about their favourite open source project. snip/ (I'm going to get flamed here) this clinging to email is probably a symptom of a bigger problem. Trust. People don't trust other members to make a decision, and always want to add their 2c's because they are smart people and have their own insights and they know what's best. and want to feel that they are needed or something. This consensus-based approach we have adopted is a drag. I don't believe we should wait 48 hours so everyone has a chance to weigh in.. I'd much rather have a quorum based approach X members say +1 and it's a done deal. Maybe it's just me, but that's not the way I see it at all. Absolutely, I trust the other committers on the projects I work on. But that doesn't mean I believe that they're always right. I would *much* prefer to have a chance to express my opinions before a decision is made, than come along late to the party and find myself vetoing something because I strongly believed that the wrong decision had been made. (Not that I believe I'm always right either!) And as for our concensus-based approach, well, I see that as a large part of who we are. Give that up and the ASF isn't the same ASF any more. get a better job? I just did. ;-) And that I don't have day-time access to IRC doesn't make it a worse job, either. I just have to consider day-job-time to be a non-IRC timezone. -- Martin Cooper
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On 7/27/06, Garrett Rooney [EMAIL PROTECTED] wrote: On 7/27/06, Carl Trieloff [EMAIL PROTECTED] wrote: Garrett Some of us spoke about this at lunch. As Glasgow is part of the university name, Glasgow Haskell it should not present a conflict. In addition, our legal department has conducted a trademark search of the word Glasgow and come up with no software-related registrations. I don't know, it still seems awfully close to me, when I hear the word Glasgow in a software context that's the first thing I think of. The first thing I think of is the JavaBeans spec. Glasgow - the code name for add-ins to the JavaBeans specification. http://java.sun.com/products/javabeans/faq/faq.schedule.html -- Martin Cooper -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary email, balanced use of IRC
On 6/23/06, David Crossley [EMAIL PROTECTED] wrote: Cliff Schmidt wrote: Noel J. Bergman wrote: The use of e-mail as the primary means for communication is part of ASF policy and philosophy, and we can certainly learn lessons from projects that have gone against it. IRC tends to breed a more closed, albeit arguably more integrated, community. That said, if IRC can be used as a learning tool to rapidly bring new people up to speed, and if the information gathered from those sessions is preserved for others to follow up via web-site and e-mail, how do people perceive that? I've never done that on a project, but I think it could be a reasonable thing for a project to try. I believe the Synapse folks have been doing regular IRC meetings from early on. I'd be interested in their perspective on the pros and cons, particularly as an incubating project. As a XAP mentor, I know that the committers already understand that no decisions will be made over IRC, that logs of each IRC will be immediately made available to the entire community, and that they need to be sensitive to any concerns from people wishing but unable to participate. But, are there other thoughts from the Synapse folks or anyone else who has used regular IRC meetings? At Apache Forrest we strive to have all communication via the mailing lists. We have a deliberate IRC session once per month. It goes for 24 hours so that everyone can be involved. It is the second Friday of the month starting at a specific time. We use a different channel name, chosen by the operator. That prevents the channel from being constantly available and turning into either a club or a support forum. http://forrest.apache.org/forrest-friday.html We simultaneously use the dev@ mailing list. Some issues are better dealt with there. The committer who is operator does a regular commit of the logfile to our SVN. This keeps good track and allows us to refer to the log during the meeting. It could also enable people not on IRC to still be involved because they could reply to the svn commit email. Wading through 24 hours of IRC logs is not something many people are going to do, though, especially if they weren't part of the original discussion, and so don't know what they're looking for. We have said that we will also create a summary text of the days events. This latter task has not been carried out very well. This is one of my main concerns. More times than not, I've seen claims that a summary will be posted that are not followed up. Personally i reckon that the events have been very beneficial. Have you participated in them? I'm sure people who participate feel they go well, but I'd be more concerned about how the people who have _not_participated feel about them. -- Martin Cooper I am still wary of using IRC more often than that. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extensible Ajax Platform (XAP) Project Update
On 6/22/06, Coach Wei [EMAIL PROTECTED] wrote: XAP project infrastructure has been set up, code has been committed and the project is up and running: 1. The initial website is set up at: http://incubator.apache.org/xap 2. The source code is at: http://svn.apache.org/repos/asf/incubator/xap 3. You are welcome to subscribe to XAP dev list via [EMAIL PROTECTED] 4. XAP developers hold bi-weekly IRC chat on irc.freenode.net - channel #xap. This is held on Thursday of the 2nd and 4th week every month at 17:00PM GMT (1PM ET, 10AM PT) for one hour. The next one is on June 29th. I'm concerned that an incubating project is using an exclusionary communication channel such as IRC right from the get-go. People who are in the wrong time zone, or people who don't have access to IRC or are simply unavailable at the right time, will be excluded from the discussion. While I saw that the minutes of the last meeting were posted to the dev list, I also saw, in those minutes, that the decision to have biweekly IRC chats was itself made on IRC... And IRC transcripts such as the one that was posted are very hard to read, making it much more difficult for those not participating at the time to get the gist of what actually happened. IMHO, all of the discussions, especially this early on, should be happening on the mailing lists, to encourage more people to participate, and thus help grow the community. -- Martin Cooper Please send comments/questions/issues etc to [EMAIL PROTECTED] Thanks. --Coach Wei -Original Message- From: Cliff Schmidt [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 2:58 PM To: general@incubator.apache.org Subject: [VOTE][RESULT] XAP Proposal PASSED Based on the following votes (five of which were cast by PMC members), the XAP proposal has been accepted for incubation under the sponsorship of the Incubator PMC. +1 Davanum Srinivas +1 Noel J. Bergman +1 Craeg Strong +1 Henri Yandell +1 Susan Wu +1 Craig L Russell +1 Sanjiva Weerawarana +1 Jim Jagielski - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committers
On 6/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 6/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yah, I guess so. But, then follow the rest of the stuff on the new committers page that Jean sent out.-- justin thanks justin. sorry justin, for bothering you again... Or should we create a adffaces-ppmc list for the adf faces incubation? We didn't have one for the WebWork incubation, which I think is similar to the situation you are in with ADFFaces. We also didn't get clear direction on what we were supposed to do, so we just used the Struts PMC + initial committers as an informal PPMC to vote on bringing in new committers. -- Martin Cooper -Matthias snip After vetting the new candidate, the vote can take place either on the PPMC list (with notice posted to the Incubator PMC list) or on the developer list (with a notice posted to the Incubator's general list). The latter practice of a private discussion followed by a public, pro-forma, vote is re-emerging as a Best Practice for ASF projects. /snip I think I'd like to vote on the adffaces-dev list, after I had a discussion on the myfaces pmc list. Thanks for clearing. -Matthias -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE-RESULT] Incubator to sponsor and accept Abdera for incubation
On 6/5/06, Paul Querna [EMAIL PROTECTED] wrote: Garrett Rooney wrote: On 6/5/06, Paul Querna [EMAIL PROTECTED] wrote: Garrett Rooney wrote: On 6/5/06, Sam Ruby [EMAIL PROTECTED] wrote: Sam Ruby wrote: With the following votes cast: +1 Sam Ruby +1 Garrett Rooney +1 Paul Fremantle +1 Davanum Srinivas +1 Yoav Shapira +1 Jim Jagielski +1 Robert Burrell Donkin +1 Martin Cooper +1 Geir Magnusson Jr ... this vote passes. At this point I'd like to ask that the mentors (Garrett Rooney, and Paul Querna) create the status file and work with infrastructure to get the necessary mailing lists, repository, and the like set up. I'd be happy to do so, but I probably won't have time until later this week. If someone beats me to it, more power to them. Mailing lists: http://issues.apache.org/jira/browse/INFRA-829 Repository: https://svn.apache.org/repos/asf/incubator/abdera/ Initial committers: abdera=eliast,rubys,yoavs James M Snell and Robert Yates do not have CLAs or accounts. Bugzilla: http://issues.apache.org/jira/browse/INFRA-830 Perhaps we should consult the initial project members and see if they would prefer JIRA to Bugzilla, before we actually start creating projects and so forth... I also wouldn't mind Jira, I was just following what was in the proposal :) I would actually recommend JIRA over Bugzilla, because of all the increased ease of use for both users and developers, and because of the additional functionality, such as dashboards and roadmaps, which make it much more than just a bug tracking system. The communities I'm involved with that have switched from Bugzilla to JIRA are definitely glad they so. -- Martin Cooper -Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ARI, Atom Reference Implementation [Proposal]
On 5/24/06, James M Snell [EMAIL PROTECTED] wrote: Does any one have any problems with simply calling this project Atom... as in, The Apache Atom Implementation ? Well, unless I'm mistaken, it would actually be (at least) the second Atom implementation at the ASF, since Roller has one already. Simply calling it Atom implies it has some special status, especially in the phrase you use above (i.e. The Apache Atom Implementation). So I would not be in favour of that name. -- Martin Cooper - James Garrett Rooney wrote: On 5/22/06, James M Snell [EMAIL PROTECTED] wrote: Hello, The following is a new project incubation proposal. We welcome your feedback and would like to extend a invitation for participation including mentors. The proposal is also located at http://wiki.apache.org/incubator/AriProposal The initial source for the project is available at: http://www.snellspace.com/public/ari.tar.gz I would be interested in helping to mentor this project, and perhaps eventually working on C implementations of some of its functionality. One comment though, you might want to reroll ari.tar.gz so it unpacks into a directory named ari, as opposed to spilling all sorts of stuff into the current working directory. -garrett - 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: Name options (was Re: ARI, Atom Reference Implementation [Proposal])
On 5/24/06, James M Snell [EMAIL PROTECTED] wrote: Ok, so here are a few of the name options that seem to be the safest (in no particular order) Iaea (adapted, of course, from the U.N. nuclear watchdog group) Anu (Dims suggestion, sanskrit for atom) Atomico (Spanish/Italian for atomic) Dalton(Suggested by Robert B. Donkin) Abdera(birthplace of the philosopher Demokritos) Of these, I like the last one, Abdera. (Anu is also a female first name, and - JAMES notwithstanding - I'm not that fond of picking people's names for project names.) -- Martin. I think any of these would work. - James Yoav Shapira wrote: Hi, On 5/24/06, James M Snell [EMAIL PROTECTED] wrote: Ok, it was worth a shot. I've been stewing over possible name selections for a couple days and can't seem to come up with any strong possibilities. Why not take the stuff that's been suggested so far (there have been 10+ ideas, no?), put it to a vote here, and take the resulting name so the project can move along? If the committers on the project *really* dislike it later, they may change it. Or do you mean that you want to pick something yourself and don't want a community-chosen name? (I don't really care, I'm just curious to see if I misinterpreted your original call for names) Yoav - 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: ARI, Atom Reference Implementation [Proposal]
On 5/23/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, I'll jump in with a couple of suggestions, although my record on this is dismal (I don't think any of my name suggestions have ever been accepted in the incubator ;)): From the nuclear domain: - Apache Reactor (borrowing on the nuclear connotation of Atom) - Apache Furnace (similar idea) - Apache Fission (also physics-driven, though implies splitting, i.e. not a unified community, so maybe not) - Apache Fusion (might be great as it implies bringing stuff together) A couple of international twists: - Apache Atomico (italian for atomic) - Apache Atomique (frensh for atomic) And the kicker: Apache Schmelzverfahren (german word for fusion) !! Yoav, I just can't understand why people haven't jumped on your suggestions before! ;-) There's also Atomate, a play on automate. -- Martin Cooper Yoav On 5/23/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Please see my comments in-line. robert burrell donkin wrote: On 5/23/06, Eran Chinthaka [EMAIL PROTECTED] wrote: Hi, Hi, AIUI not as a mentor. it's a particular role involving oversight and the current concensus amongst the membership is that this is something that should be restricted to members only. Ok... but that doesn't mean that it wouldn't be good to have you involved. you don't need to be a formal mentor to offer guidance on list. if you're going to be able to find some time to help out with the coding then maybe it'd be a good idea if your name were added to the proposal as a developer. I leave the discretion, of me adding as a developer, with the original proposers. But I'm ready to help anytime specially with Axiom. Perhaps I might even be able to crunch some code. Will give more feedback after downloading the original code. -- Chinthaka -- Yoav Shapira Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (INCUBATOR-17) Set Up SVN Repository for ADF Faces Podling
[ http://issues.apache.org/jira/browse/INCUBATOR-17?page=comments#action_12374462 ] Martin Cooper commented on INCUBATOR-17: Could someone with appropriate karma please close this out? I don't seem to have that karma. The issue has been resolved. See INFRA-749. Set Up SVN Repository for ADF Faces Podling - Key: INCUBATOR-17 URL: http://issues.apache.org/jira/browse/INCUBATOR-17 Project: Incubator Type: New Feature Reporter: Craig McClanahan Per the ADF Faces proposal[1] that was accepted by the MyFaces PMC, please set up a Subversion workspace named adffaces under the Incubator SVN root directory. Initial committers (with current Apache accounts) shall be: * Craig McClanahan craigmcc * Matthias Wessendorf matzew * Martin Marinschek mmarinschek * Bruno Aranda baranda We will also be adding several additional developers as soon as their accounts have been set up (documented via a separate JIRA ticket). [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] AJAX Toolkit Proposal - Updated
On Tue, 17 Jan 2006, Andrew Clark wrote: Justin Erenkrantz wrote: I see .java files - that has nothing to do with AJAX, so I'm sort of confused. I'd be expecting to see, well, only JavaScript. [...] If it has .java files, it isn't a 'client library'. So, I want to make sure we clarify where the boundaries are, so stupid people like me can make calls as to whether there's scope creep or not. Without communication to the host server, AJAX is just JavaScript in a web page. So there is a natural tendency to have server-side infrastructure to complete the AJAX programming model. While some AJAX toolkits do include server side code (e.g. Zimbra, DWR), others do not (e.g. Prototype, Dojo). There are pros and cons on both sides. You've detailed some of the advantages of providing it; the main down side would seem to be that it could slow adoption by those who are building their web apps with other server side languages, or even dissuade them from using it. Of course, you could always add support for other languages as well, assuming there are no ties to Java. My 2 cents. -- Martin Cooper At a basic level, there's a need to provide localized content for the application running in the browser. For example, in the Zimbra client, we put all of the resources in a standard Java .properties file and have a simple servlet detect the preferred language, load the resources (merging them), and return the data as a JS class. And at a higher level, there's a need for authorization, notification, etc. While this submission starts with the primary widget toolkit needed to start building AJAX applications, there is a need for server-side code to complete the model. And Java is a natural solution for this part and it ties in nicely with Tomcat and other solutions already at Apache. I hope this helps explain why there is some Java code in the client library. And, as for scope, I don't think the AJAX toolkit will stop simply at client-side widgets because that's only half of the picture. But I think we can start there and have it grow/evolve over time. -- Andy Clark * Zimbra * [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: ajax proposal?
On 1/16/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Martin Cooper wrote: I *care* about the quality of what we build here at the ASF. [X] can very easily cause problems when [...] I have no problem with either of the above (redacted) sentences. However, the answer, in my view, is not to wait for X to become perfected elsewhere. Rather, if there is something wrong, and it is here, contribute to fixing it, even if the contributions are just kibbitzing. Which is exactly what I've been doing over in MyFaces-land, by explaining (or trying to explain, anyway) the issues with the use of Prototype in the MyFaces ecosystem. I'm not a MyFaces committer, and I don't even use JSF, but I'm still trying to help. As for whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) -- Martin Cooper Even if you don't contribute code, if you raise perfectly valid issues, and they are ignored, that would be an indicator that the project is not right. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/16/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Martin Cooper wrote: whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) If you take your comment to a conclusion, you could be saying that if you don't have time to contribute here, the project should be rejected. Yes, I agree that I've reduced your comment to the absurd conclusion, and one which you most certainly did not intend. Correct, I did not. The only reason I made that comment at all was because it wasn't clear to me whether your earlier comment, encouraging me to contribute to fixing it, was in reference to the use of Prototype in MyFaces or to a potential redesign of the Zimbra code, so I chose to address both. But what is a solution? You appear to be against trying to incubate the project because of its current architecture, others appear to want to try. Do we accept it because they want it give it a try, or reject it without trying because you don't have time to help fix it? I'll take that as rhetorical. But I'd be curious to know how many of those who have expressed an interest in incubating Zimbra, other than the Zimbra folks themselves, are JavaScript developers planning on contributing to the code base, versus people who just think having an AJAX project at the ASF would be cool, and hope other people will do the (coding) work. Clearly I'm a lone voice here, albeit making a fair amount of noise. Given that nobody else seems to share my views on the architecture or on the effect of the ASF brand on the AJAX world, and given that the incubator appears to be a just knock and you're in project anyway, I've assumed pretty much from the get-go that I'm fighting a lost cause here. But that doesn't mean I want to go quietly. -- Martin Cooper I'll note that although I'm not familar with Zimbra, there is another proposed project for the Incubator that I am familar with, due to working with another project that uses it, and I seriously dislike it (I'd never use it). Yes, I'm being intentionally vague, because I don't want to prejudice it, and there are other people quite keen to incubate the project. FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/16/06, Erik Abele [EMAIL PROTECTED] wrote: On 17.01.2006, at 00:02, Noel J. Bergman wrote: Martin Cooper wrote: whether I get involved with the Zimbra toolkit, and try to help them see the light, I need to make a personal decision between putting my energy into that, here at the ASF, or putting it into a non-ASF project that is already on the right track. I know I don't have the energy to do both. ;-) ... FWIW, I would want to see your technical concerns addressed before graduation, but so far, we have had little if any discussion of what those tecnical issues really are, or so it seems from the archives. rantRemember that it's about the community not the code... maybe you should add another bullet to the list at http:// incubator.apache.org/incubation/Incubation_Policy.html to record this new criterion as another entry and/or exit requirement.../rant Seriously, I don't understand why you are talking about code maturity here I'm not talking about code maturity. You might want to re-read the threads. - IMO this isn't and shouldn't be one of the incubators concerns - you are here to discuss legal stuff, community issues, mentors and the Apache Way, no? And the impact of giving a project the ASF brand. And the way the incubator operates as an open door to whoever knocks, with virtually no entry criteria. -- Martin Cooper Cheers, Erik
Re: ajax proposal?
On Thu, 5 Jan 2006, Dirk-Willem van Gulik wrote: On Wed, 4 Jan 2006, Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? .. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or We are part of that market - and I have no illusions about our ability to set standards; we canot; we ONLY seem to do so when we happen to a) to jump on the boat with the right technology and b) get the market to play in our playground. (Marginally helped of course by the fact that so many talented peopel and companies come to play here that we do set the odd's for 'a' and have 'b' causal). If your argument is that the quality of Zimbra code is relatively low; or too immature by itself - and that is why you worry about spoiling the market by betting on the wrong horse - then we should simply reject -this- proposal based on the fact that there is a) not enough quality in the donation and b) no hope for it to improve in our playground. An analogy would be the Java web app environment 5 years ago, when Model 2 frameworks came along and people realised that that was the way things should be done, instead of Model 1. Just as I would not have been in favour of bringing a Model 1 framework to the ASF at that time, I'm not in favour of bringing in what I consider to be a previous-generation JavaScript framework now. Why would we want to perpetuate the old way of doing things? -- Martin Cooper But in general - having the ASF offer it's eco system a place where we all can work on Ajax (and have synergy with all the portal code we have, with MyFaces^H^H^H^H^H^HOurFaces) seems like the right thing to do -when- there are sufficient people interested to work on it. Which is the right validating feedback loop. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On Thu, 5 Jan 2006, Martin Marinschek wrote: We could of course also set-up quality standards which have to be fullfilled before the project _leaves_ incubation. That's a good bar to set... As the name MyFaces has been mentioned quite a bit, I'll explain our situation. We currently use the prototype framework (one of the widely used projects in the market, which Martin Cooper by the way doesn't like either, due to namespacing issues). So, if Zimbra has the same problems, we don't really have a need for the library. Whether I like Prototype or not isn't really the point. The point is that I *care* about the quality of what we build here at the ASF. Prototype can very easily cause problems when combined with other JavaScript code, and this situation is even worse in a portlet environment, so I simply want to make sure that the MyFaces team isn't setting itself up for problems by relying on it. -- Martin Cooper We are hoping for a major donation regarding javascript with ADF Faces - haven't had any chance to look on the sourcecode so far, though. Maybe this will settle all our javascript needs and we'll stop looking out for anything else. regards, Martin On 1/5/06, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: On Wed, 4 Jan 2006, Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? .. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or We are part of that market - and I have no illusions about our ability to set standards; we canot; we ONLY seem to do so when we happen to a) to jump on the boat with the right technology and b) get the market to play in our playground. (Marginally helped of course by the fact that so many talented peopel and companies come to play here that we do set the odd's for 'a' and have 'b' causal). If your argument is that the quality of Zimbra code is relatively low; or too immature by itself - and that is why you worry about spoiling the market by betting on the wrong horse - then we should simply reject -this- proposal based on the fact that there is a) not enough quality in the donation and b) no hope for it to improve in our playground. But in general - having the ASF offer it's eco system a place where we all can work on Ajax (and have synergy with all the portal code we have, with MyFaces^H^H^H^H^H^HOurFaces) seems like the right thing to do -when- there are sufficient people interested to work on it. Which is the right validating feedback loop. Dw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces - 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: ajax proposal?
On Thu, 5 Jan 2006, Jim Jagielski wrote: On Jan 5, 2006, at 1:38 PM, Sam Ruby wrote: Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Once we have had a chance to digest all the input and finish dotting the I's and crossing the T's from a legal perspective, Adam or I will come back to ask for a vote. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) Sanjiva and I have experience with Apache SOAP. Two rewrites later, and there is a thriving community working on Apache Axis2. The goal here is not to crown anything, but to provide the grain of sand that will lead to the production of a pearl. I am a big +1 on the ASF getting involved with AJAX. Oh, I am too. I'd just prefer to start off on the right foot. -- Martin Cooper - 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: ajax proposal?
On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) -- Martin Cooper Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/4/06, Dan Diephouse [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 1/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: So .. amidst all of our soul searching .. what'd we decide to do with the Ajax proposal from IBM et al.?? Did I miss the vote and decision?? I don't believe there is a sponsoring PMC at this point. Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I realise that the Incubator doesn't work that way, though, and that plenty of people don't seem to care / mind that we'd create a (premature, IMHO) de facto standard, but I can always hope. ;-) I am confused - why can't there be multiple ajax projects at somepoint? I don't recall saying there could not. What I am saying is that, were one to come here now, it would rapidly become the de facto standard simply by virtue of being here at the ASF. And once there is a de facto standard, many people won't even bother to look elsewhere, or bother to evaluate its merits or lack of them, because they've already got license, so to speak, to use ASF software. In fact, if we have to have Zimbra here, I would be right with you in hoping something better turns up sooner rather than later. ;-) -- Martin Cooper As the perlers say, there is more than one way to do things. See my note in a previous thread about multiple web app frameworks, etc, etc[1]. - Dan 1. http://mail-archives.apache.org/mod_mbox/incubator-general/200512.mbox/[EMAIL PROTECTED] -- Martin Cooper Sanjiva. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dan Diephouse Envoi Solutions LLC http://netzooid.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajax proposal?
On 1/4/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Dan Diephouse wrote: Martin Cooper wrote: Personally, I would prefer that the ASF not accept _any_ AJAX framework at this point in time. The area is relatively new and in a great deal of flux right now, and crowning one of them with the ASF brand will create a de facto standard instead of letting the market decide, whether we like it or not. I am confused - why can't there be multiple ajax projects at somepoint? No reason. Martin expressed his personal view. Personally, I disagree with his view. I don't believe that the ASF should be a place for crowning staid and mature projects. I would like to see continued innovation here, too. I agree with you. Unfortunately, from what I've seen from looking at Zimbra, it's more like the first generation way of doing DHTML frameworks. I'd prefer not to have that become the de facto standard, and have the ASF innovate in the wide open playing field of the next generation frameworks that are out there now. Yes - let's innovate! AJAX is an interesting area, with potential impact for Portals, WS, MyFaces, and elsewhere. Last Fall, we had someone wanting to contribute a JavaScript version of LOG4J, and nowhere to go. An AJAX project would have provided a natural home. It might have provided a sponsoring PMC, but it's not at all obvious that it would have provided a natural home. Just because they're both written in JavaScript doesn't mean they have any more in common than that. Jakarta for JavaScript? ;-) But yes, AJAX, or more generally, DHTML, is definitely an interesting area. In addition to the projects you mention above, Struts, Tapestry, Cocoon and Jakarta Commons are all working in this area (and all of those are looking at, or already using, next-generation AJAX frameworks). -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The line between full incubation and IP clearance
On 1/1/06, Ted Husted [EMAIL PROTECTED] wrote: On 12/28/05, Noel J. Bergman [EMAIL PROTECTED] wrote: Although that might be technically true, we do things collectively in the ASF. Mind you, we've not had a process for voting on IP Clearance type submissions, so that's been a potential loophole. I'm not sure what a vote would accomplish. Are we saying that we don't trust PMCs to do due diligence as to the action items on the checklist? That would be a strange perspective since the key role of every TLP PMC is to oversee the IP of each and every commit made to the project's repository. An attractive aspect of the IP Clearance protocol is that it *closes* the podling loophole that might bring committers into the Foundation outside of the meritocratic process. One thing that the votes on the proposal and podling graduation do is sanction the list of podling committers, who usually go on to become PMC members. In that case, we do need the Incubator PMC to vote on the new committers, and since the podling is an unproven community, we do need someone to decide if the community meets our standard of meritocracy. If code is developed outside of an ASF repository and mailing list, then it is appropriate that we provide a pedigree for the code. It is also appropriate that we have a central record of all such code that a PMC is bringing int our repository. It is also appropriate that we maintain that record at the Incubator, so that all external code arrives in one place. But, I would suggest that the people best suited to vote on the code itself are the people who are already making the technical decisions about such code: The receiving PMC. In the case of an IP Clearance, there is not a new community to consider. In some cases, I would agree. In others, I would not. In the particular case of MyFaces accepting the ADF Faces donation, for example, I believe that MyFaces has a general JSF community, but I disagree that there will therefore be a de facto community around ADF Faces just because the MyFaces PMC decides to accept the code. This has to do with the scale of the donation. While none of us have seen the code yet, my expectation is that the donation will be at least as large as the existing MyFaces code base, if not larger. That is not something that would be naturally absorbed by an existing community. In fact, in this particular case, it seems clear from the discussions on [EMAIL PROTECTED] that most people - from both MyFaces and ADF Faces - would prefer that the ADF Faces donation go through the full incubation process. I fully understand and respect your desire to close the free committership loophole, but I also believe that such a substantial donation warrants full incubation. Short of asking Oracle to keep the proposed committer list to a minimum (e.g. Adam John), I'm not sure how we can resolve this dilemma. -- Martin Cooper What is before the Incubator PMC is the issue of whether the code *can* be licensed to the Foundation. Whether the code *should* be licensed to the Foundation is a decision best left to the receiving PMC, who, by direction of the Board, already decide whether such code should be licensed to the ASF every time there is a commit to that project. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experiment : Incubator site done in xdocs...
On 1/1/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I realize that many might have checked-out of this thread about 200 messages ago... if there's any interest or comment... +1. I like it. And I especially like the Flooga Wagie Foo Foo news. ;-) Happy New Year! -- Martin Cooper (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: Forums/Mailing lists Was: Starting a java specs project
On 12/30/05, Henri Yandell [EMAIL PROTECTED] wrote: On 12/30/05, Thomas Dudziak [EMAIL PROTECTED] wrote: Though that would probably be more of a forum-type community rather than a mailinglist-type community. A subject for a different thread; but after looking at the latest Jyve stuff at ApacheCon, it seems entirely possible for a forum-type community and a mailinglist-type community to be the same. Nabble/GMane show that already, and something like Jyve could help do that even more. What would Jyve give us that Nabble doesn't do for us already - and without us having to lift a finger, to boot? -- Martin Cooper Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forums/Mailing lists Was: Starting a java specs project
On 12/30/05, Thomas Dudziak [EMAIL PROTECTED] wrote: On 12/30/05, Martin Cooper [EMAIL PROTECTED] wrote: What would Jyve give us that Nabble doesn't do for us already - and without us having to lift a finger, to boot? My wish would basically be for something that allows a user to use it transparently as a mailing list or forum (whatever the user wants) where in the first case he gets every forum post/mail and can post via mail and, in the latter case has to actively check what's new and has to use the forum UI to post. If both Nabble and Jyve can to this (don't know either one, could you perhaps supply some links ?), then I'd go for the one with the more features :-) E.g. better search, better forum UI (did I say that I really like Spring's forums :-) ). From an overall ASF perspective, I'd be more likely to go with the one that has less overhead. Nabble is already there, doing the forum thing, and completely managed outside of the ASF. Nobody at the ASF has to do anything but add new mailing lists to it periodically. My understanding (which could be completely wrong ;) is that Jyve would need to be installed and managed at the ASF to provide the same kind of functionality. That means it has infrastructure requirements - hardware, software and especially people to maintain it. That being the case, I'd want to see a compelling case for Jyve over Nabble, and names of people willing to do the work. -- Martin Cooper Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The line between full incubation and IP clearance
Is there a well-defined line between these two mechanisms for bringing new code to the ASF? Not having seen the code yet, I can't say for sure, but I would expect the Oracle ADF Faces donation to be substantial, and include a framework that ties everything together. I would have thought that would have warranted full incubation, but it appears to be going through only the UP Clearance procedure. See: http://mail-archives.apache.org/mod_mbox/myfaces-dev/200512.mbox/[EMAIL PROTECTED] I'm new in Incubator-land, so I'm not altogether savvy about processes and procedures, but wanted to ask about this one. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The line between full incubation and IP clearance
On 12/28/05, Noel J. Bergman [EMAIL PROTECTED] wrote: Martin, Is there a well-defined line between these two mechanisms for bringing new code to the ASF? No, not a well-defined one. The IP Clearance is primarily intended for use with a relatively simple Software Grant situation into an existing project, such as libtool, which we can contrast with mod_cli or mod_ftp. And, honestly, I think that we have made a few mistakes in the past by using the simpler form when a fuller incubation would have yielded a better result in terms of community building around new code. I would expect the Oracle ADF Faces donation to be substantial, and include a framework that ties everything together. I would have thought that would have warranted full incubation Is there community, or just code? If a community comes with it, too, I would certainly expect incubation, however, the e-mail you referenced says (in part): [after clearance,] the MyFaces committers treat the code as if we wrote it ourselves, and I don't see any mention of a community coming, too. But here is a sample grey area: one or two committers absorbed into a healthy community might be deemed acceptable, whereas a substantial number of new ones might not. So if you buy that argument, where do we draw the line, and how do we address potential abuse? I suppose I'm asking prematurely, since, of course, I haven't seen a proposal either. ;-) However, up until now, ADF Faces has been part of (or an add-on to - I'm not sure) a commercial Oracle product (JDeveloper). There may be OTN forums that it's discussed on; not sure if that counts as a community. Also, since it's no longer all of ADF Faces that's going to be offered to the ASF, I don't know how that would affect any existing community. I expect that some Oracle developers will be listed in the forthcoming proposal, and they will most likely be needed, too. How many, I have no idea. How much cross-pollination between the ADF Faces code base and the existing MyFaces code is also an open question in my mind. At least initially, I would expect that the ADF Faces code base will be set up as a separate build and download from the existing MyFaces code, until the collective team decides how to integrate the two, or even if integrating them makes sense, versus treating ADF Faces as a separate sub-project. -- Martin Cooper I'm new in Incubator-land, so I'm not altogether savvy about processes and procedures, but wanted to ask about this one. It is a fine question. Hypothetically, without judging the merits of this submission, you raise the spectre of a type of situation that I'd want to ward against as a general rule. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] bring in full code history on incubated project?
On Fri, 23 Dec 2005, Roy T. Fielding wrote: On Dec 23, 2005, at 2:26 PM, Justin Erenkrantz wrote: snip/ Is it permissible to commit code to our repositories that were under, say, GPL (for when a project, like SA, re-licenses)? Yes. Relicensing means the copyright owners offer a different set of terms for the same code -- they do not have to change the files for that to take effect. So what would it mean if Project Foo comes to the ASF, having released their 1.0 beforehand under the GPL, and then I grab the 1.0 code from the ASF repo and release that as my own version of the original 1.0? Can I release this new version under the Apache License, thereby effectively retroactively relicensing 1.0 under that license, or is that version still GPL, therefore meaning GPL code is checked into the ASF repo? I don't really understand how this would work, but it seems kinda important. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: iBatis..
On 12/22/05, Larry Meadors [EMAIL PROTECTED] wrote: 1) We are not in the incubator anymore. 2) Odd...not sure what's up with that. 3) Probaly will not make that change (and break all those apps) until 3.x Regarding #3, you might want to check out this current thread: http://www.nabble.com/Incubating-java-projects-t779868.html -- Martin Cooper Larry On 12/22/05, Martin van den Bemt [EMAIL PROTECTED] wrote: Hi all, What is the status of iBatis ? On the website (ibatis.apache.org) it doesn't say it is in the incubator (unless you look really good), in the status on the incubator site they are still in incubator and eg in svn eg the packages haven't changed to use the apache namespace.. Just an observation.. Mvgr, Martin - 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
On 12/20/05, Jochen Wiedmann [EMAIL PROTECTED] wrote: Noel J. Bergman wrote: We don't support any of those. Who's we? The Apache Software Foundation. Those other archives are maintained outside of the ASF, by people who most likely have no affiliation with the ASF. Therefore, the ASF cannot provide support for those archives - their support comes from the organisations that run them. -- Martin Cooper As a user, I still prefer marc over mail-archives a real lot and am happy about any Apache project that's available on Marc. But, actually, I replied because your response made me angry. You (choose between You as in We, or You as in I) are the one who dictate the rules. Others do fulfill the rules. Is it up to you to declare that these issues do not exist? Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX Toolkit Framework Proposal
Some comments: 1) This appears to be two proposals rolled into one. One is to incubate a JavaScript toolkit. (It's not clear to me at this point whether or not that toolkit includes a server-side component, but that's not really relevant at this point.) The other is to incubate a development environment that can be used with that toolkit, or apparently with other toolkits if the necessary work is done. The former comes from Zimbra; the latter from IBM. It's not clear to me why this is a single proposal and not two separate ones. I understand that there is synergy between the two, but I believe that explicitly separating them will make each part stronger. The proposal as it is now leaves quite a bit if doubt as to where one ends and the other begins, begging the question of just how separate they really are, and how friendly to other JavaScript toolkits. 2) Various comments have been made regarding multiple ASF projects addressing the same area being OK, and indeed a good thing. While I generally agree with that sentiment, there are grounds for concern when it comes to JavaScript toolkits running in the browser. One issue is that of footprint. As it is today, Zimbra appears to be about a 1.25MB download to the browser, if everything is included. That is *massive* for a JavaScript toolkit. To include that for, for example, one portlet on a portal page, while the remaining portlets use other toolkits, and hence yet more downloads, is expensive and slow. This may sound theoretical, but recall that another substantial JavaScript toolkit is already on its way to the ASF, in the form of ADF Faces from Oracle, heading for MyFaces. That project is not (I sincerely hope) going to want to develop components that target multiple huge JavaScript toolkits in the same library. 3) Related to the above, but from a more technical perspective, it is very disappointing to see so much old-school JavaScript in this toolkit. For example, the code is not namespaced, leading to greater potential for collisions, and appears to be written more like Java code, instead of taking advantage of the features of the JavaScript language. (This is likely a factor in why the amount of code is so large.) The use of the Rico toolkit is also mentioned in the proposal. That toolkit is built on Prototype, which is popular but fragile, and will rapidly lead to problems in any non-uniform environment, especially in portals. 4) While #3 above is technical in nature, such a code base coming to the ASF will tend to lend credence to the way it is structured and built, as a side-effect of the stature of the ASF. IMO, it would do the JavaScript community a disservice to promote old-style JavaScript coding when we should be trying to lead the way in the new world of AJAX. This, of course, doesn't apply to the IDE part of the proposal, which I'm sure any JavaScript developer would appreciate (as long as it works with their toolkit of choice, which it purports to do ;). 5) Given that we have numerous open issues regarding the inclusion of components with non-Apache licenses, I would like to see a more explicit description of the relationship between the proposed code base and other artifacts mentioned in the proposal, such as XULRunner, JavaConnect, Rhino, JSLint and Rico. I know that we current have a problem with Rhino because of the NPL. What other issues does this proposal introduce? 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. -- Martin Cooper On 12/20/05, Sam Ruby [EMAIL PROTECTED] wrote: Kenneth Tam wrote: I have a more specific question: have you guys considered separating this into a plug-ins/tooling donation to Eclipse, and a runtime donation to Apache? It seems like the IP is already in a form that makes this easy (ie, the AJAX Toolkit Framework Eclipse plugins from IBM, and the AjaxTK Javascript library from Zimbra), and there are several examples that suggest this kind of parallel community building works well. I'll take this question, as well as Cliff's below. First, for starters, it is worth noting that there is Apache Licensed code all over the internet - SourceForge, CodeHaus, people's private sites, whatever. Similarly for Eclipse plugins. Second, code licensed under the Apache license can be sublicensed and/or bundled/shipped with other projects. Example: Eclipse ships Ant. Separate from the IP
Re: PROJECT DONATION PROPOSAL: RAD system for internet applications
In addition to Cliff's comments, it would also be interesting to know how Molimo would relate to the web application frameworks at Apache, such as Struts, Turbine, Tapestry, etc. -- Martin Cooper Cliff Schmidt [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi Marcus, Here are a few ideas on how to proceed with your proposal: 1. Read http://incubator.apache.org/incubation/Incubation_Policy.html, particularly the Proposal section. 2. While that policy document is very useful, it unfortunately does not yet provide a short list of what should be in your proposal (we should fix that). Here's another document that discusses what the Jakarta project likes to see in proposals. This outline has been used by many projects outside Jakarta as well: http://jakarta.apache.org/site/newproject.html 3. If you want to see examples of what others have done, see: http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheDirectoryProject http://nagoya.apache.org/wiki/apachewiki.cgi?JaxMeProposal http://nagoya.apache.org/wiki/apachewiki.cgi?TapestryProposal http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansProposal 4. Aside from the formalities of writing and sending in a proposal, you also want to see which other Apache projects might find this interesting. Sending to this list is a start, but you might also want to try the Portals project: - http://portals.apache.org - post to general at portals.apache.org. or the DB/Objectbridge project: - http://db.apache.org/ojb/ - post to obj-dev at db.apache.org There are probably other projects that might find it interesting as well. I hope you find these resources helpful. Once you've had a chance to check them out, please feel free to post back to this list with any questions. Cliff [EMAIL PROTECTED] wrote on Saturday, May 01, 2004 3:11 AM: Hi Folks, We at Molimo developed a system for the rapid type development of complex internet applications (main focus is the server side). We are discussing about donating that system to the apache project. So far we are three developers in this project and we are urgently looking for further developers, therefore we are thinking about this step. We hope that you are interested, this is our project description: Molimo is an open source software system for the easy, rapid development of complex, transaction-based large internet applications using the J2EE platform. Molimo consists of a set of highly configurable components that are easily assembled to your web application. As Molimo is based on the J2EE standard, you may integrate these powerful components in your existing system, e.g. in your CMS - or build a powerful new RIA from scratch. With Molimo, internet development is divided in three easy steps: * First you define your objects in a brand new object-relational database layer * Then you define actions that could be done on these objects * Finally you put all together in a web view using our brand-new, easy to use open source web portal There's also a video presentation online at our homepage. Please don't hesitate to contact us concerning our software. Thanks, Marcus PS: please CC, as I can't subscribe to this list (mail limit) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EyeBrowse bugs
The Eyebrowse software comes from Tigris: http://eyebrowse.tigris.org/ so you might bring it up with them. The underlying search engine, though, is Lucene, which is within Apache: http://jakarta.apache.org/lucene/docs/index.html Our own installation is maintained by the Apache infrastructure group, I believe, and you can reach them at [EMAIL PROTECTED] HTH. -- Martin Cooper David Remy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] hmm. I am going to post this to the incubator list as well in case someone there can help us. -Original Message- From: Toby H Ferguson [mailto:[EMAIL PROTECTED] Sent: Friday, January 23, 2004 10:21 AM To: [EMAIL PROTECTED] Subject: EyeBrowse bugs This is not about XMLBeans, but about the tool we use for looking at the email archive, eyebrowse. Eyebrowse's search functionality has errors - it cannot find things! I've written at least 3 messages, which I can see if I look at the list manually. But if I search for my name using the search facility only 2 such messages are returned. If I search by subject that has problems too - I searched for location and didn't get any messages back, but I know that there's at least one thread with location in the subject. Any ideas who I inform about these problems? Toby H Ferguson - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STATUS] (incubator) Wed Jan 14 23:45:31 EST 2004
Rodent of Unusual Size [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
APACHE INCUBATOR PROJECT
-*-indented-text-*-
Last modified at [$Date: 2003/11/11 00:01:00 $]
Web site: http://Incubator.Apache.Org/
Wiki page:
http://Nagoya.Apache.Org/wiki/apachewiki.cgi?ApacheIncubatorProjectPages
[note: the Web site is the 'official' documentation; the wiki pages
are for collaborative development, including stuff destined for the
Web site.]
Pending Issues
==
o We need to be very very clear about what it takes to be accepted
into the incubator. It should be a very low bar to leap, possibly
not much more than 'no problematic code' and the existence of a
healthy community (we don't want to become a dumping ground).
o We need to be very very clear about what it takes for a podling
to graduate from the incubator. The basic requirements obviously
include: has a home, either as part of another ASF project or as
a new top-level project of its own; needs to be a credit to the
ASF and function well in the ASF framework; ...
On the one hand, we still appear to have this as a pending issue. On the
other hand, we have everyone apparently voting +1 to graduate
MerlinDeveloper. Am I alone in feeling that this is a little odd?
--
Martin Cooper
o Moving the bylaw documentation from the Wiki to the main site
o Merge the README.txt info on site management and the info on the
How to Participate page into a single place
o fix formatting of the project status pages
Resolved Issues
===
o The policy documentation does not need ratification of changes
if there seems consensus. Accordingly, the draft status of these
documents can be removed and we will use the lazy commit first,
discuss later mode common across the ASF for documentation
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgby=threadfrom=517190)
o Coming up with a set of bylaws for the project
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgby=threadfrom=517190)
o All projects under incubation must use a STATUS file (or a
status.xml file if the project prefers XML) that contains
information the PMC needs about the project. This file must
live at the root of the project cvs module
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgby=threadfrom=504543)
o Projects under incubation should display appropriate disclaimers
so that it is clear that they are, indeed, under incubation
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
ache.orgby=threadfrom=504543)
The Incubation Process
==
This tries to list all the actions items that must be complete for a
project
before it can graduate from the incubator. It is probably incomplete.
Identify the project to be incubated:
-- 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.
-- If request from an existing Apache project to adopt an external
package, then ask the Apache project for the cvs module and mail
address names.
-- If request from outside Apache to enter an existing Apache project,
then post a message to that project for them to decide on acceptance.
-- If request from anywhere to become a stand-alone PMC, then assess
the fit with the ASF, and create the lists and modules under the
incubator address/module names if accepted.
Interim responsibility:
-- Who has been identified as the mentor for the incubation?
-- Are they tracking progress in the file
incubator/projects/{project_name}/STATUS
Copyright:
-- Have the papers that transfer rights to the ASF been received?
It is only necessary to transfer rights for the package, the
core code, and any new code produced by the project.
-- Have the files been updated to reflect the new ASF copyright?
Verify distribution rights:
-- For all code included with the distribution that is not under the
Apache license, do we have the right to combine with Apache-licensed
code and redistribute?
-- Is all source code distributed by the project covered by one or more
of the following approved licenses: Apache, BSD, Artistic, MIT/X,
MIT/W3C, MPL 1.1, or something with essentially the same terms?
Establish a list of active committers:
-- Are all active committers in the STATUS file?
-- Do they have accounts on cvs.apache.org?
-- Have they submitted a contributors agreement?
Infrastructure:
-- CVS modules created and committers added to avail file?
-- Mailing lists set up and archived?
-- Problem tracking system (Bugzilla)?
-- Has the project migrated to our infrastructure?
Collaborative Development:
-- Have all
Re: [STATUS] (incubator) Wed Jan 14 23:45:31 EST 2004
Noel J. Bergman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: RoUS wrote in the Incubator STATUS report: o We need to be very very clear about what it takes for a podling to graduate from the incubator. The basic requirements obviously include: has a home, either as part of another ASF project or as a new top-level project of its own; needs to be a credit to the ASF and function well in the ASF framework; ... On the one hand, we still appear to have this as a pending issue. What pending issue? If you'll look a bit further up in my original message, above what you've quoted here, you'll see the heading Pending Issues. In other words, We need to be very very clear about what it takes for a podling to graduate is listed as a Pending Issue, but we seem to be in the process of graduating a podling anyway. I find that a bit odd. -- Martin Cooper On the other hand, we have everyone apparently voting +1 to graduate MerlinDeveloper. Am I alone in feeling that this is a little odd? MerlinDeveloper is an externally developed codebase that is not only going into an existing TLP, it is being merged into an existing effort within that project. The single external developer has already been participating in the community, and was just voted Committer status. The rest of the people working on this effort are already Avalon Committers, and just need permission to import the code. Do you see a problem that has been overlooked? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Re: request for incubation: axion database project
Noel J. Bergman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Rodney Waldhoff wrote: snip/ I don't know what AISI stands for, but the way. For that matter, what's RT stand for in [RT]? AISI == As I See It RT == Random Topic I see RT used on a few lists, I don't consider RT to convey a useful semantic. The first time I saw RT was in a message from Sam (Ruby) on the Gump list, where he expanded it as Random Thought, meaning something along the lines of I just had an idea -- Martin Cooper --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
