RE: Switching incubator.apache.org to svnpubsub?
> -Original Message- > From: Martijn Dashorst [mailto:martijn.dasho...@gmail.com] > Sent: Wednesday, 3 February 2010 5:28 PM > To: general@incubator.apache.org > Subject: Re: Switching incubator.apache.org to svnpubsub? > > +0.9 > > I agree that the site update process is cumbersome, but it also gives > podling folks an incentive to log on to p.a.o and learn to use that > system to their advantage. Moving to svnpubsub would take that away. Only whilst they are podlings. This system is not applied to most TLPs, though they can request it. And I'm betting that every single project that graduates will make that request rather than learn the old cumbersome way. Gav... > > That said, I think that most committers never have to go to p.a.o in > any case so perhaps the point is moot. > > Martijn > > On Wed, Feb 3, 2010 at 7:57 AM, 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* > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.4 increases type safety for web applications > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 > > - > 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?
+0.9 I agree that the site update process is cumbersome, but it also gives podling folks an incentive to log on to p.a.o and learn to use that system to their advantage. Moving to svnpubsub would take that away. That said, I think that most committers never have to go to p.a.o in any case so perhaps the point is moot. Martijn On Wed, Feb 3, 2010 at 7:57 AM, 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* > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - 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?
+1 from me too! Cheers, Tommaso 2010/2/3 Jukka Zitting > Hi, > > On Wed, Feb 3, 2010 at 7:57 AM, Justin Erenkrantz > wrote: > > I'd like to suggest switching incubator.apache.org over to svnpubsub. > > +1! > > BR, > > Jukka Zitting > > - > 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?
Hi, On Wed, Feb 3, 2010 at 7:57 AM, Justin Erenkrantz wrote: > I'd like to suggest switching incubator.apache.org over to svnpubsub. +1! BR, Jukka Zitting - 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 Tue, Feb 2, 2010 at 11:01 PM, Mattmann, Chris A (388J) wrote: > +1 from me on this - I'd see the OODT changes more quickly, right? Indeed! Your note re: OODT is what triggered me to send this email. =P -- justin - 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?
+1 from me on this - I'd see the OODT changes more quickly, right? Cheers, Chris On 2/2/10 10:57 PM, "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* - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Switching incubator.apache.org to svnpubsub?
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* - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator PMC/Board report for February 2010 ("OODT Developers" )
On Tue, Feb 2, 2010 at 8:47 PM, Mattmann, Chris A (388J) wrote: > Thanks Justin! > > I went ahead and updated the incubator site oodt.xml document in > incubator/public/trunk/site-author/projects/oodt.xml with the February 2010 > report based off the wiki: > > http://svn.apache.org/viewvc?rev=905884&view=rev Ooh, good catch. > Is there a command I can run to rebuild the site or is some automated thing? In general, take a look at http://incubator.apache.org/guides/website.html ; The quick-and-dirty guide (should work fine on Mac OS X) is: % % ./build.sh % % svn ci Then: % ssh people.apache.org % cd /www/incubator.apache.org % svn up ...wait at least 1hr for it to appear on http://incubator.apache.org/... If you have any questions, please yell though... =) -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator PMC/Board report for February 2010 ("OODT Developers" )
Thanks Justin! I went ahead and updated the incubator site oodt.xml document in incubator/public/trunk/site-author/projects/oodt.xml with the February 2010 report based off the wiki: http://svn.apache.org/viewvc?rev=905884&view=rev Is there a command I can run to rebuild the site or is some automated thing? Thanks! Cheers, Chris On 2/2/10 8:42 AM, "Justin Erenkrantz" wrote: On Mon, Feb 1, 2010 at 10:41 PM, Mattmann, Chris A (388J) wrote: > Hi All, > > A draft OODT report has been submitted to the Incubator wiki. > Comments/updates from mentors and from the OODT/incubator community are > welcome. Cool - thanks! I made some minor tweaks, so please review. Namely, I shifted the notice about the sw grant from "issues" to the "progress" section. The issues section is primarily for things that we need either Incubator PMC or Board-level assistance in resolving - for example, when we are stuck or need advice further than what the mentors can provide. At this time, I think we're fine - I expect we'll have the lists and such created by the time the report is due. Thanks! -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: [Vote] Release Kato M1-incubating
Thanks Ant and Mark, If someone wouldn't mind looking over the release artifacts and casting a vote, it would be very much appreciated by the Kato podling. Thanks, Stuart Stuart Monteith http://blog.stoo.me.uk On 30 Jan 2010, at 08:29, ant elder wrote: > +1 > > ...ant > > On Fri, Jan 29, 2010 at 4:20 PM, Stuart Monteith wrote: >> The Kato community has voted to release Kato M1-incubating. We now request >> the >> Incubator PMC for a vote. >> >> The proposed release artifacts are located at: >>http://people.apache.org/~monteith/kato/apache-kato-M1-incubating-RC3/ >> >> There are packages for the Java binaries with documentation, source and >> native libaries for Linux and Windows x86. >> Each package is available in tar.gz and zip form, expect for the native >> packages. >> asc, md5 and sha1 (SHA512) files are generated for each. >> >> rat*.txt files have been generated for each of the packages contents. The >> mapping is: >>apache-kat-M1-incubating-bin.(tar.gz|zip) - rat-bin.txt >>apache-kat-M1-incubating-src.(tar.gz|zip) - rat-src.txt >>apache-kat-M1-incubating-native-bin-linux-i386.tar.gz - rat-bin-linux.txt >>apache-kat-M1-incubating-native-bin-windows-i386.zip - >> rat-bin-windows.txt >> >> Please review the artifacts and cast your vote by Thursday 4th February. >> >> >> Thanks in advance, >>Stuart Monteith >> >> -- >> Stuart Monteith >> http://blog.stoo.me.uk/ >> >> >> - >> 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE RESULTS] was: [VOTE] Graduate Apache Cassandra to an Apache TLP
On Thu, 2010-01-28 at 13:59 -0600, Eric Evans wrote: > Please cast your vote: > [ ] +1 to recommend Cassandra's graduation > [ ] 0 don't care > [ ] -1 no, don't recommend yet, (because...) > > The vote will be open for 72 hours. The vote passes with 13 binding +1 votes and no 0 or -1 votes. +1 binding: Niclas Hedhman ant elder Matthias Wessendorf Bertrand Delacretaz Matthieu Riou Matt Hogstrom Paul Fremantle Ian Holsman Alan D. Cabrera Craig L Russell Davanum Srinivas Daniel Kulp Kevan Miller +1 non-binding: Chris Mattmann As I understand it, the next step is to send the proposed resolution to the board for approval. Thanks everyone! -- Eric Evans eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance Question
On Mon, Feb 1, 2010 at 11:47 PM, Niclas Hedhman wrote: > I think this will be promoted now, after the recent license header > issues in another podling... +1 once i have a minute, i planned to drawing up additional policy - robert - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator PMC/Board report for February 2010 ("OODT Developers" )
On Mon, Feb 1, 2010 at 10:41 PM, Mattmann, Chris A (388J) wrote: > Hi All, > > A draft OODT report has been submitted to the Incubator wiki. > Comments/updates from mentors and from the OODT/incubator community are > welcome. Cool - thanks! I made some minor tweaks, so please review. Namely, I shifted the notice about the sw grant from "issues" to the "progress" section. The issues section is primarily for things that we need either Incubator PMC or Board-level assistance in resolving - for example, when we are stuck or need advice further than what the mentors can provide. At this time, I think we're fine - I expect we'll have the lists and such created by the time the report is due. Thanks! -- justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[PROPOSAL] Dalesa P2P Web Cache Project
Hi, We would like to incubate the project Dalesa at Apache incubator and join Apache Software Foundation. You can find the proposal at http://wiki.apache.org/incubator/DalesaProposal. Dalesa is a P2P web cache which could become an alternative to existing centralised web caches like Squid. At the moment we have a released the first release candidate of version 1.0.0. The project web is at http://dalesa.sourceforge.net Full proposal is given below. Thanks, Wathsala - Dalesa Proposal -Abstract Dalesa is a Peer – to – Peer web caching software that provides a caching proxy for web browsers. -Proposal Dalesa is a cooperative web caching software based on peer – to – peer computing. Nodes participating in the network will expose their web caches to the entire system through peer – to – peer web object (document) lookup algorithms. This project focuses on using various group communication technologies such as distributed hash tables and IP multicasting to implement robust document lookup techniques. The system will provide a proxy interface and an API for browsers and other potential user agents. User agents such as web browsers can embed the peer – to – peer lookup algorithm by using the API. However, when changes to the code of the user agent is not allowed or inconvenient the proxy can be used. The system also comes equipped with a web interface for administration and visualization of the data and activities of the corresponding peer – to – peer node. -Background The project was founded by Wathsala Vithanage in January 2009 at Lanka Software Foundation, Sri Lanka. Later Nuwan Gunratna and Nishshanka Sirisena joined the project. Project was funded by Information and Communication Technology Agency of Sri Lanka under eSociety grant for the first year. The system which was developed in C language appeared as a solution to experiment cooperative web caching through peer – to – peer technologies. At the initial stage, developers focused on developing the simplest possible peer – to – peer document lookup algorithm using IP multicasting. Initially, the system was divided into two components; the HTTP caching module and peer – to – peer discovery module. The HTTP caching module performs HTTP request/response processing, cache store management and cache index management. The document lookup module is used for discovering documents (web objects) scattered throughout the network. The core of the system such as HTTP request/response processing, Caching, Multicast based discovery protocol was coded by Wathsala, including Win32 port. Nuwan has also contributed to the discovery protocol. The web based UI is developed by Nishshanka from ground up. -Rationale During last couple of years there has been some research on peer – to – peer web caching technologies, such as Squirrel based on Pastry DHT. However, as of this writing there is no software that implement those concepts, therefore we believe that peer – to – peer caching should come out of it's research cocoon to the main stream computing as free and open source products. Apache has the greatest collection of web related software including the Apache web server with a proven community oriented development model called “Apache Way”. Therefore, we believe that Apache is the ideal place for a free and open source peer – to – peer web cache that will make the web faster. -Initial Goal 1.) Developing a Peer - to - Peer web cache that will be equivalent to a centralized web cache in functionality. 2.)Optimizing the performance, perceived latency of the developed system based on performance measurements. -Current Status As of this writing, the project has a functional system based on IP multicasting. The project progressed for about one year at Lanka Software Foundation where three developers continuously contributed to the project. IP multicasting system should be further improved based on performance data collected from the test bed. At the same time other group communication methods such as various DHTs and application level multicasting can be used for building the peer - to - peer overlay that will become an alternative to the current IP multicasting based system. --Meritocracy Meritocracy is a practice we thrive for. At the moment due to small number of developers and the short duration and novelty of the project this principal is not practiced. However, as we open it for a larger community where different individuals could continuously contribute to the project meritocracy becomes the healthiest and the ideal practice. Therefore, we plan to follow the practice of meritocracy as soon as the code is ready for with it's first release candidate. --Community At the moment the Dalesa community is limited to three individuals as it has just started but we are looking forward to increase this number and grow the community. We believe that Dalesa could easily accomplish
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Sorry for shaking things up, but it sounds like you got the gist of things. Using OSGi services to wire up Chatterbot makes it much more flexible in the long run allowing developers/users to plug in alternative implementations of things if they want to. I'm quite happy to join your project as a committer to help guide this if you wish. :) Not sure about the proposal side of things, I'm sure someone will pipe up soon enough. Cheers, Chris On 1 February 2010 18:39, Donald Whytock wrote: > I had originally thought that Felix Shell would replace Chatterbot > Listener, but I no longer think so. Felix Shell, as far as I can > tell, is focused around Commands that have single outputs directed > toward their originator; Chatterbot Parsers, in a multiuser > environment, might have multiple outputs, and therefore have to > respond in the context of the originator. (v0.2 had writeMsg(target, > message) as well as writeMsgToAllBut(target, message).) On the other > hand, I can see a Parser that acts like a Remote Shell. > > So at this point we're talking about changing the proposal to focus on: > > - Building Chatterbot around Felix as a modularity framework, with its > lifecycle management, its ServiceEvents to resolve dependencies, and > its Service properties to cut down on global datastore space. > > - Building protocol handlers around a more general-purpose interface, > so that they can be used elseproject, then wrapping bundles around > them to make them standard services in a Felix environment for > Chatterbot. > > I think Listener and Sender have to remain, rebuilt as services. > Changes to make Parser a service should leave the parse() method > functionally unchanged. > > The global datastore (I call it the "namespace" in the proposal; I see > now that that conflicts with a term of art) would work best as a > service. I'd like to discuss the Chatterbot Listable class vs. the > standard Dictionary or HashTable classes; Listable allows access to > subsets of the datastore by using a partial key. > > So where do I go from here? A new proposal draft? > > Don > > On Fri, Jan 29, 2010 at 11:05 AM, Richard S. Hall > wrote: > > On 1/29/10 10:38, Donald Whytock wrote: > >> > >> I have an overview of the current Chatterbot architecture at > >> > >> http://www.imtower.net/chatterbot/doku.php?id=overview > >> > >> Chatterbot is different from JMS inasmuch as it's currently built to > >> receive messages from chat IDs and turn them into messages from > >> Chatterbot-internal IDs, and vice versa. My intent was to allow > >> multiple chat IDs (same protocol or different protocols) to translate > >> into a single Chatterbot ID, so that a user could choose how he > >> accessed the bot. Which protocol a message comes in over should be > >> totally transparent to the Parsers, and the Parsers should be able to > >> send messages out using Chatterbot IDs and not worry what protocol is > >> used to deliver them. > >> > >> Looking briefly over Felix (http://felix.apache.org), I'd say the > >> Chatterbot Listener and Parsers would be equivalent to the Felix Shell > >> and Commands, if the Shell was fed a JMS stream consolidated from > >> multiple message streams, and if its output was then dispersed over > >> multple message streams. Though there would also need to be a way to > >> set up a Command to respond to any input string, rather than one > >> starting with a particular word. > >> > > > > Just to be clear, there are two shells at Felix: > > > >http://felix.apache.org/site/apache-felix-shell.html > > > > And > > > >http://felix.apache.org/site/apache-felix-gogo.html > > > > Although they basically do the same thing, I think Christopher was > referring > > to the latter shell, which is more sophisticated than the former and may > > eventually become and OSGi standard. > > > > -> richard > > > >> Chatterbot Parsers also have the capacity to originate messages to > >> users other than the one whose message the Parsers are responding to, > >> so that they can serve as chatrooms; this would be the equivalent of > >> Felix sending out notifications to other users when a given user > >> performed a command. Would this compare to Felix Event Admin? > >> > >> That pretty much just leaves the global namespace, which is > >> essentially volatile JDO. This is where the Chatterbot IDs are stored > >> and the Modules are defined; it gets updated by Channels, and can be > >> referenced and updated by Parsers. I've implemented that as a TreeSet > >> of TreeSets, due to the key structure, but of course the internal > >> structure of the namespace is largely transparent to the modules. > >> > >> So all in all I'd say there's no inherent barrier to building > >> Chatterbot with Felix. Especially if it'll still run off my USB > >> drive. > >> > >> Don > >> > >> On Fri, Jan 29, 2010 at 3:44 AM, Christopher Brind > > >> wrote: > >> > >>> > >>> Hi, > >>> > >>> I have read through the proposal and I like the idea of it. > >
