Re: You know what... Apache is just too complicated.
On Tue, May 19, 2015 at 12:08 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Tue, May 19, 2015 at 7:43 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: If someone wants to write a 12 steps to becoming an Apache top-level project that might become the single-page Incubator website ;-) Isn't it 1 step nowadays? ;-) Yes, but there's 12 different versions of it. Don
Re: [PROPOSAL] Silk as new Incubator project
On Fri, Sep 19, 2014 at 12:57 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Fri, Sep 19, 2014 at 8:36 AM, Christian Grobmeier grobme...@gmail.com wrote: Not saying anything on the proposal itself, I would be concerned because of the name Silk. There is this: http://lucidworks.com/product/integrations/silk/ which is related to Apache Solr and Lucene and also gets some attention. While it may not solve the same thing, I wouldn't use the name Silk at least because it somehow works with other Apache products. It could lead to confusion. If the podling is accepted, I suggest to consider this before resources are created Yup. Hence the following set of potential names: * Apache Silk (preferable name) * Apache Sylk * Apache Memstor * Apache Ignite It would be very useful if we can get feedback on the most/least pref. ones from that list. Memstor is a trademark in the US: http://www.kingleetech.com/membrane-chemicals/additional-products/membrane-storage-products/memstor I'd actually wondered about Membrain, but that's a different chemical product. Sylk is an adult product whose URL I'm not visiting at the office. I'd think Ignite is a standard-enough English word that no one could reasonably claim exclusivity (but IANAL). Don
Re: [PROPOSAL] Weave for Apache Incubator
Knit, crochet, macrame? Though, honestly, pulling lower-level components together into higher-level ones sounds a little like granny squares... Don On Wed, Oct 30, 2013 at 1:53 AM, Andreas Neumann a...@apache.org wrote: Pardon my ignorance, I just looked it up and realized that warp and weft are indeed related to weaving, so they might work. I do have the impression, though, that most people would associate Warp with the speed of light and not with weaving. -Andreas. On Wed, Oct 30, 2013 at 1:41 AM, Andreas Neumann a...@apache.org wrote: Thanks for pointing out these similarities; we were not aware of Commons Weaver. Given that Weaver is a sub-project of Commons, would the similarity be tolerable? Also, since Weave and Wave are pronounced quite differently, I am hoping that they are perceived as different enough. The name Weave is motivated from the name of YARN - it takes the complexity out of yarn by weaving it into a simple pattern. Warp and Weft don't really convey this meaning. If the concern about the name similarity is really strong, we will try to find another name, and we are open to suggestions. But please do also consider the motivation for this naming. Thanks On Tue, Oct 29, 2013 at 7:54 PM, sebb seb...@gmail.com wrote: In which case, maybe consider the related words: Apache Warp Apache Weft Just a thought. On 29 October 2013 22:14, Upayavira u...@odoko.co.uk wrote: And Apache Wave too (which is what I first saw before I read the title more carefully). Upayavira On Tue, Oct 29, 2013, at 09:12 PM, Matt Benson wrote: Hi, I am concerned about potential confusion with Apache Commons Weaver [1]. Matt [1] https://commons.apache.org/proper/commons-weaver/ On Tue, Oct 29, 2013 at 2:53 PM, Andreas Neumann a...@apache.org wrote: I would like to propose Weave, an abstraction over Apache Hadoop® YARN to reduce the complexity of developing distributed applications, as an Apache Incubator podling. The proposal is included in plain text. I would also like to put this on the wiki, but I appear to lack privileges to create pages. What do I need to do to get permission? -Andreas. Abstract Weave is an abstraction over Apache Hadoop® YARN that reduces the complexity of developing distributed applications, allowing developers to focus more on their business logic. Proposal Weave is a set of libraries that reduces the complexity of developing distributed applications. It exposes the distributed capabilities of Apache Hadoop® YARN via a simple and intuitive programming model similar to Java threads. Weave also has built-in capabilities required by many distributed applications, such as real-time application logs and metrics collection, application lifecycle management, and network service discovery. Background == Hadoop YARN is a generic cluster resource manager that supports any type of distributed application. However, YARN’s interfaces are too low level for rapid application development. It requires a great deal of boilerplate code even for a simple application, creating a high ramp up cost that can turn developers away. Weave is designed to improve this situation with a programming model that makes running distributed applications as easy as running Java threads. With the abstraction provided by Weave, applications can be executed in process threads during development and unit testing and then be deployed to a YARN cluster without any modifications. Weave also has built-in support for real-time application logs and metrics collection, delegation token renewal, application lifecycle management, and network service discovery. This greatly reduces the pain that developers face when developing, debugging, deploying and monitoring distributed applications. Weave is not a replacement for YARN, it’s a framework that operates on top of YARN. Rationale = Developers who write YARN applications typically find themselves implementing the same (or similar) boilerplate code over and over again for every application. It makes sense to distill this common code into a reusable set of libraries that is perpetually maintained and improved by a diverse community of developers. Weave’s simple thread-like programming model will enable many Java programmers to develop distributed applications. We believe that this simplicity will attract developers who would otherwise be discouraged by complexity, and many new use cases will emerge for the usage of YARN. Incubating Weave as an Apache project makes sense because Weave is a framework built on top of
Re: [PROPOSAL] Aurora for Incubation
Hi Dave... So Aurora already exists as a functioning package? Is there a public-accessible project page for it somewhere? Don On Tue, Aug 27, 2013 at 4:20 PM, Dave Lester d...@ischool.berkeley.eduwrote: Hi Jean-Baptiste, The focus is currently on Mesos. Our intent is to make it a sub-project. Dave On Mon, Aug 26, 2013 at 11:52 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi guys, the proposal is interesting. Quick question: do you plan to focus only on Mesos, or create a kind of more global and standalone job scheduler ? Regards JB On 08/27/2013 12:27 AM, Dave Lester wrote: Hi All, We're pleased to share a draft ASF incubation proposal for Aurora, a service scheduler used to schedule jobs onto Apache Mesos that we've developed at Twitter. Aurora provides all of the primitives necessary to quickly deploy and scale stateless and fault tolerant services in a datacenter. The complete proposal can be found: https://wiki.apache.org/**incubator/AuroraProposal https://wiki.apache.org/incubator/AuroraProposal, and also pasted below. In particular, we'd love to add additional mentors to the project. Your feedback is appreciated. Dave
Re: Instead of a Bill how about a Booklet? (was Re: [DISCUSS] PodlingBillOfRights)
On Thu, Jun 20, 2013 at 12:22 PM, Alex Harui aha...@adobe.com wrote: 2) Apache has been around long enough and is large enough to have its own culture, with its own societal rules and tribal history. Lots of it is written down, but it is hard to find. I never thought of that...Apache policy is the written equivalent of oral history. Don
Re: [PROPOSAL] Curator for the Apache Incubator
On Mon, Feb 25, 2013 at 8:14 PM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: == Source and Intellectual Property Submission Plan == * The initial source is already licensed under the Apache License, Version 2.0. https://github.com/Netflix/curator/blob/master/LICENSE.txt So this is effectively a fork of the Netflix version? Or will Netflix be making an official transfer, a la OpenOffice? Will there be any issues with using the name Curator? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Curator for the Apache Incubator
On Tue, Feb 26, 2013 at 3:36 PM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: It will be an official transfer. Apache will get all the code and the name Curator. -JZ On Feb 26, 2013, at 12:31 PM, Donald Whytock dwhyt...@gmail.com wrote: On Mon, Feb 25, 2013 at 8:14 PM, Jordan Zimmerman jor...@jordanzimmerman.com wrote: == Source and Intellectual Property Submission Plan == * The initial source is already licensed under the Apache License, Version 2.0. https://github.com/Netflix/curator/blob/master/LICENSE.txt So this is effectively a fork of the Netflix version? Or will Netflix be making an official transfer, a la OpenOffice? Will there be any issues with using the name Curator? Don Okay. Might want to add that to the IP Submission Plan section. Not a deal-breaker on the proposal IMO, but something to keep track of for graduation. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Steams Project
On Tue, Nov 6, 2012 at 12:06 PM, Franklin, Matthew B. mfrank...@mitre.org wrote: Apache Streams Proposal == Proposal == Apache Streams will bring together individuals who are or are looking to increase and centralize the production, consumption and federation of ActivityStreams throughout enterprise organizations and the Internet as a whole. The target features include: * Publication of Activities from multiple systems via HTTP * Aggregation and syndication of streams * Support for security trimming of streams by social graph * Noise reduction and intelligent filtering * Federation of streams across disparate systems * Provide libraries for easy integration in source systems Do you see this project working at all with Apache Camel? Camel provides tools for aggregating from multiple sources into single streams. Perhaps developing Camel endpoint drivers for ActivityStreams would be useful? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Mayhem proposal
Just giving a post-hurricane nudge. On Tue, Oct 30, 2012 at 11:49 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I prepared a new proposal[1] for the incubator, concerning the creation of a new community focused on all aspects of Google Guice extensions, starting from a rather than small codebase that I and other friends - already ASF committers/members - would like to donate to the ASF. We still need at least one mentor, is there any volunteer available on joining to provide help on bringing that new community up? Many thanks in advance, all the best!!! -Simo [1] http://wiki.apache.org/incubator/MayhemProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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
Re: [PROPOSAL] Allura Proposal
On Mon, Jun 18, 2012 at 5:00 PM, Ross Gardler rgard...@opendirective.com wrote: Under reliance on salaried developers the proposal states At present, almost all development on Allura is done on salaried time. It is understood that expanding the developer community to the point where this is not the case, is a goal of incubation. This isn't quite accurate. We don't have a problem with salaried time, we only worry about single sources of salaried time. I've taken the liberty (as a mentor) to change it to At present, almost all development on Allura is done on salaried time ***from a single company***. It is understood that expanding the developer community to the point where this is not the case, is a goal of incubation. Ross FWIW, they're worried about single sources of unsalaried time too. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] cTAKES for the Apache Incubator
Hi Pei, A lot of the components listed in the proposal and the Wikipedia entry look useful for general natural language processing, not just clinical-data processing. Is it possible to use cTAKES for general, non-clinical processing? Or is it built on a general core with clinical-data-related extensions? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: CloudStack?
From the article: CloudStack brings to Apache more than 30,000 community members, thousands of certified apps, and hundreds of production clouds. And to think, people were worried about OpenOffice... Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][RFC] CloudStack for the Apache Incubator
Regarding the section Source and Intellectual Property Submission Plan...What do the patents cover/restrict? Is a patent even compatible with ALv2? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][RFC] CloudStack for the Apache Incubator
On Tue, Apr 3, 2012 at 3:06 PM, David Nalley da...@cloudstack.org wrote: On Tue, Apr 3, 2012 at 2:09 PM, Donald Whytock dwhyt...@gmail.com wrote: Plan...What do the patents cover/restrict? Is a patent even compatible with ALv2? Speaking only for myself, Section 3 of ALv2 seems to address patents held by contributors. Or am I misunderstanding the concern around patents? No, if I'm reading ALv2 section 3 right, that essentially says people that use the ALv2-licensed material are granted the right to use the material in the same way that they would if the contributor of the material had a patent on it and granted license to that patent. The proposal, on the other hand, says Citrix has filed for patents on the material they're donating and will continue to do so. I'm wondering what they think the patents are intended to accomplish if, by the ALv2 license, just about anyone is permitted to do just about anything with the code. Don (who INAL) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator, or Incubation?
Isn't there also something along the lines of what's called culpable deniability? Since podlings may be in states where their offerings might not be as legal as TLPs (licensing issues, trademark/branding issues, etc.), is it not more convenient for them to be relegated to an area specifically designated as not officially supported? This is very clearly demarked by a subdomain and a subproject, and if there's to be a subdomain and a subproject it makes sense that there are people specifically managing them. I submit that the IPMC is an effect of the incubator rather than a cause. I think the mechanisms need to be in place so that not-yet-legal projects can exist and work on becoming legal projects, and that it's just as well that staff exists to manage them. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
May I suggest bumping thoughts of cashiering the incubator to its own thread? It seems a much bigger question than whether to prevent vetoes on PPMC membership votes. Don On Tue, Jan 31, 2012 at 6:21 PM, William A. Rowe Jr. wr...@apache.org wrote: On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote: In replacement, I propose the following concrete actions: 1. Move the Incubator process/policy/documentation, etc., to ComDev - I agree with gstein on this. I think it could be maintained by the ASF community folks there, and updated over time. But it's not vastly or rapidly changing really anymore. 2. Discharge the Incubator PMC and the role of Incubator VP -- pat everyone on the back, go have a beer, watch the big game together, whatever. Call it a success, not a failure. 3. Suggest at the board level that an Incubation process still exists at Apache, in the same way that it exists today. New projects write a proposal, the proposal is VOTEd on by the board at the board's next monthly meeting, and those that cannot be are QUEUED for the next meeting, or VOTEd on during out of board inbetween time on board@. Refer those wanting to Incubate at Apache to the existing Incubator documentation maintained by the ComDev community. Tell them to ask questions there, about the process, about what to do, or if ideas make sense. But *not* to VOTE on whether they are accepted or not. Note that at the time the incubator was created, there was no particular process. Projects entered the ASF helter-skelter, without really following any template. Also, the legal committee was not a resource, comdev was not a resource, trademarks was not a resource, press was not a resource. I think it's sort of silly to suggest that resource needs are completely isolated to either incubating efforts, or TLP efforts. So the question is, what does the incubator provide today that should be persisted as a resource to any incubating or full project? Obviously, mentorship; but comdev seems like a really good home for that. - 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: [RT] Community over policy, and similar thoughts
Fair enough. I used to run into this in high school, where something that had been done the year before a freshman came in was suddenly a tradition that had to be done every year. You could probably compare it to Terry Pratchett's senior mayfly (It's way too bright around here now. Not like it was in the good ol' hours.).[1] There still needs to be something one can bootstrap a community with. Oral tradition is a wonderful thing, make it up as you go is very liberating, but some people work really really well with checklists and flowcharts. Something somewhere should say, If you don't do anything else, you at least have to do this. Perhaps break it down into must, should, and worked before. Don [1] http://en.wikipedia.org/wiki/Reaper_Man - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RT] Community over policy, and similar thoughts
Like Apache, But Sexier...LABS? I can totally see that. Anyone want to start an Apache LABS podling? I'm speaking as someone who lurks on a few prodling lists, plus the incubator. There's stuff I've picked up sort of by osmosis (absorbing through membranes and the skin, rather like how one learns in a college class by falling asleep on one's book), stuff I assume from what I perceive as the nature of the beast, and stuff I may well be dead wrong about. I like what you've said about community. I appreciate the idea of community over policy, community over bureaucracy, people over rules. Having said that...My understanding is that Apache is a legal entity. It has a registered life and purpose. It has assets, both tangible and non-tangible. It receives assets and distributes assets. And it does this, in cooperation with governments and financial institutions, by following specific rules. Rules that have to be followed so that various other legal entities, not limited to governments and financial institutions, don't take the assets away from it. I'm not sure, but I believe accepting contributions from people incurs certain rules in and of itself, along the lines of, We will use the assets you transfer to us in such-and-such a way. You can trust us when we say that. I assume that to use assets for something other than what one says when one asks for them constitutes misrepresentation and can lead to civil incivility. Because of this, Apache has a duty to require that these rules be followed by people that Apache invites to participate in activities voluntarily. On the one hand, there are Ts that have to be crossed and Is that require a pixel or two over them. On the other hand, if people don't want to participate, for whatever reason (duty, fun, ego, a drive to participate in something bigger than oneself), they're not going to. It has to be hard to deal with both of these things at the same time. I think I've seen The Apache Way used to describe both rule adherence and social curling[1], though not typically in the same sentence. Depending on the person, one or the other may make more sense. Some people may be more bureaucractically sensitive, others may be more community savvy. Both people will, in response to a What do I do now? query, present their answers as they see them. These answers may seem contradictory, but nevertheless represent answers that need to be taken together. But while community can be flexible in a lot of ways, policy generally can't be. The rules are there; exceptions can be made, but in terms of law it's generally safer to assume they won't be. So, as much as I hate to say it, I don't think community over policy can actually work. Community within policy, or community in the context of policy, perhaps. But the policy kindasorta has to be there. It has to be visible, and it has to be explained. And in some cases someone might actually have to explain what a T is, and how it can be crossed. I look forward to being proven wrong. Don [1] http://en.wikipedia.org/wiki/Curling - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 10, 2012 at 2:49 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: It is not helpful to have a number of directors contradicting each other on general@, never coming to consensus. In fact, its maddening. I'm actually not seeing much in the way of contradiction in discussion of the policy. The letter seems to be: Apache projects don't import and incorporate code without the owners' consent. License to use is not synonymous with consent to import. The spirit seems to be: It is terminally rude to try to form an Apache project by ripping up an existing community without its consent. Most of the Apache people commenting here seem to agree on these things. Most of the argument on this thread seems to have been about whether or not they apply to Bloodhound. Bloodhound notwithstanding, there's probably enough practical clarification here to put up on a page somewhere, with a link from the main policy page saying, For a discussion of the issues, click here. But perhaps I'm naive. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
It occurs to me that the ASF, in enforcing open-source licensing, becomes a source of free legal advice to the open-source community, whether it intends to or not... 1. Contribute a body of code to ASF. 2. Is it legal for us to accept this? Better run it past legal@. 3. Use acceptance of the contribution as certification that it can be used by the contributor. Just sayin'. Not sure if this is a good thing or a bad thing. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Flex for Apache Incubator
A minor comment on one sentence... To that end, Adobe will only have minority representation on the initial committers list. As I understand it, companies don't have representation in Apache projects. Individuals do, that may or may not belong to a given company, and that may or may not be operating with their employer's backing. It'll be good to have participation by people with access to the resources of the original contributors. But it's participation by people. Whether or not those people represent Adobe is between Adobe and them. Just so Adobe understands that's a consequence of the code grant. Looks interesting, though. Given AOO, is this suggesting a trend of major companies transferring code and communities to Apache? Don On Mon, Dec 19, 2011 at 3:20 PM, Alex Harui aha...@adobe.com wrote: Hi everyone, I would like to propose Flex to be an Apache Incubator project. Here's a link to the proposal: http://wiki.apache.org/incubator/FlexProposal Thank you, Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - 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: Actively retiring projects (was: Incubator Board Report November 2011)
On Wed, Nov 16, 2011 at 8:27 PM, Benson Margulies bimargul...@gmail.com wrote: I can see two problems with this view to begin with. One is IP management. The more people participate in a project and the longer they do so, the messier it becomes to track provenance and get ICLAs from all of the contributors. One almost wishes that the ASF could accept ICLAs and code grants for code that is in fact living somewhere else. I'm sure someone will tell me why that idea is nuts. Well, if the code is living somewhere else, that means the code in ASF would be taking up space for possibly no good reason, as people might more habitually go to where the code is living. On the other hand, the ASF could theoretically act as a last line of defense against system failure, community dissolution, sociopolitically-motivated bogus forking, etc., in that if all else fails people can go to Apache to get a stable release of something. I'm sorry...was that a rhetorical question? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Establishing New Committers
On Fri, Nov 4, 2011 at 5:32 AM, Ross Gardler rgard...@opendirective.com wrote: You use the phrase committ rights in this template. They are not rights they are privileges. The reason this might be important is that very occasionally it is necessary for a PMC to remove these privileges, it is one of the few blunt instruments available for solving community issues that have got out of hand. Another way that privileges is better is that commits, as I understand it, can be -1'ed away if necessary. A right to commit might imply more permanence than actually exists. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: podlings.xml - field to hold details of non-current podlings
On Thu, Oct 20, 2011 at 6:06 AM, sebb seb...@gmail.com wrote: In some cases, a URL might be relevant for retired projects; this could be added as an attribute of the foo tag Is it at all possible that a current podling would have a nonstandard URL? I'm wondering if the URL attribute should be at the podling level, where it could, if needed, be used for current projects as well as non-current ones. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling status summary - expand details for graduated/retired/dormant projects?
So...a url attribute that takes precedence when present, otherwise the link is derived from the podling name? Or should the url attribute be default-filled for all cases? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling status summary - expand details for graduated/retired/dormant projects?
Right, but unless the podling changes its name on graduation it's still going to be relatively standard, right? project.apache.org vs incubator.apache.org/project? Since I still have the script handy, shall I kick out a new podlings.xml, with a url attribute pre-filled using the above for current and/or graduated podlings? Something that can be changed manually? On Thu, Oct 13, 2011 at 11:19 AM, sebb seb...@gmail.com wrote: On 13 October 2011 16:00, Donald Whytock dwhyt...@gmail.com wrote: So...a url attribute that takes precedence when present, otherwise the link is derived from the podling name? Or should the url attribute be default-filled for all cases? No, the URL I referred to would only apply to *non-current* podlings. The URL would point to the new TLP or 3rd party site. It's not derivable from any existing information. - 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
Re: [SITE] Split projects/index.html
On Tue, Oct 11, 2011 at 10:50 AM, sebb seb...@gmail.com wrote: If it's important to have a single page that contains all the podling names ever used for searching purposes, then we could create a simplified version of podlings.xml, with links to more detailed entries. Does it make sense for the details such as description and mentors to be pushed out to site-author/projects/podling.xml, and pages to be generated from time to time from a compilation of the podling files and a simplified podlings.xml? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Layout change - remove the right table
On Mon, Oct 10, 2011 at 10:58 AM, Christian Grobmeier grobme...@gmail.com wrote: Ok, for you. Not me. I believe people coming from outside are confused by this navigation too. Of course I cannot prove it, but all the website I like have easier navigation. So what's the use case for the RHS column? Presumably it's to quickly navigate to a project of interest, which is good if you know what you're looking for. But then, if you know what you're looking for, you also know it's at incubator.apache.org/whatyou'relookingfor. If you don't know what you're looking for, a list of names may not be as useful as, say, the actual podlings list page which has descriptions along with the names. Mostly it would seem useful if you *almost* know what you're looking for...What was the name of that podling again...? Well, let's go to incubator.apache.org and...Oh, of course. Chukwa. So which of these is best served by the presence of the column, and is that a frequently-enough-occurring need to demand the column? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] podling-info.xml (was: Layout change - remove the right table)
There's been talk on the OpenOffice dev list about a public list of PPMC members. Now that there's an overall podlings.xml registery, should there perhaps be a standard for something similar at the podling level, that a general script can use if it's there? Perhaps something along the lines of incubator.apache.org/podling/podling-info.xml, that could contain lists of PPMC members, committers, other info. Some of this could possibly be automatically generated from security lists and mailing list membership. The file, if it exists, could be read by something building a podling page from a template. Thoughts? Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] podling-info.xml (was: Layout change - remove the right table)
On Mon, Oct 10, 2011 at 2:35 PM, Christian Grobmeier grobme...@gmail.com wrote: There is always: http://people.apache.org/committers-by-project.html#ooo This isn't necessarily the same as the members of the PPMC, is it? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Layout change - remove the right table
On Fri, Oct 7, 2011 at 5:10 PM, sebb seb...@gmail.com wrote: However I think it would make sense to sort the entries by podling name, rather than by name within status. Otherwise it will be a pain when the status changes. Also, rather than use a website tag, I think it would be better to use a tag which is the podling identity name (or whatever we call it). For most podlings, this is just the name in lower-case, however there are some exceptions that currently have to be hard-coded in clutch.py. It's then easier to use the value to create the website and in other cases. Okay, so sorted by podling name, and instead of a website you'd like an id field that URLs and the like would be generated from? I can kick that out this evening. Would it be desirable for this to be in a database? Does Infra run a DBMS? Either way, we can start with the XML. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Layout change - remove the right table
On Fri, Oct 7, 2011 at 6:48 PM, sebb seb...@gmail.com wrote: I'm now thinking it might be better to convert some of the tags to attributes, for example: podling name=Accumulo resource=accumulo status=current These are all relatively short fields and I think it would make the file shorter and easier to read. I used resource rather than id because that seems to be what clutch uses. podlings podling name=name resource=resource status=status startdate=startdate [enddate=enddate] description description /description mentors mentormentor/mentor /mentors /podling podlings Look good? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Layout change - remove the right table
On Fri, Oct 7, 2011 at 9:08 PM, sebb seb...@gmail.com wrote: It would be easier to edit and navigate if the attributes were all on the same line as the podling tag Yeah, that's the plan. I was just listing what attributes would be there. I format the final file using XPontus. I forgot sponsor, BTW; that'll be in there. What do we do with projects such as Manifold Connector Framework (ManifoldCF) ? That name is too long for a navigation list and probably some other places. Perhaps we need two types of name. Probably better to use the short name by default, and allow the long name to be used in some places. In that case, we would need to add an optional longName or fullName attribute. Okay. Likewise, what about Tapestry? It has a nonstandard resource: http://jakarta.apache.org/tapestry/ Optional website attribute? I'm generating these with a PHP script that uses a chopped version of the podlings page as an XML source. Single-item special cases will have to be manual for now. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Layout change - remove the right table
On Thu, Oct 6, 2011 at 6:46 AM, sebb seb...@gmail.com wrote: The registry would contain all podling names (current and previous) together with state (active, dormant, graduated, retired) and other basic information. This would be used to generate the podling summary page(s) as well. Would said XML file then be manually edited? Or could, say, a PHP app be set up for making changes to it? Where would it reside? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Layout change - remove the right table
What about storing the podling names in a table somewhere and using a Javascript fragment to read the table and populate the right-column list? Pages that include the script therefore don't have to be updated at all when the podling list changes. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance - transferral or licensing of copyright ownership?
On Wed, Sep 21, 2011 at 5:27 AM, Sander van der Waal sander.vanderw...@oucs.ox.ac.uk wrote: On the other hand, the ASF general FAQ states that the copyright of ASF projects is owned by the ASF, more specifically The members own the code [5]. Also the IP Clearance template [6] has a check that says Check and make sure that the papers that transfer rights to the ASF been received. But it seems that the SGA and *CLAs are just license agreements and don't include a transferral of rights? I must be missing something obvious here but I'm not sure what. [5] http://www.apache.org/foundation/faq.html#who-owns-apache-code [6] http://incubator.apache.org/ip-clearance/ip-clearance-template.html ianal Actually, [5] says, All software developed within the Foundation belongs to the ASF, and therefore the members. Software contributed to the ASF would not, I would think, count as developed within. On the other hand, code contributed through the SGA conveys a non-exclusive, worldwide, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense, internally and externally, the Software. [6] I would think that this means the moment ASF makes any change at all to a contribution -- including adding an ASF copyright notice -- that makes it a derivative work, developed within the ASF, and therefore belonging to its members. And the spirit of the SGA seems to sufficiently express this that people contributing under the SGA thereby express consent for it to happen. The only time this would not be the case is if the contributor is contributing something he has no right to so contribute. That isn't a fault of the SGA. /ianal Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance - transferral or licensing of copyright ownership?
Apologies...shouldn't have cited [6]. Meant to cite [2]: [2] http://www.apache.org/licenses/software-grant.txt Good thing IANAL. Don On Wed, Sep 21, 2011 at 12:30 PM, Donald Whytock dwhyt...@gmail.com wrote: On Wed, Sep 21, 2011 at 5:27 AM, Sander van der Waal sander.vanderw...@oucs.ox.ac.uk wrote: On the other hand, the ASF general FAQ states that the copyright of ASF projects is owned by the ASF, more specifically The members own the code [5]. Also the IP Clearance template [6] has a check that says Check and make sure that the papers that transfer rights to the ASF been received. But it seems that the SGA and *CLAs are just license agreements and don't include a transferral of rights? I must be missing something obvious here but I'm not sure what. [5] http://www.apache.org/foundation/faq.html#who-owns-apache-code [6] http://incubator.apache.org/ip-clearance/ip-clearance-template.html ianal Actually, [5] says, All software developed within the Foundation belongs to the ASF, and therefore the members. Software contributed to the ASF would not, I would think, count as developed within. On the other hand, code contributed through the SGA conveys a non-exclusive, worldwide, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense, internally and externally, the Software. [6] I would think that this means the moment ASF makes any change at all to a contribution -- including adding an ASF copyright notice -- that makes it a derivative work, developed within the ASF, and therefore belonging to its members. And the spirit of the SGA seems to sufficiently express this that people contributing under the SGA thereby express consent for it to happen. The only time this would not be the case is if the contributor is contributing something he has no right to so contribute. That isn't a fault of the SGA. /ianal Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Bluesky calls for a new mentor!
On Fri, Jul 1, 2011 at 5:04 PM, Gavin McDonald ga...@16degrees.com.au wrote: Are we to keep on creating new committer accts for these folks knowing damn well that at the end of the term they disappear and a new lot appears? This is why they ( when they did commit) shared accounts. What if the students all served as contributors rather than committers, with a core of committers that handled the contributions? As long as a contribution is made to a JIRA, and said contribution was flagged as being released to ASF, that should ensure clean IP, right? Of course, that's presupposing all the code is maintained publicly from now on. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: process for going Dormant/Retired
Should there be a way to comment on the dormant podling? Perhaps analysis on what (over and above community, the core problem) would be required to make the project viable, in case anyone who has the time and interest and expertise (i.e. someone other than, say, me) wanted to try to revive it? Don On Fri, Jun 17, 2011 at 5:09 AM, Henri Yandell flame...@gmail.com wrote: On Fri, Jun 17, 2011 at 2:04 AM, Henri Yandell flame...@gmail.com wrote: On Wed, Jun 15, 2011 at 7:11 PM, David Crossley cross...@apache.org wrote: David Crossley wrote: Christian Grobmeier wrote: I would like to propose Dormant or Retired status for the alois project - not sure what is more matching or what the difference between these two is. Unfortunately I have not found any docs about this process. I suggest search the mail lists for past similar situations. We did have a recent discussion too about the process. IIRC, the Leo Simons was very helpful. Clutch provides some links: http://incubator.apache.org/clutch.html#h-Retire However there is more involved. When we find/create/enhance some docs, we can add to those pointers. Ah yes, one of those links goes to INCUBATOR-100 Giving this discussion a new name and linking from JIRA. Also, is there a retired-podlings url that the Attic can link to? Some additional thoughts after reviewing the Bluesky thread. Generally the Attic process should be followed for retired podlings; things like making svn, JIRA etc read-only, updating the podling website with a bold notice that the podling is retired and making the announcement. Also a FAQ item from the bluesky thread: What happens to a dormant podling? Are its files still accessible, and does its licensing still apply? I'd guess that the files remain accessible. However... Please use unreleased code, especially from the Incubator, with extreme care. Nobody, especially not the ASF, will grant for it. We really want to be strong on that 'not vouched for' point. I think we also should think about the question of whether we keep source that wasn't able to check off its IP checklist items. We've got strong podlings (JSPWiki springs to mind) where these haven't been checked off yet - I think the Incubator PMC should push very strongly on podlings to sort out their copyright early instead of letting it linger. Perhaps even put in place some timelines 'sort it out in 3 months' etc. Hen - 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: Bluesky status and plans (was: Monthly reports missing)
What happens to a dormant podling? Are its files still accessible, and does its licensing still apply? Don On Tue, Jun 14, 2011 at 12:21 PM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Jun 14, 2011 at 7:38 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Tue, Jun 14, 2011 at 16:15, Noel J. Bergman n...@devtech.com wrote: We can take that up with the community. They've certainly had their struggles, but seem to come back sporadically. --- Noel -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com]On Behalf Of Sam Ruby Sent: Tuesday, June 14, 2011 6:49 To: general@incubator.apache.org Subject: Bluesky status and plans (was: Monthly reports missing) On Tue, Jun 14, 2011 at 12:58 AM, Noel J. Bergman n...@devtech.com wrote: I know that it is early (as in the earliest that the meeting could possibly happen), but we're late. BeanValidation, Bluesky, Isis, and Wave are all missing from the Wiki. Bluesky entered incubation nearly three and half years ago. It is time to decide that incubation is not going to succeed for this podling? I've been following the mailing list for a while now and I don't see any progress towards what could become an Apache project eventually. Bernd +1, At the beginning I was really trying to help and be a non-official mentor for the Bluesky podling and I now tend to agree with Bernd that no really progress has been made and I don't see that changing in the near/medium future. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 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: [VOTE] Accept OpenOffice.org for incubation
+1 (non-binding) On Fri, Jun 10, 2011 at 2:33 PM, Yegor Kozlov yegor.koz...@dinom.ru wrote: +1 On Fri, Jun 10, 2011 at 8:02 PM, Sam Ruby ru...@intertwingly.net wrote: *** Please change your Subject: line for any [DISCUSSION] of this [VOTE] As the discussions on the OpenOfficeProposal threads seem to be winding down, I would like to initiate the vote to accept OpenOffice.org as an Apache Incubator project. At the end of this mail, I've put a copy of the current proposal. Here is a link to the document in the wiki: http://wiki.apache.org/incubator/OpenOfficeProposal?action=recallrev=207 As the proposal discussion threads are numerous, I encourage people to scan and review the archives for this month: http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/browser Please cast your votes: [ ] +1 Accept OpenOffice.org for incubation [ ] +0 Indifferent to OpenOffice.org incubation [ ] -1 Reject OpenOffice.org for incubation This vote will close 72 hours from now. - Sam Ruby = OpenOffice.org - An open productivity environment = == Abstract == !OpenOffice.org is comprised of six personal productivity applications: a word processor (and its web-authoring component), spreadsheet, presentation graphics, drawing, equation editor, and database. !OpenOffice.org is released on Windows, Solaris, Linux and Macintosh operation systems, with more [[http://porting.openoffice.org/|communities]] joining, including a mature [[http://porting.openoffice.org/freebsd/|FreeBSD port]]. !OpenOffice.org is localized, supporting over 110 languages worldwide. == Proposal == Apache !OpenOffice.org will continue the mission pursued by the !OpenOffice.org project while under the sponsorship of Sun and Oracle, namely: To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format. In addition to to building the !OpenOffice.org product, as an end-user facing product with many existing individual and corporate users, this project will also be active in supporting end-users via tutorials, user forums, document template repositories, etc. The project will also work to further enable !OpenOffice.org to be used as a programmable module in document automation scenarios. == Background == !OpenOffice.org was launched as an open source project by Sun Microsystems in June 2000. !OpenOffice.org was originally developed under the name of StarOffice by Star Division, a German company, which was acquired by Sun Microsystems in 1999. Sun released this as open source in 2000. !OpenOffice.org is the leading alternative to MS-Office available. Its most recent major version, the 3.x series saw over [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|100 million downloads]] in its first year. The [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|most recent estimates]] suggest a market share on the order of 8-15%. The !OpenOffice source is written in C++ and delivers language-neutral and scriptable functionality. This source technology introduces the next-stage architecture, allowing use of the suite elements as separate applications or as embedded components in other applications. Numerous other features are also present including XML-based file formats based on the vendor-neutral !OpenDocument Format (ODF) standard from OASIS and other resources. == Rationale == !OpenOffice.org core development would continue at Apache following the contribution by Oracle, in accordance with Apache bylaws and its usual open development processes. Both Oracle and ASF agree that the !OpenOffice.org development community, previously fragmented, would re-unite under ASF to ensure a stable and long term future for OpenOffice.org. ASF would enable corporate, non-profit, and volunteer stakeholders to contribute code in a collaborative fashion. Supporting tooling projects will accompany the !OpenOffice.org contribution, providing APIs for extending and customizing !OpenOffice.org. Both !OpenOffice.org and the related tooling projects support the OASIS Open Document Format, and will attract an ecosystem of developers, ISVs and Systems Integrators. ODF ensures the users of !OpenOffice.org and related solutions will own their document data, and be free to choose the application or solution that best meets their requirements. The !OpenOffice.org implementation will serve as a reference implementation of the Open Document Format standard. = Current Status = == Meritocracy == We understand the intention and value of meritocracy at Apache. We are particularly gratified to learn, during the discussion on this proposal, that there is a strong role for non-coders to participate in this meritocracy and as they demonstrate their
Re: Remediation ...
Considering the code was owned by Oracle, would Oracle and IBM have slugged out any IP issues between them before now? On Thu, Jun 9, 2011 at 12:56 PM, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Simon Phipps si...@webmink.com To: general@incubator.apache.org Sent: Thu, June 9, 2011 12:46:41 PM Subject: Re: Remediation ... On Thu, Jun 9, 2011 at 5:34 PM, Sam Ruby ru...@intertwingly.net wrote: On Thu, Jun 9, 2011 at 12:27 PM, Michael Meeks michael.me...@novell.com wrote: IMHO this is vastly preferable to some smoke and lawyer (IANAL) filled room that issues edicts to remove features and veto patches without a clear public rational on a public list (cf. the above). All work at the ASF that involve changes to the code base will be done in smoke-free and publicly archived mailing lists. If you have questions relating to prior work done by groups other than the ASF, I encourage you to contact those groups directly. Despite the tone, I do think Michael makes a serious point. Rob did indicate that IBM has IP concerns and it would be good to have more details before Apache takes on any responsibilities for the code. I don't see how this has any bearing on the vote. The ASF doesn't require entities to disclose whether or not any particular contribution includes a patent license. If anything is certain about this podling, given the mentors there will be no tolerance for any unusual off-list collusion or non-public decision-making regarding contributions of any kind. If Rob or any other IBM person has issues with what LO distributes, they can take it up with the TDF. If at some point there needs to be a discussion about outstanding patent claims regarding the code grant to the ASF, that is best done in the confines of a podling, on the podling's public dev list. - 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: Happy happy joy joy
Is that a copyleft swallow or an ALv2 swallow? On Wed, Jun 8, 2011 at 8:38 AM, Jim Jagielski j...@jagunet.com wrote: On Jun 7, 2011, at 2:43 PM, Simos Xenitellis wrote: On Thu, Jun 2, 2011 at 6:17 PM, Jim Jagielski j...@jagunet.com wrote: Guys, if we are going to argue over the mistakes of the pasts and the slights of the past, quite frankly, we aren't going to get very far. This is supposed to be a happy occasion; let's not bicker and argue about who-killed-who... :) If this is an attempt for reconciliation, it's somewhat poor ;-) And the last paragraph, quite ambiguous. You say 'bicker', which can be interpreted as a way to dissuade people from discussing. Do you feel people are bickering? The whole affair is a big issue, and what I detect is an attitude that it would better just not to discuss the touchy issues, as if they will go away. Monty Python and the Holy Grail. - 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: [OO.o] updated mailing lists in proposal
On Mon, Jun 6, 2011 at 5:18 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: According to Markmail (http://openoffice.markmail.org/) the following 37 openoffice.org mailing lists received more than 365 messages in 2010: Based on the volume here over the last week, how many of those lists got all 365 messages in one day? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Commerce and open-soure (Was) Proposal to join Apache OpenOffice
Actually, land-grab isn't an invalid analogy. Think of a mountain...Imagine some enterprising nonprof manages to buy a scenic mountain. A cadre of volunteers sees to it, cleaning up litter and the occasional forest fire. The nonprof opens up the mountain for anyone to go play on, as long as they don't unduly damage it. This doesn't prevent commercial organizations from exploiting the mountain. People might sell mountain t-shirts, mountain pictures, mini mountains, mountain tours, mountain bus trips or travel packages, rooms in mountain-facing hotels, etc. There's virtually no limit to the amount of mountain-related business that can be conducted...as long as the mountain remains untouched. Because all those businesses rely on the mountain being there. The purpose of the nonprof is to preserve the mountain and keep it untouched, or at least reasonably pristine. As opposed to, say, some strip-mining company that would, for its own profit, make the mountain go away. And hey, if people from the surrounding businesses want to come in and pick up trash too, more power to 'em. On Mon, Jun 6, 2011 at 1:53 PM, Phillip Rhodes motley.crue@gmail.com wrote: On Mon, Jun 6, 2011 at 1:43 PM, Benson Margulies bimargul...@gmail.comwrote: The expression 'land-grab' in here bothers me. I understand (if not agree with) the 'deep philosophy justification' of the FSF for a particular licensing strategy. I understand the views of individuals who don't want to benefit corporations without extracting, at least, some token cooperation in return. I don't understand the analogy in which code is 'land' which can be 'grabbed'. If a corporation takes ALv2 licensed code and uses it to launch some close-source thing, the code isn't used up. It's still there where anyone else can use it for anything else. Thanks for saying that... I was thinking about making a similar post, but hadn't quite found time to figure out exactly how to express it. I realize some people interacting in this current discussion may not be long-time participants in ASF projects, and / or may be FSF / Free software ideologues... but I think it's important to realize that the ASF is not the FSF and that the Apache License is written the way it is for a reason, and that it reflects the ideals of the ASF community. Here, as far as I can tell, it is completely acceptable for an entity (corporation or otherwise) to take Apache licensed code, put it into a proprietary app, and benefit from it commercially. Yes, the community most likely finds it *desirable* for such an entity to contribute back in kind, but it's not required. And here, that's just a normal par for the course part of the way things work. In short, complaining about what IBM, or any other commercial entity, plans to do with the OOo code, and spending all this energy worrying about IBM's strategy, and criticizing IBM, is not helping this process. The goal here is to get the code into the incubator, and have a healthy, vibrant community emerge that can run a viable project according to the Apache way. A lot of this discussion strikes me as tangential (at best) to that. None of this is meant to disparage TDF, LibreOffice, or Free/Libre software... but the issues about commercialization of the code that might be crucial in some orgs, are not (as) relevant here. A healthy, vibrant project is relevant... if IBM, Oracle, Microsoft, Novell, SCO, or Enron decide to use the code for a commercial project, then so be it. All of this is IMO of course. Phil - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Happy happy joy joy
The butler did it. On Thu, Jun 2, 2011 at 11:17 AM, Jim Jagielski j...@jagunet.com wrote: Guys, if we are going to argue over the mistakes of the pasts and the slights of the past, quite frankly, we aren't going to get very far. This is supposed to be a happy occasion; let's not bicker and argue about who-killed-who... :) On Jun 2, 2011, at 11:11 AM, robert_w...@us.ibm.com wrote: Jochen Wiedmann jochen.wiedm...@gmail.com wrote on 06/02/2011 10:25:20 AM: I trust I do not need to explain at length to an Apache PMC the relative merits of the Apache 2.0 license or the strengths and stability of the ASF. I'll take it as granted that this is well-known to you all. In any case I am a strict adherent to the practical wisdom of not debating open source licenses while sober, and I decline to make an exception in this case. Rob, it may come as a surprise to you: But what I wrote was in no way related to a particular license. I would have written just the same, if Apache would use the LGPL/MPL and LibreOffice where ASL licensed. The point I am trying to make is that it is (IMO) in noone's interest to create a second community (!), the exception (at least it seems) being IBM. Everyone else would be just as happy or even happier if the OO code base, trademarks, etc. where simply donated to TDF. Respectfully, Jochen, that is your opinion, but it disproved with every non-IBM name added to the wiki. Despite TDF press releases, there was never unanimous support for LibreOffice among members of the OpenOffice.org community. We're seeing some of them stand up now and be counted. What is best for them? Really? Do you really want to tell them what is best for them, what will make everyone happy?! - 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: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? On Mon, Nov 8, 2010 at 11:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Ian, On Mon, Nov 8, 2010 at 4:22 PM, Ian Dickinson i...@epimorphics.com wrote: ...Bertrand wrote: ... 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first As an Apache newbie it's hard to comment definitively, but it's not clear to me what the common needs of the projects might be, and how dependencies would handled. Are there examples of existing commons areas between Apache projects, other than basic application-library dependencies? The best example is commons.apache.org of course - my idea is that utilities and libraries that might be useful for several of those new semantic projects should be shared whenever possible, to avoid duplication of efforts. As Olivier notes, it's best to create such a commons area only when we really need it, there's no need to define things precisely right now. -Bertrand - 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] NPanday Project
Are there plans for NPanday to work with other .NET IDEs, such as SharpDevelop (www.sharpdevelop.net)? Don On Thu, Jul 29, 2010 at 7:12 AM, Mark Struberg strub...@yahoo.de wrote: sounds good. A minor question: do you plan to graduate under the umbrella of the Maven TLP or becoming an own TLP? LieGrue, strub - Original Message From: Josimpson Ocaba joc...@g2ix.net To: general@incubator.apache.org Sent: Thu, July 29, 2010 12:10:29 PM Subject: Re: [PROPOSAL] NPanday Project Hi, We would like to inquire if there are any more comments before we could start a vote. note: We also have a current vote for a new committer at codeplex, so we will wait for the results on that and adjust the proposal before the vote if needed. - Original Message - From: Josimpson Ocaba joc...@g2ix.net To: general@incubator.apache.org Sent: Friday, July 23, 2010 1:23:18 PM Subject: [PROPOSAL] NPanday Project Good Day, In behalf of the NPanday community I would like to share with you our proposal for the NPanday project to be included amongst one of the incubation projects. Here is the link for the proposal in the incubation: http://wiki.apache.org/incubator/NPandayProposal and here is the link for the current location of the project: http://npanday.codeplex.com/ Please let us know any feedbacks or questions about the proposal. We would very much welcome any volunteers to help us guide NPanday through this incubation process. -- NPanday Proposal -- Abstract NPanday y allows projects using the .NET framework to be built with Apache Maven. NPanday allows .NET projects to be converted into Maven projects thus allowing them to fully utilize the other technologies driven by Maven. Proposal NPanday primarily provides two capabilities: a set of Maven plugins, for constructing builds in Maven that use the .NET command-line tools; and a Visual Studio Addin that keeps a Visual Studio project in sync with the Maven POM and adds reference resolution from Maven artifact repositories. Together this allows you to use a single tool across .NET, Java or any other Maven-based projects, including the same benefits of dependency management, automated release and source control management. Background When building .NET projects traditionally you would use the built in components in Visual Studio or compile the source code by hand in the command line using .NET frameworks. NPanday gives an alternative building management option. NPanday also allows developers to continue to build and develop .NET projects even without the aid of Visual Studio. Rationale NPanday allows developers to still use the .NET Frameworks and technologies that they need and at the same time allow their projects to be distributed and released with greater ease using Maven's conventions. NPanday also helps those developers maintain and integrate their project in a continuus integration that could host both Java and .NET projects. Initial Goals The initial goals for NPanday are: * Donate the existing codebase and import it. * Setup the incubation infrastructure (svn repository, build system, website) so we can run continuous builds with automated testing and publish all available documentation and releases, and migrate from Codeplex * Get people involved in advancing the code base in different directions, integrating it with other projects at Apache. * Work closely with current contributors and seek to add new committers * Prepare for a point release that meets incubator and Apache criteria * Start active development on NPanday 2.0 Current Status The current codebase is developed and tested in both .NET and Java. It was developed at Codeplex for the last two years after originally being forked from the failed NMaven incubator podling. We have a number of releases all of which have followed a clear transparent process. Documentation for the project is currently available in http://www.npanday.org/docs/1.2/, which can be donated and converted to the Apache NPanday website. The development team is currently using Codeplex discussion forums as the primary colaborative process. Meritocracy Some of the core developers are already committers and PMC members at Apache, so they understand what it means to have a process based on meritocracy. NPanday has been operating under an Apache-like model since its inception. Community We've seen a number of new contributors joining the community recently.. Most of the community members have found NPanday through searching for Maven in .NET and have donated their own tweaks as they continue to consume NPanday. The community members have actively created issues that are improving the behaviors and bugs in the current version. Core Developers The
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Okay, getting back into this. Offering to mentor? Have I your permission to add you to the proposal in that capacity? I would not be averse to this project being attached to a bigger project. Did you have a particular one in mind? Don On Fri, Mar 12, 2010 at 3:45 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Thu, Mar 11, 2010 at 22:23, Donald Whytock dwhyt...@gmail.com wrote: Sorry to leave things on a sour note...had family in from college. Do we want to take this off-channel to discuss details? Preferrably - no. Let's continue here. Bernd - 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] Chatterbot, a lightweight framework for chat responders
Sorry to leave things on a sour note...had family in from college. Do we want to take this off-channel to discuss details? Don On Wed, Mar 3, 2010 at 11:57 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Wed, Mar 3, 2010 at 16:23, Donald Whytock dwhyt...@gmail.com wrote: So I gather that's a no on mentoring. throws ParseException. In fact, I'm still volunteering to mentor (if you still want to have me). I only propose to think about and discuss to move it to an existing project's sandbox as an alternative to incubation. Bernd Any other takers? Don On Wed, Mar 3, 2010 at 3:36 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Wed, Mar 3, 2010 at 00:06, Donald Whytock dwhyt...@gmail.com wrote: On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: So, what are your short term goals with chatterbot? As you are on the incubator list and put up a proposal, the goal should be to become an Incubator project. Otherwise, we are just wasting time here. An important part of preparing for Incubation is recruting mentors. Making Chatterbot an Incubator project is indeed my goal. Based on that goal, I looked at the other projects under consideration, which typically have multiple committers, an existing community and a good-sized codebase, Indeed, this is the tricky part. You might want to consider taking this project to the sandbox of an existing project, and grow from there. and wondered what the response would be to, Hi, wanna be the mentor for my project that consists of me and my eleven-class app? Was that your question at the beginning? I'm pleased to find there is interest in the project. Yes, I am looking for mentors. If you'd want to test against a local server, I recommend using Vysper (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/). Thanks. I had a console for offline parser testing; this'll help with offline channel development. Bernd - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
So I gather that's a no on mentoring. Any other takers? Don On Wed, Mar 3, 2010 at 3:36 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Wed, Mar 3, 2010 at 00:06, Donald Whytock dwhyt...@gmail.com wrote: On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: So, what are your short term goals with chatterbot? As you are on the incubator list and put up a proposal, the goal should be to become an Incubator project. Otherwise, we are just wasting time here. An important part of preparing for Incubation is recruting mentors. Making Chatterbot an Incubator project is indeed my goal. Based on that goal, I looked at the other projects under consideration, which typically have multiple committers, an existing community and a good-sized codebase, Indeed, this is the tricky part. You might want to consider taking this project to the sandbox of an existing project, and grow from there. and wondered what the response would be to, Hi, wanna be the mentor for my project that consists of me and my eleven-class app? Was that your question at the beginning? I'm pleased to find there is interest in the project. Yes, I am looking for mentors. If you'd want to test against a local server, I recommend using Vysper (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/). Thanks. I had a console for offline parser testing; this'll help with offline channel development. Bernd - 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] Chatterbot, a lightweight framework for chat responders
On Tue, Mar 2, 2010 at 4:10 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: So, what are your short term goals with chatterbot? As you are on the incubator list and put up a proposal, the goal should be to become an Incubator project. Otherwise, we are just wasting time here. An important part of preparing for Incubation is recruting mentors. Making Chatterbot an Incubator project is indeed my goal. Based on that goal, I looked at the other projects under consideration, which typically have multiple committers, an existing community and a good-sized codebase, and wondered what the response would be to, Hi, wanna be the mentor for my project that consists of me and my eleven-class app? I'm pleased to find there is interest in the project. Yes, I am looking for mentors. If you'd want to test against a local server, I recommend using Vysper (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/). Thanks. I had a console for offline parser testing; this'll help with offline channel development. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Hello again... Following is the revised proposal text, as posted on the wiki. Significant changes are the goals, which now focus on building the framework around Felix and devising a standard for protocol handlers to be used both inside and outside the project, and the committer list, which now includes Christopher Brind. The wiki copy is at http://wiki.apache.org/incubator/ChatterbotProposal Thanks... Don - Proposal: Abstract ChatterBot is a lightweight, multiprotocol framework and container for chat responders. Proposal ChatterBot is a framework for developing chat responders (applications that respond to messages received via online chat) and a container for deploying them. It is written in Java SE, and runs as a Java application. Chat responders are built by extending a single class and modifying a configuration file to reference the new class. ChatterBot's focus is on the following characteristics: * Small: The current framework consists of eight core classes. * Standalone: ChatterBot does not require external servers to operate. * Portable: ChatterBot should work as run from any Java-capable machine. For full functionality that machine should have internet access, but localhost and console connectivity are possible. It should be possible to run multiple instances of ChatterBot on the same machine or on separate machines with no loss of functionality. * Extensible: An instance of ChatterBot can support multiple message parsers and protocols. Adding more is done by editing a configuration file. * Dynamic: Activating and de-activating modules should be possible during runtime. * Multi-user access: Multiple users, over multiple protocols, should be able to access deployed applications. Rationale A chat responder can serve as a user interface to applications, either those built into the responder or external applications with which the responder communicates. Such an interface is more secure than interfaces such as Telnet or web services since it does not require open ports in the firewall; the container connects out through the firewall to the chat server, rather than allowing users to connect in. A lightweight chat responder can be installed on any system to allow command-line access to users over whatever protocol a user may have access to. Thus applications can be accessed from web interfaces, instant-message systems, text messages, email, etc. A scalable container can allow as many or as few access protocols as are desired. ChatterBot, therefore, has value for those circumstances where a user interface is needed but a server-based or enterprise solution is either not possible or not desired. It also can serve as a bridge between applications, where one or more uses a chat protocol such as XMPP to communicate. Background ChatterBot began in 2005 as a thin-server approach to online multi-user board games, implemented as applets sending gamestate changes to one another via message relaying. The idea was to make as general-purpose a server as possible, so that multiple games could be built that employed the same message-relaying system. Version 0.2 of the server was then refined in 2008 to allow for more varied and functional message-handlers, and was used to implement a room system that allowed for room-specific applications -- parsers that checked the user's room before handling a command and sent responses to other room occupants. This version was structured entirely around XMPP. The global namespace was introduced to allow modules to communicate with relatively limited coupling. Version, 0.3, as of late 2009, functions with XMPP and has the capacity to function with whatever other protocols channels are coded for. V0.3, though, uses a custom shell, with rudimentary module lifecycle capability. This proposal introduces version 0.4, to be based on OSGi for module lifecycle management and event-driven module synchronization. Applications originally built for v0.2 will be ported to v0.4. Current Status Meritocracy: Peer review and alternate ideas are welcomed in this project with open arms. This project was intended specifically as an alternative to traditional server-based or enterprise architecture; however, it is recognized that tried-and-tested principles established in enterprise architecture may be applicable here. Core Developers: As of late 2009, there is one developer, Donald Whytock (dwhytock at gmail dot com). Donald Whytock has several years of experience as a software developer, working in a variety of languages, including C, Java, Perl, PHP, JavaScript and SQL. He develops both professionally and casually; ChatterBot has been an independent, voluntary effort. Alignment: ChatterBot's primary potential alignment with ASF is that of a framework for internet-accessible applications. As command parsers can be built to interface with other applications, ChatterBot can be employed as a general-purpose remote console operating over instant
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Well, it seemed presumptuous to ask about mentors when I hardly had a community...but thank you for your consideration. Yes, mentoring would be appreciated. I tested my XMPP handler against two servers: Google's chat server and one managed by dreamhost.com. The handler is rudimentary, yes; there are several functions of the protocol it doesn't handle yet. A big one is dynamically accepting/rejecting users; at the moment I manually authenticate new contacts. But it does work (mixed results with Google). V0.3 will make a connection to its server, accept messages from authenticated contacts and send responses. With the right Parsers it should communicate with multiple users, relaying messages between them and originating messages based on other users' actions. I have Parsers that did this for v0.2 that I haven't ported over yet. The handler was a first effort for me, meant as an education in protocol handling. Happy to look at other things now...Thanks, I'll check out Smack. (http://www.igniterealtime.org/projects/smack/) Don On Mon, Mar 1, 2010 at 11:42 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Hi, What about mentors? I cannot find any note you are actively searching for them, but maybe I missed that. As I think about volunteering to mentor, my question is: Against what server did you test your own XMPP implementation? Does it really work as it seems to be rudimentary to me. Why didn't you use a XMPP client lib like Smack? Thanks, Bernd On Mon, Mar 1, 2010 at 12:54, Donald Whytock dwhyt...@gmail.com wrote: Hello again... Following is the revised proposal text, as posted on the wiki. Significant changes are the goals, which now focus on building the framework around Felix and devising a standard for protocol handlers to be used both inside and outside the project, and the committer list, which now includes Christopher Brind. The wiki copy is at http://wiki.apache.org/incubator/ChatterbotProposal Thanks... Don - Proposal: Abstract ChatterBot is a lightweight, multiprotocol framework and container for chat responders. Proposal ChatterBot is a framework for developing chat responders (applications that respond to messages received via online chat) and a container for deploying them. It is written in Java SE, and runs as a Java application. Chat responders are built by extending a single class and modifying a configuration file to reference the new class. ChatterBot's focus is on the following characteristics: * Small: The current framework consists of eight core classes. * Standalone: ChatterBot does not require external servers to operate. * Portable: ChatterBot should work as run from any Java-capable machine. For full functionality that machine should have internet access, but localhost and console connectivity are possible. It should be possible to run multiple instances of ChatterBot on the same machine or on separate machines with no loss of functionality. * Extensible: An instance of ChatterBot can support multiple message parsers and protocols. Adding more is done by editing a configuration file. * Dynamic: Activating and de-activating modules should be possible during runtime. * Multi-user access: Multiple users, over multiple protocols, should be able to access deployed applications. Rationale A chat responder can serve as a user interface to applications, either those built into the responder or external applications with which the responder communicates. Such an interface is more secure than interfaces such as Telnet or web services since it does not require open ports in the firewall; the container connects out through the firewall to the chat server, rather than allowing users to connect in. A lightweight chat responder can be installed on any system to allow command-line access to users over whatever protocol a user may have access to. Thus applications can be accessed from web interfaces, instant-message systems, text messages, email, etc. A scalable container can allow as many or as few access protocols as are desired. ChatterBot, therefore, has value for those circumstances where a user interface is needed but a server-based or enterprise solution is either not possible or not desired. It also can serve as a bridge between applications, where one or more uses a chat protocol such as XMPP to communicate. Background ChatterBot began in 2005 as a thin-server approach to online multi-user board games, implemented as applets sending gamestate changes to one another via message relaying. The idea was to make as general-purpose a server as possible, so that multiple games could be built that employed the same message-relaying system. Version 0.2 of the server was then refined in 2008 to allow for more varied and functional message-handlers, and was used to implement a room system that allowed for room-specific applications -- parsers that checked
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
Ignite lists Smack as licensed under the Apache license v2 (http://www.apache.org/licenses/LICENSE-2.0), though it's not an Apache project. I assume that license is revokable by Ignite at any time? How does incorporating outside code work in Apache projects? Don On Mon, Mar 1, 2010 at 6:43 PM, Donald Whytock dwhyt...@gmail.com wrote: Well, it seemed presumptuous to ask about mentors when I hardly had a community...but thank you for your consideration. Yes, mentoring would be appreciated. I tested my XMPP handler against two servers: Google's chat server and one managed by dreamhost.com. The handler is rudimentary, yes; there are several functions of the protocol it doesn't handle yet. A big one is dynamically accepting/rejecting users; at the moment I manually authenticate new contacts. But it does work (mixed results with Google). V0.3 will make a connection to its server, accept messages from authenticated contacts and send responses. With the right Parsers it should communicate with multiple users, relaying messages between them and originating messages based on other users' actions. I have Parsers that did this for v0.2 that I haven't ported over yet. The handler was a first effort for me, meant as an education in protocol handling. Happy to look at other things now...Thanks, I'll check out Smack. (http://www.igniterealtime.org/projects/smack/) Don On Mon, Mar 1, 2010 at 11:42 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: Hi, What about mentors? I cannot find any note you are actively searching for them, but maybe I missed that. As I think about volunteering to mentor, my question is: Against what server did you test your own XMPP implementation? Does it really work as it seems to be rudimentary to me. Why didn't you use a XMPP client lib like Smack? Thanks, Bernd On Mon, Mar 1, 2010 at 12:54, Donald Whytock dwhyt...@gmail.com wrote: Hello again... Following is the revised proposal text, as posted on the wiki. Significant changes are the goals, which now focus on building the framework around Felix and devising a standard for protocol handlers to be used both inside and outside the project, and the committer list, which now includes Christopher Brind. The wiki copy is at http://wiki.apache.org/incubator/ChatterbotProposal Thanks... Don - Proposal: Abstract ChatterBot is a lightweight, multiprotocol framework and container for chat responders. Proposal ChatterBot is a framework for developing chat responders (applications that respond to messages received via online chat) and a container for deploying them. It is written in Java SE, and runs as a Java application. Chat responders are built by extending a single class and modifying a configuration file to reference the new class. ChatterBot's focus is on the following characteristics: * Small: The current framework consists of eight core classes. * Standalone: ChatterBot does not require external servers to operate. * Portable: ChatterBot should work as run from any Java-capable machine. For full functionality that machine should have internet access, but localhost and console connectivity are possible. It should be possible to run multiple instances of ChatterBot on the same machine or on separate machines with no loss of functionality. * Extensible: An instance of ChatterBot can support multiple message parsers and protocols. Adding more is done by editing a configuration file. * Dynamic: Activating and de-activating modules should be possible during runtime. * Multi-user access: Multiple users, over multiple protocols, should be able to access deployed applications. Rationale A chat responder can serve as a user interface to applications, either those built into the responder or external applications with which the responder communicates. Such an interface is more secure than interfaces such as Telnet or web services since it does not require open ports in the firewall; the container connects out through the firewall to the chat server, rather than allowing users to connect in. A lightweight chat responder can be installed on any system to allow command-line access to users over whatever protocol a user may have access to. Thus applications can be accessed from web interfaces, instant-message systems, text messages, email, etc. A scalable container can allow as many or as few access protocols as are desired. ChatterBot, therefore, has value for those circumstances where a user interface is needed but a server-based or enterprise solution is either not possible or not desired. It also can serve as a bridge between applications, where one or more uses a chat protocol such as XMPP to communicate. Background ChatterBot began in 2005 as a thin-server approach to online multi-user board games, implemented as applets sending gamestate changes to one another via message relaying. The idea was to make
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
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 he...@ungoverned.org 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 Brindbri...@brindy.org.uk wrote: Hi, I have read through the proposal and I like the idea of it. The only issues I have are around modularity and shell/console. Apache already has a modularity solution (Felix) based on an open standard (OSGi) I don't think the Java community as a whole needs yet another modularity solution. =) Felix also provides a shell which allows you to manage module (bundle) lifecycle (install, start, stop, update, uninstall) and while I don't know what the status is regarding the 'Standard Shell' (OSGi RFC 132) it is quite easy to add new commands to the Felix shell. Felix is also very lightweight, so it wouldn't add much to your footprint, but would give you a sophisticated dynamic module contain in which to work as well as making it compatible with various environments already using OSGi now (e.g. Application Servers
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
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. 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 bri...@brindy.org.uk wrote: Hi, I have read through the proposal and I like the idea of it. The only issues I have are around modularity and shell/console. Apache already has a modularity solution (Felix) based on an open standard (OSGi) I don't think the Java community as a whole needs yet another modularity solution. =) Felix also provides a shell which allows you to manage module (bundle) lifecycle (install, start, stop, update, uninstall) and while I don't know what the status is regarding the 'Standard Shell' (OSGi RFC 132) it is quite easy to add new commands to the Felix shell. Felix is also very lightweight, so it wouldn't add much to your footprint, but would give you a sophisticated dynamic module contain in which to work as well as making it compatible with various environments already using OSGi now (e.g. Application Servers, etc). I could see potential uses for this project in my own work, but as I've implied, it would have to be compatible with OSGi which is where I spend most of my time. I'd even offer to assist that effort on this project. This is more of a question, is there any Java API standard abstraction for chat protocols? e.g. javax.chat? I don't think there is but there is of course JMS, is ChatterBot significantly different from JMS? If so, perhaps a low priority side goal of the project should be to develop a standard Java API standardisation for chat? Cheers, Chris On 29 January 2010 03:32, Donald Whytock dwhyt...@gmail.com wrote: Hello all... As discussed before, here is the current wiki text of the proposal for Chatterbot, a lightweight framework for chat responders. The proposal is at http://wiki.apache.org/incubator/ChatterbotProposal Interested in comments, feedback and participation. Thanks... Don - wiki text - Abstract ChatterBot is a lightweight, multiprotocol framework and container for chat responders. Proposal ChatterBot is a framework for developing chat responders (applications that respond to messages received via online chat) and a container for deploying them. It is written in Java SE, and runs as a Java application. Chat responders are built by extending a single class and modifying a configuration file to reference the new class. ChatterBot's focus is on the following characteristics: - Small: The current framework consists of eight core classes. - Standalone: ChatterBot does not require external servers to operate. - Portable: ChatterBot should work as run from any Java-capable machine. For full functionality that machine should have internet access, but localhost and console connectivity are possible. It should be possible to run multiple instances of ChatterBot on the same machine or on separate machines with no loss of functionality. - Extensible: An instance of ChatterBot can support multiple message parsers and protocols. Adding more is done by editing
[PROPOSAL] Chatterbot, a lightweight framework for chat responders
Hello all... As discussed before, here is the current wiki text of the proposal for Chatterbot, a lightweight framework for chat responders. The proposal is at http://wiki.apache.org/incubator/ChatterbotProposal Interested in comments, feedback and participation. Thanks... Don - wiki text - Abstract ChatterBot is a lightweight, multiprotocol framework and container for chat responders. Proposal ChatterBot is a framework for developing chat responders (applications that respond to messages received via online chat) and a container for deploying them. It is written in Java SE, and runs as a Java application. Chat responders are built by extending a single class and modifying a configuration file to reference the new class. ChatterBot's focus is on the following characteristics: - Small: The current framework consists of eight core classes. - Standalone: ChatterBot does not require external servers to operate. - Portable: ChatterBot should work as run from any Java-capable machine. For full functionality that machine should have internet access, but localhost and console connectivity are possible. It should be possible to run multiple instances of ChatterBot on the same machine or on separate machines with no loss of functionality. - Extensible: An instance of ChatterBot can support multiple message parsers and protocols. Adding more is done by editing a configuration file. - Dynamic: Activating and de-activating modules should be possible during runtime. Multi-user access: Multiple users, over multiple protocols, should be able to access deployed applications. Rationale A chat responder can serve as a user interface to applications, either those built into the responder or external applications with which the responder communicates. Such an interface is more secure than interfaces such as Telnet or web services since it does not require open ports in the firewall; the container connects out through the firewall to the chat server, rather than allowing users to connect in. A lightweight chat responder can be installed on any system to allow command-line access to users over whatever protocol a user may have access to. Thus applications can be accessed from web interfaces, instant-message systems, text messages, email, etc. A scalable container can allow as many or as few access protocols as are desired. ChatterBot, therefore, has value for those circumstances where a user interface is needed but a server-based or enterprise solution is either not possible or not desired. It also can serve as a bridge between applications, where one or more uses a chat protocol such as XMPP to communicate. Background ChatterBot began in 2005 as a thin-server approach to online multi-user board games, implemented as applets sending gamestate changes to one another via message relaying. The idea was to make as general-purpose a server as possible, so that multiple games could be built that employed the same message-relaying system. Version 0.2 of the server was then refined in 2008 to allow for more varied and functional message-handlers, and was used to implement a room system that allowed for room-specific applications -- parsers that checked the user's room before handling a command and sent responses to other room occupants. This version was structured entirely around XMPP. The global namespace was introduced to allow modules to communicate with relatively limited coupling. The current version, 0.3, as of late 2009, functions with XMPP and has the capacity to function with whatever other protocols channels are coded for. Applications built using 0.2 are being ported to 0.3. At this point the original thin-server backend intended in 0.1 would be built as an application using 0.3. Current Status Meritocracy Peer review and alternate ideas are welcomed in this project with open arms. This project was intended specifically as an alternative to traditional server-based or enterprise architecture; however, it is recognized that tried-and-tested principles established in enterprise architecture may be applicable here. Core Developers As of late 2009, there is one developer, Donald Whytock (dwhytock at gmail dot com). Donald Whytock has several years of experience as a software developer, working in a variety of languages, including C, Java, Perl, PHP, JavaScript and SQL. He develops both professionally and casually; ChatterBot has been an independent, voluntary effort. Alignment ChatterBot's primary potential alignment with ASF is that of a framework for internet-accessible applications. At its core, it is largely free of outside dependencies, though modules can be built to utilize other technologies. Embedded Derby is used in one application; use of Derby and/or ORM should be explored as a base capability. Initial Goals ChatterBot currently exists as a functioning prototype; protocol modules built for it provide access to chat responders via XMPP/Jabber, localhost connections and a chat-simulating
Re: ChatterBot chat responder framework
I did find the docs, yes, thanks. The docs themselves are fairly clear, though perhaps there needs to be a more straightforward Start Here. My impression from them, though, was that a community should exist first, before the actual proposal hit the list...? If the other way around works, I'll be happy to do it that way. Don On Tue, Jan 5, 2010 at 9:05 PM, David Crossley cross...@apache.org wrote: Donald Whytock wrote: I have a personal project that I would like to make OpenSource and submit to the ASF. It is a small framework for chat responders, designed to be multi-user and multi-protocol, called ChatterBot. The website for the project is: http://www.imtower.net/chatterbot with a mailing list at http://lists.imtower.net/listinfo.cgi/chatterbot-imtower.net Seeking interested contributors, potential mentors, and, perhaps most important, peer review. This is interesting. No time for me to look right now. However i definitely do want to encourage you. I see that you have an initial Proposal at your site. Next step would be to refine it and then move it to http://wiki.apache.org/incubator/ then send the text of it to this list with [Proposal] subject tag. Did you find the ASF docs about Incubator proposals? Sorry that it is a mess, but you get the drift. BTW, might also get some ideas from ASF Infra's own recent beaut infrabot. -David - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
ChatterBot chat responder framework
Hello, I have a personal project that I would like to make OpenSource and submit to the ASF. It is a small framework for chat responders, designed to be multi-user and multi-protocol, called ChatterBot. The website for the project is: http://www.imtower.net/chatterbot with a mailing list at http://lists.imtower.net/listinfo.cgi/chatterbot-imtower.net Seeking interested contributors, potential mentors, and, perhaps most important, peer review. Thanks... Donald Whytock
