Re: [VOTE] Accept Wayang into the Apache Incubator
+1 Bernd On Fri, Dec 11, 2020 at 5:33 PM Christofer Dutz wrote: > Hi all, > > following up the [DISCUSS] thread on Wayang ( > https://lists.apache.org/thread.html/r5fc03ae014f44c7c31a509a6db4ac07faedb2e1c6245cd917b744826%40%3Cgeneral.incubator.apache.org%3E) > I would like to call a VOTE to accept Wayang Aka Rheem into the Apache > Incubator. > > Please cast your vote: > > [ ] +1, bring Wayang into the Incubator > [ ] +0, I don't care either way > [ ] -1, do not bring Wayang into the Incubator, because... > > The vote will open at least for 72 hours and only votes from the Incubator > PMC are binding, but votes from everyone are welcome. > > Chris > > - > > Wayang Proposal ( > https://cwiki.apache.org/confluence/display/INCUBATOR/WayangProposal) > > == Abstract == > > Wayang is a cross-platform data processing system that aims at decoupling > the business logic of data analytics applications from concrete data > processing platforms, such as Apache Flink or Apache Spark. Hence, it tames > the complexity that arises from the "Cambrian explosion" of novel data > processing platforms that we currently witness. > > Note that Wayang project is the Rheem project, but we have renamed the > project because of trademark issues. > > You can find the project web page at: https://rheem-ecosystem.github.io/ > > = Proposal = > > Wayang is a cross-platform system that provides an abstraction over data > processing platforms to free users from the burdens of (i) performing > tedious and costly data migration and integration tasks to run their > applications, and (ii) choosing the right data processing platforms for > their applications. To achieve this, Wayang: (1) provides an abstraction on > top of existing data processing platforms that allows users to specify > their data analytics tasks in a form of a DAG of operators; (2) comes with > a cross-platform optimizer for automating the selection of > suitable/efficient platforms; and (3) and finally takes care of executing > the optimized plan, including communication across platforms. In summary, > Wayang has the following salient features: > > - Flexible Data Model - It considers a flexible and simple data model > based on data quanta. A data quantum is an atomic processing unit in the > system, that can represent a large spectrum of data formats, such as data > points for a machine learning application, tuples for a database > application, or RDF triples. Hence, Wayang is able to express a wide range > of data analytics tasks. > - Platform independence - It provides a simple interface (currently Java > and Scala) that is inspired by established programming models, such as that > of Apache Spark and Apache Flink. Users represent their data analytic tasks > as a DAG (Wayang plan), where vertices correspond to Wayang operators and > edges represent data flows (data quanta flowing) among these operators. A > Wayang operator defines a particular kind of data transformation over an > input data quantum, ranging from basic functionality (e.g., > transformations, filters, joins) to complex, extensible tasks (e.g., > PageRank). > - Cross-platform execution - Besides running a data analytic task on any > data processing platform, it also comes with an optimizer that can decide > to execute a single data analytic task using multiple data processing > platforms. This allows for exploiting the capabilities of different data > processing platforms to perform complex data analytic tasks more > efficiently. > Self-tuning UDF-based cost model - Its optimizer uses a cost model fully > based on UDFs. This not only enables Wayang to learn the cost functions of > newly added data processing platforms, but also allows developers to tune > the optimizer at will. > - Extensibility - It treats data processing platforms as plugins to allow > users (developers) to easily incorporate new data processing platforms into > the system. This is achieved by exposing the functionalities of data > processing platforms as operators (execution operators). The same approach > is followed at the Wayang interface, where users can also extend Wayang > capabilities, i.e., the operators, easily. > > We plan to work on the stability of all these features as well as > extending Wayang with more advanced features. Furthermore, Wayang currently > supports Apache Spark, Standalone Java, GraphChi, relational databases (via > JDBC). We plan to incorporate more data processing platforms, such as > Apache Flink and Apache Hive. > > === Background === > > Many organizations and companies collect or produce large variety of data > to apply data analytics over them. This is because insights from data > rapidly allow them to make better decisions. Thus, the pursuit for > efficient and scalable data analytics as well as the > one-size-does-not-fit-all philosophy has given rise to a plethora of data > processing platforms. Examples of these specialized processing platforms > range from DBMSs to MapReduce-like
Re: [DISCUSS] Wayang Proposal
+1 If three mentors for Wayang are not enough (I'm one of them), how much would a incubating project need? Bernd On Sun, Dec 6, 2020 at 12:43 PM Justin Mclean wrote: > Hi, > > > Right now, there are 3 people signed up as mentors, however knowing that > not always are all mentors available at every given time, it would be cool > if we could find 1-2 more to help out. > > In no way reflecting on the mentors who have volunteered and I’m sure they > will do a good job > > In recent times I've notice that incubating projects with a large number > of initial mentors seem to have a very slow start. I’m not sure if the > issue is that each mentor assumes someone else will do the job or something > else but 3 initial mentors seems to be the sweet spot. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Accept Training into the Apache Incubator
[X] +1 Accept Training into the Apache Incubator (binding) Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release of Apache Twill 0.1.0-incubating [rc1]
On Sat, Feb 1, 2014 at 1:42 AM, Terence Yim cht...@gmail.com wrote: Hi all, This is to call for a vote for release of Apache Twill v0.1.0-incubating. This will be the first incubator release for Apache Twill. Vote on twill-dev: http://s.apache.org/Rsy Result on vote on twill-dev: http://s.apache.org/KMR The tag to be voted upon is v0.1.0-incubating: https://git-wip-us.apache.org/repos/asf?p=incubator-twill.git;a=tag;h=refs/tags/v0.1.0-incubating The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/incubator/twill/0.1.0-incubating-rc1/src [x] +1 (binding) Release this package as Apache Twill 0.1.0-incubating Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Hoya Proposal
Very informative explanation. I've got a better understanding of the proposal now. I suggest that a remark like this is added to the Hoya proposal, so this part of the discussion becomes part of the vote on the proposal.The proposal's Known Risk section lacks a Relationships with Other Apache Products paragraph, which would be a good place to add this information. There are more considerations missing that we have in other proposals. I'd suggest to add them, too, to complete the proposal. All-in-all I'm currently -1 on the proposal as it is, but ready to change to +1 as this discussion reaches a consent. (side note: When a project graduates, a PMC is established and tasked with a specific task. Two PMCs cannot have the same task. Therefore, it is better in my opinion to either clearly differentiate the projects from start, or join them from start.) Thanks, Bernd On Fri, Jan 17, 2014 at 8:48 AM, Devaraj Das d...@hortonworks.com wrote: Andreas, to me, Twill is a library, a convenience library, that one can use to write Yarn apps. Hoya aims to provide a general framework using which one can take existing apps (HBase/Accumulo to start with), and make them run well in a Yarn cluster, without intruding at all into the App internals. The goal is to have minimal, ideally zero changes, in the App itself. The only glue between the App and Hoya is a Hoya interface that the App needs to implement for it to be deployable/manageable by Hoya. Although, one could argue that Hoya can be written using Twill libraries (which is something we should pursue as part of long/medium-term collaboration between the two projects), but I'd argue that the goals of the two projects are different - Twill would continue to make Yarn app developers' lives easier, while Hoya is a tool that could deploy distributed-frameworks easily in a Yarn cluster, and be able to later do basic management (as is talked about in the github docs). Things like dynamic configuration patching for the applications like HBase to easily run in a Yarn cluster, security issues, failure handling and defining a model for reacting to failures, being able to store some state about applications to facilitate better application restart behavior in a Yarn cluster, etc. would be in the purview of Hoya. Management frameworks could use Hoya as a tool as well to talk to Yarn and do application start/stop/shrink/expand an instance of an application (e.g. HBase) cluster. On Thu, Jan 16, 2014 at 4:38 PM, Andreas Neumann a...@apache.org wrote: I do see a lot of value in all the features of Hoya, and I am not trying to discredit it. Yet I do think that most of these features are actually already in Twill or would be great additions to Twill, and sooner or later will be implemented in Twill, implying even greater overlap. I am not sure whether I follow the distinction between porting an existing app and developing a new app, if both require similar abstractions... And after all, porting an existing application is one way to start developing a Yarn application. Anyway, I just wanted to point out the overlap and offer collaboration. If the community thinks that the two projects are different beasts, that's fine with me. On Wed, Jan 15, 2014 at 10:40 AM, Josh Elser josh.el...@gmail.com wrote: I wanted to weigh in on some of Steve's thoughts, I'm actually really excited about being able to leverage Hoya inside of Accumulo itself. We presently have a few system tests that rely on manual set up, which can be frustrating to deal with on a beefy boxes (running multiple Accumulo procs on a single host). Hoya drastically reduces the amount of effort it takes to run these distributed tests in a 'closer to real' environment. On Jan 15, 2014 8:36 AM, Steve Loughran ste...@hortonworks.com wrote: On 15 January 2014 02:13, Andreas Neumann a...@apache.org wrote: I see. So is Hoya limited to HBase and Accumulo? Or is it open for any other type of existing application? If so, won't it have some common abstraction that is shared by all of them? That is where I see the similarity with Twill. it started off as pure hbase, but now has the notion of a provider which has a client-side and server side client side -helps set up the template JSON file to describe the cluster (e.g. adds default values), -patches the configuration directory supplied at creation time with whatever options it wants (e.g links up fs.default.name ZK settings in hbase-site.xml) -does preflight validation of cluster options -can also add its own .tar.gz to the resources of the AM (or any other resources) server side -runs in the AM and sets up everything needed to run instances of a role (e.g. HBase master, Accumulo GC, ..) -can run code in the AM to help set things up (e.g. Accumulo provider service runs bin/accumulo init if needed) -TODO: liveness monitoring the requirements of an app to be
Re: Hoya Proposal
On Fri, Jan 17, 2014 at 1:13 PM, Steve Loughran ste...@hortonworks.com wrote: On 17 January 2014 10:10, Bernd Fondermann bernd.fonderm...@gmail.comwrote: (side note: When a project graduates, a PMC is established and tasked with a specific task. Two PMCs cannot have the same task. Therefore, it is better in my opinion to either clearly differentiate the projects from start, or join them from start.) Really? Because while I am confident that hoya and twill are different, i do note similarities between ant, maven and buildr, commons-logging, log4j and avalon-logger,.. Now if two podling entered the Incubator around the same time with the same goal I think it would be unwise to not a. set both on parallel tracks instead of the same or b. make them one train from start. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Hoya Proposal
I think that Andreas has a valid point. With the description you are giving here, there seems to be much more overlap with the Twill podling than I initially anticipated. In the Hoya proposal, I'd like to learn about how it compares to Twill and why it makes sense to start another such podling while the other one is still ongoing. Bernd On Wed, Jan 15, 2014 at 2:36 PM, Steve Loughran ste...@hortonworks.comwrote: On 15 January 2014 02:13, Andreas Neumann a...@apache.org wrote: I see. So is Hoya limited to HBase and Accumulo? Or is it open for any other type of existing application? If so, won't it have some common abstraction that is shared by all of them? That is where I see the similarity with Twill. it started off as pure hbase, but now has the notion of a provider which has a client-side and server side client side -helps set up the template JSON file to describe the cluster (e.g. adds default values), -patches the configuration directory supplied at creation time with whatever options it wants (e.g links up fs.default.name ZK settings in hbase-site.xml) -does preflight validation of cluster options -can also add its own .tar.gz to the resources of the AM (or any other resources) server side -runs in the AM and sets up everything needed to run instances of a role (e.g. HBase master, Accumulo GC, ..) -can run code in the AM to help set things up (e.g. Accumulo provider service runs bin/accumulo init if needed) -TODO: liveness monitoring the requirements of an app to be deployable are https://github.com/hortonworks/hoya/blob/master/src/site/markdown/app_needs.md Whereas, if it is a separate effort for each existing application, say HBase, then what is the end goal for Hoya when it comes out of incubation? To merge it back into HBase proper? Now that it supports 1 application, it can't go into HBase. The individual provider services can (their implementation classes are worked out via the configuration.XML). But as we use the accumulo and HBase apps for testing, its really good to have them both in the hoya project right now -a project that builds downstream of both and needs to be given the Hadoop filesystem paths to .tar.gz files of each app. There's nothing to stop 3rd party apps joining in, indeed, one thing I'd like someone to do is actually have Hoya deploy SmartFrog .tar.gz files and pass down configurations that deploy applications -for example jetty-based web servers. That'd take an intern working at HP Labs over the summer, maybe -steve -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Hoya Proposal
Which languages are they? I would expect the english pronounciation would be relevant, where Hyena (see http://en.wiktionary.org/wiki/hyena) is quite different from Jena. Bernd On Mon, Jan 13, 2014 at 9:25 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Jan 13, 2014 at 5:36 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Mon, Jan 13, 2014 at 3:33 PM, Steve Loughran ste...@hortonworks.com wrote: ...What do people think about a project name Hyena? It's close enough, lives in the savannah... I think it's too close to http://jena.apache.org/ to be clear, this is a strong -1 from me, having confusing project names inside Apache is not ok. Hyena and Jena sound exactly the same in several languages, unfortunately. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Hoya Proposal
+1 Bernd On Mon, Jan 13, 2014 at 4:44 PM, Jean-Baptiste Onofré j...@nanthrax.netwrote: +1 for Hyena. Regards JB On 01/13/2014 03:33 PM, Steve Loughran wrote: On 9 January 2014 21:55, Enis Söztutar enis@gmail.com wrote: Proposal looks good. Let me know if you need any additional help in mentors. Enis +1 -I'd really like input from the HBase and Accumulo teams as they are the first apps we're trying to work with. On that note, I know we've used the acronym hoya, HBase on YARN, but it is already a bit out of date. What do people think about a project name Hyena? It's close enough, lives in the savannah... -steve -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance before releasing
On Sun, Dec 8, 2013 at 12:43 AM, Marvin Humphrey mar...@rectangular.comwrote: Greets, I read in the Tajo report and I see on the dev list that the Tajo developers are now diligently tackling IP clearance: http://s.apache.org/00w In my view, IP clearance is only the remain work for graduation. That was also my understanding, that IP clearance is important, and neccessary for successful incubation, but incubator releases are orthogonal and therefore carry a disclaimer being not fully vetted Apache releases because of IP and other open issues. Have I missed a change here to our policie? However, the fact that this is only happening now represents a failure of the IPMC. Tajo made a release last month. That release should not have gotten our go-ahead until IP clearance was completed[1]. In the reference [1], what exactly are you referring to? [1] http://incubator.apache.org/projects/tajo.html http://incubator.apache.org/incubation/Incubation_Policy.html#Releases http://incubator.apache.org/guides/mentor.html#initial-ip-clearance Thanks, Bernd
Re: [VOTE] Accept Twill for Incubation
+1 Bernd On Fri, Nov 8, 2013 at 5:22 PM, Arun C Murthy a...@hortonworks.com wrote: +1 (binding) Arun On Nov 7, 2013, at 1:04 PM, Andreas Neumann a...@apache.org wrote: The discussion about the Weave proposal has calmed. As the outcome of the discussion, we have chosen a new name for the project, Twill. I would like to call a vote for Twill to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/TwillProposal Let's keep this vote open for three business days, closing the voting on Tuesday 11/12. [ ] +1 Accept Twill into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Twill because... -Andreas. = Abstract = Twill 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 = Twill 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. Twill 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. Twill 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 Twill, applications can be executed in process threads during development and unit testing and then be deployed to a YARN cluster without any modifications. Twill 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. Twill 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. Twill’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 Twill as an Apache project makes sense because Twill is a framework built on top of YARN, and Twill uses Apache Zookeeper, HDFS, Kafka, and other Apache software (see the External Dependencies section). = Current Status = Twill was initially developed at Continuuity under the name of Weave. The Weave codebase is currently hosted in a public repository at github.com, which will seed the Apache git repository after renaming to Twill. == Meritocracy == Our intent with this incubator proposal is to start building a diverse developer community around Twill following the Apache meritocracy model. Since Twill was initially developed in early 2013, we have had fast adoption and contributions within Continuuity. We are looking forward to new contributors. We wish to build a community based on Apache's meritocracy principles, working with those who contribute significantly to the project and welcoming them to be committers both during the incubation process and beyond. == Community == Twill is currently being used internally at Continuuity and is at the core of our products. We hope to extend our contributor base significantly and we will invite all who are interested in simplifying the development of distributed applications to participate. == Core Developers == Twill is currently being developed by five engineers at Continuuity: Terence Yim, Andreas Neumann, Gary Helmling, Poorna Chandra and Albert Shau. Terence Yim is an Apache committer for Helix, Andreas is an Apache committer and PMC member for Oozie, and Gary Helmling is an Apache committer and PMC member for HBase. Poorna Chandra and Albert Shau have made many contributions to Twill. == Alignment == The ASF is the natural choice to host the Twill project as its goal of encouraging
Re: What constitute a successful project?
On Tue, Nov 27, 2012 at 9:08 AM, Eric Yang eric...@gmail.com wrote: Apache is a non-profit organization. If we restrict our thinking model to metrics of how many developers, and how many patches are committed in pre-defeined time limit. There is no software that is gong to succeed in this evaluation other than commercial software. Paid developers are contributing to the software that meeting cooperate interests at rapid pace, and smaller companies will work together until cooperate interests tear apart the software, or the funding eventually dry up and the software cease to exist, and the community will eventually fall apart. We don't only apply metrics, otherwise this decision would be very easy, and we'd not have that discussion right now. One other aspect for example is that there's no Chukwa release for a long time. There are a lot of hard and soft facts I personally take into account for any vote. Good software usually comes down to a few individuals who work hard to enable the community to flourish. Many of the good software takes decades to develop from hobby projects. As long as these few indivduals are actually there, nobody would close a project. I will accept the voting result from IPMC, and I wish IPMC would use better human sense to enable future project to flourish. This sounds like you're frustrated with your mentors. I'm sorry for that and take part of the responsibility of Chukwa's failure. But really only a part. Chris Douglas resigned from mentor position, therefore, Chukwa will need a new mentor, and one of Chukwa contributor Sourygna Luangsay volunteer to be the motivator for Chukwa development if Chukwa is voted to stay for another 6 months. Everyone is welcome to contribute, vote (even if non-binding) and take part in discussion. (Hey, people, if you're out there, post to the list!) Not much of this happened over the last months. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire Chukwa from incubation
On Mon, Nov 26, 2012 at 12:00 AM, Alan Cabrera l...@toolazydogs.com wrote: Hi, The Chukwa community has voted to retire the project. Following the retirement guide [1], I now call the Incubator PMC to vote on confirming this decision. [X ] +1 Retire the Chukwa project Bernd, after careful consideration, failing to successfully mentor Chukwa. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: What constitute a successful project?
On Tue, Nov 27, 2012 at 1:25 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, Nov 26, 2012 at 10:53 PM, Alan Cabrera l...@toolazydogs.com wrote: As I mentioned in an earlier email, we did have this conversation seven months ago. We came to a consensus to give it another try. We even added a few committers a bit early with the hopes that they would infuse the project with more energy. That doesn't take away the fact that there are still people who are clearly interested in continuing work on the project. Instead of telling the community to pick up their toys and leave, I'd much rather ask them to come up with a credible alternative. The failure of past attempts to grow the community does not necessarily mean that future attempts will also fail, so I'd give the community the benefit of doubt as long as there are new ideas and people willing to try them. If I understand correctly the problems in Chukwa are two-fold: 1) the community isn't diverse, i.e. there are only few people involved, and 2) the community isn't active, in that even the involved people don't have too many cycles to spend on the project. Thus I'd raise the following questions to Eric and others who want to keep Chukwa alive at the ASF: a) Is it reasonable to expect existing community members to become more active in near future? If yes, will such increased activity be sustainable over a longer period of time? Why? IIUC there was some recent legal progress that might help here. What would be the best way to measure the expected increase in activity? b) How do you expect to get more people involved in the project? What concrete actions will be taken to increase the chances of new contributors showing up? Why do you believe these things will work better than the mentioned earlier attempts at growing the community? Good ideas of concrete actions are for example cutting new releases, improving project documentation, presenting the project at various venues, simplifying the project build and initial setup, and giving more timely answers and feedback to new users and contributors (see also my observation from October [1]). How can we best tell whether such efforts are working? Coming up with good answers to such questions is not necessarily easy (and it's fine if not all of them can yet be answered), but going through that effort should give us a good reason to continue the incubation of Chukwa at least for a few more months until we should start seeing some concrete and sustainable improvements in community activity and diversity. This is exactly what we did for the last months (years, actually). Give it yet more time. Honestly, I don't understand why we should continue in this mode for another few months when it failed for the past years. Is this the extra-bonus IPMC time? The legal issues only made it more clear to me that and why this Incubation failed. The much I'd love to see Chukwa fly, this is getting ridiculous. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Anticipating my reign of terror -- new idea for December
On Sun, Nov 4, 2012 at 11:29 PM, Benson Margulies bimargul...@gmail.com wrote: At the bottom of the template for each podling's report, I'd like to have a space for each of the mentors, every month, to reaffirm his or her involvement in the podling. Thus, instead of (at most) one mentor signing off on the report, itself, we'd get a reading on how many mentors are in the game. If the number were less than 3 -- and -- especially, if it were less than one, we'd be alerted and could make it a priority to find replacements. What do you think? +1. The foundation on all levels is great at recognizing engagement, but not that great at detecting the lack of. At other foundations like XSF for example members need to step up for re-election after three or so years. This assures that liveliness of the members body can actually be measured only by looking at the members list size. So your proposed showing of hands makes the reports more plausible. +1, again. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Drill for the Apache Incubator
great proposal and a very promising mentor lineup. Have fun, Bernd On Thu, Aug 2, 2012 at 11:40 PM, Ted Dunning tdunn...@apache.org wrote: Abstract Drill is a distributed system for interactive analysis of large-scale datasets, inspired by Google’s Dremel ( http://research.google.com/pubs/pub36632.html). Proposal Drill is a distributed system for interactive analysis of large-scale datasets. Drill is similar to Google’s Dremel, with the additional flexibility needed to support a broader range of query languages, data formats and data sources. It is designed to efficiently process nested data. It is a design goal to scale to 10,000 servers or more and to be able to process petabyes of data and trillions of records in seconds. Background == Many organizations have the need to run data-intensive applications, including batch processing, stream processing and interactive analysis. In recent years open source systems have emerged to address the need for scalable batch processing (Apache Hadoop) and stream processing (Storm, Apache S4). In 2010 Google published a paper called “Dremel: Interactive Analysis of Web-Scale Datasets,” describing a scalable system used internally for interactive analysis of nested data. No open source project has successfully replicated the capabilities of Dremel. Rationale = There is a strong need in the market for low-latency interactive analysis of large-scale datasets, including nested data (eg, JSON, Avro, Protocol Buffers). This need was identified by Google and addressed internally with a system called Dremel. In recent years open source systems have emerged to address the need for scalable batch processing (Apache Hadoop) and stream processing (Storm, Apache S4). Apache Hadoop, originally inspired by Google’s internal MapReduce system, is used by thousands of organizations processing large-scale datasets. Apache Hadoop is designed to achieve very high throughput, but is not designed to achieve the sub-second latency needed for interactive data analysis and exploration. Drill, inspired by Google’s internal Dremel system, is intended to address this need. It is worth noting that, as explained by Google in the original paper, Dremel complements MapReduce-based computing. Dremel is not intended as a replacement for MapReduce and is often used in conjunction with it to analyze outputs of MapReduce pipelines or rapidly prototype larger computations. Indeed, Dremel and MapReduce are both used by thousands of Google employees. Like Dremel, Drill supports a nested data model with data encoded in a number of formats such as JSON, Avro or Protocol Buffers. In many organizations nested data is the standard, so supporting a nested data model eliminates the need to normalize the data. With that said, flat data formats, such as CSV files, are naturally supported as a special case of nested data. The Drill architecture consists of four key components/layers: * Query languages: This layer is responsible for parsing the user’s query and constructing an execution plan. The initial goal is to support the SQL-like language used by Dremel and Google BigQuery ( https://developers.google.com/bigquery/docs/query-reference), which we call DrQL. However, Drill is designed to support other languages and programming models, such as the Mongo Query Language ( http://www.mongodb.org/display/DOCS/Mongo+Query+Language), Cascading ( http://www.cascading.org/) or Plume (https://github.com/tdunning/Plume). * Low-latency distributed execution engine: This layer is responsible for executing the physical plan. It provides the scalability and fault tolerance needed to efficiently query petabytes of data on 10,000 servers. Drill’s execution engine is based on research in distributed execution engines (eg, Dremel, Dryad, Hyracks, CIEL, Stratosphere) and columnar storage, and can be extended with additional operators and connectors. * Nested data formats: This layer is responsible for supporting various data formats. The initial goal is to support the column-based format used by Dremel. Drill is designed to support schema-based formats such as Protocol Buffers/Dremel, Avro/AVRO-806/Trevni and CSV, and schema-less formats such as JSON, BSON or YAML. In addition, it is designed to support column-based formats such as Dremel, AVRO-806/Trevni and RCFile, and row-based formats such as Protocol Buffers, Avro, JSON, BSON and CSV. A particular distinction with Drill is that the execution engine is flexible enough to support column-based processing as well as row-based processing. This is important because column-based processing can be much more efficient when the data is stored in a column-based format, but many large data assets are stored in a row-based format that would require conversion before use. * Scalable data sources: This layer is responsible for supporting various data sources. The initial
Re: [jszip-dev] Re: [mojo-user] [ANN] JSZip Maven Plugin 0.1-alpha-1 released
On Fri, Jun 1, 2012 at 4:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Yes, though jars don't work as well for packaging... let's drop the other mailing lists (left on BCC to let them know they are being dropped ;-) ) and move to just jszip-...@googlegroups.com On 1 June 2012 15:24, LeClaire Garvin garvin.lecla...@gmail.com wrote: I think there is also some overlap with the web jar repository (https://github.com/webjars/webjars.github.com) project Regards, Garvin LeClaire garvin.lecla...@gmail.com On Jun 1, 2012, at 10:19 AM, Christopher Hunt wrote: Hi Stephen, Not sure if you know, but the JS Import project (1) can already utilise zip files with a www classifier. The regular Assembly plugin can be used to make these packages. The following type of dependency declaration can then be made: dependency groupIdorg.codehaus.mojo/groupId artifactIdbootstrap-amd/artifactId version2.0.2-alpha-1/version classifierwww/classifier typezip/type /dependency In addition to this the following libraries are present on Maven Central via the MJS project (2): * almond * bootstrap * d3.js * jquery * jquery-mobile * jquery-ui * knockout.js * qunit Kind regards, Christopher (1) http://mojo.codehaus.org/js-import-maven-plugin/ (2) http://mojo.codehaus.org/javascript-maven-tools/index.html - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email -- You received this message because you are subscribed to the Google Groups JSZip Developers group. To post to this group, send email to jszip-...@googlegroups.com. To unsubscribe from this group, send email to jszip-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jszip-dev?hl=en. - 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: Accumulo incubator proposal: Statement of Concern
On Tue, Sep 13, 2011 at 04:34, Doug Meil doug.m...@explorysmedical.com wrote: re: overlap This is the there are multiple webservers in ASF counter-argument - except that ones that exist are in two different languages (Apache WS and Tomcat). The point I made in my email is that if a 3rd webserver showed up that was written in Java that copied a couple thousand lines of code from Tomcat, I would hope somebody would ask why. I thought I had some agreements from some folks on this thread, but you feel differently so we're going to have to disagree. This is not about feeling differently. There is no stealing of code or intellectual property, so as far as incubation is concerned this is a non-argument. Another example: Chukwa, Flume and Ambari. The're all incubating, with significant overlap in features and technical architecture. So what? If successful, some or all of them may become TLPs. I didn't notice similar turf-related complaints from those projects. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accumulo to join the Incubator
On Fri, Sep 9, 2011 at 18:22, Doug Cutting cutt...@apache.org wrote: It's been a week since the Accumulo proposal was submitted for discussion. A few questions were asked, and the proposal was clarified in response. Sufficient mentors have volunteered. I thus feel we are now ready for a vote. [X] +1 Accept Accumulo for incubation Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Other mentors for accumulo?
I've signed up myself, too. Bernd On Fri, Sep 9, 2011 at 03:10, Benson Margulies bimargul...@gmail.com wrote: On Thu, Sep 8, 2011 at 9:02 PM, Alan D. Cabrera l...@toolazydogs.com wrote: I can help. Would you please add yourself to the proposal on the wiki? Regards, Alan On Sep 8, 2011, at 11:12 AM, Benson Margulies wrote: Optimist that I am, I wonder if any of you would be willing to sign up to join me as a mentor on accumulo on the assumption that it is approved? - 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] Accumulo for the Apache Incubator
On Saturday, September 3, 2011, Adam P Fuchs adam.p.fu...@ugov.gov wrote: Hi Bernd, The latest stable release of Accumulo contains roughly 200,000 lines of code, of which about 85,000 are machine generated thrift code. Of the remaining code, about 15,000 lines are derived from other Apache projects, and about 1,500 of those are derived from HBase code. The code derived from HBase comprises a query caching layer (block cache, index cache, multi-level LRU logic, etc.). So, you are saying more than 10% of the non-generated code base (and you are not counting lib-style uses/JARs here, right?) is derived from other Apache code? That seems to be unusual. Just curious, could you elaborate a bit about why you did that amd what kind of code that is? Thank you. Bernd
Re: [PROPOSAL] Accumulo for the Apache Incubator
On Sun, Sep 4, 2011 at 18:16, Greg Stein gst...@gmail.com wrote: On Sep 4, 2011 3:41 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: ... So, you are saying more than 10% of the non-generated code base (and you are not counting lib-style uses/JARs here, right?) is derived from other Apache code? That seems to be unusual. Just curious, could you elaborate a bit about why you did that amd what kind of code that is? Thank you. You make it sound like deriving from our code base is a bad thing, and should be justified. I don't get it. That is what we *want* people to do. Of course, many do so. Especially in closed source projects we will never know about. What is your concern here? The concern would be when people would take code and re-incubate it at large scale, whatever that means. But Billies reply below is showing that they improved Hadoop code (like I hoped) and are willing to contribute back. (If the code grant is going through at all, it sounds like a little bit more complicated than usual.) Hadoop can only benefit from that. Also, I don't share the concerns discussed over at hbase-dev. How large the overlap between HBase and Accumulo really is can still be determined in Incubation. Whether or not they will become two different projects or one is something that would be decided later in Incubation. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accumulo for the Apache Incubator
On Friday, September 2, 2011, Billie J Rinaldi billie.j.rina...@ugov.gov wrote: Greetings, I would like to propose Accumulo to be an Apache Incubator project. Accumulo is a distributed key/value store that provides expressive cell-level access labels and a server-side programming mechanism that can modify key/value pairs at various points in the data management process. It is based on Google's BigTable design and runs over Apache Hadoop and Zookeeper. How is the project's relation to HBase? Especially, how much code - if any - in the Accumolo code base is directly taken from HBase? Thanks, Bernd Here is a link to the proposal in the Incubator wiki: http://wiki.apache.org/incubator/AccumuloProposal I've also pasted the initial contents below. Thanks, Billie Rinaldi = Accumulo Proposal = == Abstract == Accumulo is a distributed key/value store that provides expressive, cell-level access labels. == Proposal == Accumulo is a sorted, distributed key/value store based on Google's BigTable design. It is built on top of Apache Hadoop, Zookeeper, and Thrift. It features a few novel improvements on the BigTable design in the form of cell-level access labels and a server-side programming mechanism that can modify key/value pairs at various points in the data management process. == Background == Google published the design of BigTable in 2006. Several other open source projects have implemented aspects of this design including HBase, CloudStore, and Cassandra. Accumulo began its development in 2008. == Rationale == There is a need for a flexible, high performance distributed key/value store that provides expressive, fine-grained access labels. The communities we expect to be most interested in such a project are government, health care, and other industries where privacy is a concern. We have made much progress in developing this project over the past 3 years and believe both the project and the interested communities would benefit from this work being openly available and having open development. == Current Status == === Meritocracy === We intend to strongly encourage the community to help with and contribute to the code. We will actively seek potential committers and help them become familiar with the codebase. === Community === A strong government community has developed around Accumulo and training classes have been ongoing for about a year. Hundreds of developers use Accumulo. === Core Developers === The developers are mainly employed by the National Security Agency, but we anticipate interest developing among other companies. === Alignment === Accumulo is built on top of Hadoop, Zookeeper, and Thrift. It builds with Maven. Due to the strong relationship with these Apache projects, the incubator is a good match for Accumulo. == Known Risks == === Orphaned Products === There is only a small risk of being orphaned. The community is committed to improving the codebase of the project due to its fulfilling needs not addressed by any other software. === Inexperience with Open Source === The codebase has been treated internally as an open source project since its beginning, and the initial Apache committers have been involved with the code for multiple years. While our experience with public open source is limited, we do not anticipate difficulty in operating under Apache's development process. === Homogeneous Developers === The committers have multiple employers and it is expected that committers from different companies will be recruited. === Reliance on Salaried Developers === The initial committers are all paid by their employers to work on Accumulo and we expect such employment to continue. Some of the initial committers would continue as volunteers even if no longer employed to do so. === Relationships with Other Apache Products === Accumulo uses Hadoop, Zookeeper, Thrift, Maven, log4j, commons-lang, -net, -io, -jci, -collections, -configuration, -logging, and -codec. === Relationship to HBase === Accumulo and HBase are both based on the design of Google's BigTable, so there is a danger that potential users will have difficulty distinguishing the two or that they will not see an incentive in adopting Accumulo. There are a few key areas in which Accumulo differs from HBase. Some of the desired features of Accumulo could be incorporated into HBase, however the most important of these may be unlikely to be adopted (see cell-level access labels and iterators below). It is a possibility that the codebases will ultimately converge, but the number of differences at the current time warrants a separate project for Accumulo. Access Labels Accumulo has an additional portion of its key that sorts after the column qualifier and before the timestamp. It is called column visibility and enables expressive cell-level access control. Authorizations are passed with each query to control what data is returned to the user. The column
Re: [hms] HMS status page not build
Thanks. However, the name HMS may be changed before the project will hit the website. Bernd On Wed, Aug 31, 2011 at 14:33, Christian Grobmeier grobme...@gmail.com wrote: hehe :) It was not the question how it works - it was a reminder to the HMS people to generate and commit the page :-) Sorry for being confusing! On Wed, Aug 31, 2011 at 2:07 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi... Yes, you make the changes to the XML file of the podling or add it if it is a new one, then run build and then commit both the XML and HTML files :). On Wed, Aug 31, 2011 at 1:02 PM, Christian Grobmeier grobme...@gmail.com wrote: Hello, just updated the ognl page and saw that there is a new hms status page checked in, but the generated html is missing. Is is necessary to commit the html page too to be visible on the incubator website. I was not sure if the page is ready yet, so I did not do it - the HMS people may want to correct this :-) Cheers -- http://www.grobmeier.de - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://www.grobmeier.de - 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: A Spam ? (was: Re: You have been recruited to the Love/Avon Army of Women)
I don't remember seeing this in the moderation queue, so maybe we need to unsub someone if we see more posts like this. Bernd On Wed, Aug 31, 2011 at 15:19, Dennis E. Hamilton dennis.hamil...@acm.org wrote: It's a version of the Nigerian scam, but claimed to be from Ivory Coast. -Original Message- From: Mohammad Nour El-Din [mailto:nour.moham...@gmail.com] Sent: Wednesday, August 31, 2011 05:03 To: general@incubator.apache.org Subject: A Spam ? (was: Re: You have been recruited to the Love/Avon Army of Women) Hi All... Is that a Spam ? 2011/8/31 frank_kamar...@yahoo.fr frank_kamar...@yahoo.fr: frank_kamar...@yahoo.fr has invited you to the Army of Women website Assistance d'urgence. S'IL VOUS PLAAtilde;ŽT NOTE rAtilde;copy;ponse Atilde;nbsp; mon e-mail privAtilde;copy; CASE CI-DESSOUS frank_kamar...@yahoo.fr Atilde;nbsp; Abidjan, en CAtilde;acute;te d'ivoireWest afrique Bonjour Cher, Salutations Je souhaite demander votre aide dans une transaction financiAtilde;uml;re et je suis sAtilde;raquo;r que ce sera d'un avantage mutuelle. Je souhaite investir dans la production et de gestion immobiliAtilde;uml;re dans votre pays. J'ai hAtilde;copy;ritAtilde;copy; de la somme de six millions, USD (6,000,000.00 $) J'ai besoin de votre aide pour investir dans votre pays. Vous aurez juste a recevoir les fonds dans votre compte dans votre pays. Je serai heureux de vous donner au moins 15% de la somme totale pour votre aide. S'il vous plaAtilde;reg;t, il est important que vous me contacter je vous demande d'accepter de m ecrire un mot gentil dans mon email et je vous assure que je vous rAtilde;copy;pondrai . Voici mon email: frank_kamar...@yahoo.fr En attente de votre rAtilde;copy;ponse immAtilde;copy;diate et que Dieu vous bAtilde;copy;nisse. Cordialement FRANK KAMARA1. -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein - 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: [VOTE] Change the name of the HMS podling to Ambari.
On Wed, Aug 31, 2011 at 19:58, Owen O'Malley omal...@apache.org wrote: When I was doing the initial trademark search for HMS, I found that there are a lot of projects (including software) named HMS. It also has the problem of being very bad to search for (42.7m hits on google). Before I go through and create the infrastructure for Apache incubator, I wanted to discuss changing the name. Suhas did some searches and found that the name for the royal chair on top of elephants is Ambari, which seems like a very nice name to me. Toward that end, I'd like to propose changing the name from HMS to Ambari. +1 Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept HMS as an incubator project
On Fri, Aug 26, 2011 at 06:56, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: +1 (binding). G'luck guys! Cheers, Chris On Aug 25, 2011, at 1:57 PM, Devaraj Das wrote: Hello everyone, This is a vote proposing that HMS be accepted as a project in the Apache Incubator. HMS is monitoring, administration and lifecycle management project for Apache Hadoop clusters. The latest proposal is pasted at the end and it could be found in the wiki as well - http://wiki.apache.org/incubator/HMSProposal The related discussion thread is at: http://www.mail-archive.com/general@incubator.apache.org/msg30354.html [X] +1 Accept HMS for incubation (binding) Additionally, would you mind adding myself to the initial committers roster? Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Bluesky cleanup? (was: [RESULT][VOTE] Retire Bluesky Podling)
On Tue, Jul 19, 2011 at 11:10, Chen Liu liuchen0...@gmail.com wrote: Has Bluesky project been retired by ASF? I'm sorry, but: yes. Can we continue to release work? I'm not sure what you mean by release, but SVN will soon be closed for Bluesky. Bernd 2011/7/19 Chen Liu liuchen0...@gmail.com We are preparing for realese work right now. some mentors in ASF support our project and are willing to give us one more month to do this work. I think 2011/7/19 Bertrand Delacretaz bdelacre...@apache.org (dropping bluesky-dev) On Tue, Jul 5, 2011 at 9:30 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: ...The vote to retire Bluesky succeeds... Is anyone taking care of cleaning up BlueSky, deleting code from svn (I assume that's needed), closing mailing lists etc? -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
[RESULT][VOTE] Retire Bluesky Podling
Hi everyone, The vote to retire Bluesky succeeds with only +1 votes from Martijn, Emmanuel, Bernd, Niklas, Tommaso, Bertrand, Chris, Ralph, Christian, Noel, Luciano, Alan, Upayavira, Ross, Benson, Craig, Greg, William (binding) and Andreas Kuckartz, Kalle Korhonen, Henry Saputra (non-binding). Please review the tally and correct it if neccessary. Thanks for voting. I sincerly hope that Bluesky will nevertheless become open source somewhere in the OSS universe. Bernd On Tue, Jun 28, 2011 at 07:49, berndf ber...@apache.org wrote: Hi everyone, this is a vote to retire the Bluesky podling. 3.5 years into incubation, the podling has not made progress in terms of becoming an Apache project. Dev is still done behind closed doors, and developers are changing frequently without notifications on the public lists. Mentors are M.I.A. Reports are often late. No Apache release was every made. There were multiple attempts to reboot the podling (Thanks Luciano!) without much success. So now I'm calling a vote to end Incubation for Bluesky. The vote is open at least until 2011-07-02 12:00 UTC. [] +1, retire Bluesky for the time being [] -0/+0, I'm undecided [] -1, I will step up as a mentor, so let's give it another try Thanks for voting, 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
[VOTE] Retire Bluesky Podling
I don'tthink that a single mentor is nearly sufficient for this or any podling. Taking the feedback above and below in this thread into account, there seems few confidence if any that Bluesky will be able to become an Apache project. I'll close the vote, which sees no other votes than +1s ATM, on the 5th. Bernd On Friday, July 1, 2011, Noel J. Bergman n...@devtech.com wrote: Bill Stoddard wrote: I would like to see this vote suspended until we can get some feedback from Jack Cai re whether he is willing to be a mentor. I concur that we should suspend this vote pending the outcome of the project's attempt to reboot. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Bluesky calls for a new mentor!
On Thu, Jun 30, 2011 at 10:37, Christian Grobmeier grobme...@gmail.com wrote: I believe projects from school could also rock in Apache as well. You can look down up on us but you can't deny others. This is not the point. The point is, if you have contributors who have no apache id, they a) need to sign an ICLA b) need to create an Jira issue and attach an svn diff there, ticking the allowed to use for the ASF box c) need to ask development questions on the mailinglist, not by ICQ, MSN or whatever You can actually work with students, no problem. But it should happen visible. Even when you are in the same room, it should be visible to all other parties around the world. Otherwise you will never get an development community. I had a propose that community give us the last chance for 1-2month and certain member could become our mentor to lead us finish releasing the newest version. During this time slot. What you would see includes: I am not sure if the term mentor is used well here. A mentor is not here to help you in development questions. A mentors role is to oversee how the project progresses, guide people to work after the apache way. After 3 years you should already know about the apache way and mentor should be obsolet (from a teaching role only). A mentor is for sure NO project lead. He can point you to the according docs of how to release code, for example. 1. gradually increasing discussion in bluesky-dev mailing list. Meaningless discussion would not count. ALL discussion must happen on list, from now on. If it didn't happen on list, it didn't happen, as a wise man once said. 2. committing of source code after they were cleaned up. Inactive committers would be revoked and new committers would apply to join in. Now or never. It is commit then review Potential new committers must show their interest on the mailing list - otherwise your mentors cannot decide if they should support a invitation or not. As you know, new committers must be voted in. The discussion should also happen before, on list. 3. preparing for what release needs and make the release successful. Thus the new developers and committers could completely experienced the release process and know about How things are done in Apache community better. You should start working on the apache way even before the release. If it didn't work well before, it will not work well while releasing. If community accept my suggestion, individually, i want the BlueSky project under strict surveillance by community members. If we can't fulfill what we just promised, then just kick us out of here and i would have noting to say. I (personally) have no problems with waiting just another 2 or 3 months. I cannot imagine anyone would like to step up as a mentor at the moment. My suggestion: try to work out the apache way now. Use jira and the mailinglist. Students contribute patches through jira. Committers apply them. And so on. If that all happens, your Jira is full of contributions and your mailinglist full of discussions. If that is the case, come back to this list and ask for a mentor again - probably somebody is willling to step up again. We had this discussion multiple times over the last year. I firmly think, without immediate new mentors this project should not continue. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire Bluesky Podling
On Tue, Jun 28, 2011 at 07:49, berndf ber...@apache.org wrote: Hi everyone, this is a vote to retire the Bluesky podling. 3.5 years into incubation, the podling has not made progress in terms of becoming an Apache project. Dev is still done behind closed doors, and developers are changing frequently without notifications on the public lists. Mentors are M.I.A. Reports are often late. No Apache release was every made. There were multiple attempts to reboot the podling (Thanks Luciano!) without much success. So now I'm calling a vote to end Incubation for Bluesky. The vote is open at least until 2011-07-02 12:00 UTC. [X] +1, retire Bluesky for the time being Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Retire Bluesky Podling
On Tue, Jun 28, 2011 at 07:49, berndf ber...@apache.org wrote: The vote is open at least until 2011-07-02 12:00 UTC. I'll extend the voting period until 2011-07-05 so the project has some time to find new mentors. Bernd - 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)
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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Releases and IPMC votes
On Mon, Mar 14, 2011 at 09:33, ant elder ant.el...@gmail.com wrote: On Mon, Mar 14, 2011 at 8:13 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I was under the impression that *any* mentor is an IPMC member, has a binding +1 vote for releases and could therefore approve of releases without having to go through general@ While I find it very helpful and valuable for first time releases (and first time release managers) to go to general@ the first time, consecutive releases could go a lot smoother if Mentor votes were all that is required. The current policy states: Therefore, should a Podling decide it wishes to perform a release, the Podling SHALL hold a vote on the Podling's public -dev list. At least three +1 votes are required (see the Apache Voting Process page). If the majority of all votes is positive, then the Podling SHALL send a summary of that vote to the Incubator's general list and formally request the Incubator PMC approve such a release. Three +1 Incubator PMC votes are required. So there's not much leeway here. Although the three +1 incubator PMC votes are often already satisfied. Martijn There have been numerous releases where we have not followed exactly that process, two other common approaches these days seem to be: - the email to general@ says they already have three IPMC +1 votes on the poddling dev list, there may or may not be comments on the general@ thread and the release is done anyway after 3 days - the initial vote email is CC'ed to both the poddling dev list and general@ and the vote result is tallied from both lists and there may or may not have been votes on general@ Both of those approaches seem ok to me and I'd be fine with a simpler and more flexible policy, perhaps saying that the main thing is that general@ must be notified. All PMC members have binding votes - means, they can be -1 on a particular release. I'd appreciate if more PMC members would review releases for projects they don't mentor (however I myself do fail miserably at this). (Let's remember that before mentors were formally established, all releases were ratified on general@ only and much Incubation work happened here.) So making release votes visible on general@ early can only increase overall release quality and give the whole PMC an opportunity to exercise oversight. One could also argue that binding release votes are required to happen on general@. However, in the past this led to stale votes, which does not serve the incubating projects. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Wave into the incubator
On Tue, Nov 30, 2010 at 07:52, Dan Peterson dpeter...@google.com wrote: Hi everyone, Please vote on the acceptance of Wave into the Apache incubator. The proposal is available at: http://wiki.apache.org/incubator/WaveProposal (for your convenience, a snapshot is also copied below) The earlier discussion thread can be found at: http://apache.markmail.org/message/3ebtccdxvipp2732?q=general%40incubator.apache.org+list:org.apache.incubator.general+order:date-backwardpage=2 The vote options: [X] +1 Accept Wave for incubation Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Fri, Nov 26, 2010 at 01:35, Niclas Hedhman nic...@hedhman.org wrote: On Wed, Nov 24, 2010 at 1:26 PM, Greg Stein gst...@gmail.com wrote: Simple review: the original email was sent by Dan Peterson from his google.com address. I imagine that if Google had a problem with it, then he wouldn't be working there tomorrow :-D ... or if this was some kind of spurious one-guy-goes-batshit-crazy, then how could he line up so many people? And sure, while you couldn't know this, Dan is a great guy. I worked with him while at Google. This proposal is straight-up. My simple point is: please accept proposals at face value rather than pushing back with paranoid thoughts about malfeasance on the part of the people wanting to join our efforts here at the ASF. Yet, we have in the past had similar situations, where we have not allowed this kind of position. In the end, you are now encouraging that Apache WAVE, Google WAVE and Niclas WAVE are totally fine, possibly not the same thing. LucidImagination is told that LucidWorks for Lucene is a proper 'association' back to the Apache project. Shouldn't they (in the same spirit) then be allowed Lucid Lucene as well? Didn't we require Yahoo TrafficServer to assign trademark, or we would change the name? Doug Cutting assign trademark to Lucene? Although I agree with you, Greg, that if Google has a problem, this is likely not happening. My point is the reverse; If we allow Google Wave, Niclas Wave and so forth, we need to allow this for the Lucenes, Hadoops and TrafficServers as well, otherwise 5 years down the line, you need to go researching each and every projects history to figure out how derived products may call themselves. I think it severely complicates Trademark policies and blurs our definitions. -1 to the proposal as it stands with this name and 'Google retains the trademark Google Wave' In general I agree with Niclas. This clause should be removed. I seem to recall podlings where the donating company was required to transfer trademarks, but don't remember exactly which podling/project it was. I wouldn't stop the proposal, though. This can be identified as an issue to be solved in Incubation - either by changing the name away from 'Wave' or by transferring marks or even by determining that none of both is required. Bernd PS: It would've been much better to first [DISCUSS] the proposal before putting it up for vote. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Fri, Nov 26, 2010 at 12:26, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Fri, Nov 26, 2010 at 12:07 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: PS: It would've been much better to first [DISCUSS] the proposal before putting it up for vote. I don't see a [VOTE] here. Ooops, you're right. - Well, in this case, I vote +1. Bernd /me goes cleaning glasses - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] real-time communications
On Wed, Nov 24, 2010 at 22:34, Siegfried Goeschl siegfried.goes...@it20one.at wrote: Hi folks, could you stop believing in a conspiracy taking place at the Apache Isis incubator project where a bunch of Isis member plus a few obscure mentors are trying to subvert the Apache Software Foundation by having a Skype session?! I don't think anyone believes in such a conspiracy. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ISIS] Re: Conference call
On Mon, Nov 22, 2010 at 16:16, Benson Margulies bimargul...@gmail.com wrote: I am nothing if not chronically disingenuous. My first concern in responding here is a process concern. As far as I can tell, the Incubator PMC has not formally voted to forbid the use of real-time communications in podlings. Absent such a vote, the use of these technologies is permitted, and it's up to the mentors to guide, monitor, and ring alarm bells, as needed. Concluding that in the absence of a vote everything is allowed is not correct. There is a lot of unwritten, conventional law at Apache which has never been subject to a vote but is nonetheless part of how-it-works. That's the hard thing about Apache - you have to be part of the community for a substantial amount of time to know how it really works. Sadly, there is no such thing as a manual Apache in 14 days. My recommendation: Skip the conf calls - it's a waste of time -, and start with email communication right away. Reason: If there's only one person not on the call, the whole discussion from the conf call will happen again asymptotically on the mailing list (...as I said on the conf call...). Also, call transcripts (... as we decided on the conf call...) minutes tend to sound binding (and people on the call think they are) when really they aren't, which can lead to frustration. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ip-clearance voting
On Wed, Nov 17, 2010 at 00:32, Christopher Brind bri...@brindy.org.uk wrote: Hi, I've been following gene...@incubator for a while and have a question. When there's a vote on ip-clearance why would one vote against it? Presumably one would only vote against it if someone knows some reason why the codebase cannot be accept for legal reasons, and not for any technical reason, is that correct? That is correct. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Proposal document for JXTA Migration to ASF under name Chaupal
Hi Jerome, Any reason why you didn't follow Incubator process as Bertrand suggested? We'd be happy to get feedback to know where our documentation[1] is unclear or lacking detail. The mailing list archive is also full of best practices of successful incubation requests. Thanks, Bernd [1] http://incubator.apache.org/incubation/Incubation_Policy.html On Sun, Nov 7, 2010 at 21:09, Jérôme Verstrynge jvers...@gmail.com wrote: Please find our proposal for discussion in attachement. We need a Champion. Thanks, Jérôme Verstrynge On 28/10/2010 3:54, Bertrand Delacretaz wrote: Hi, On Thu, Oct 28, 2010 at 5:19 AM, Jérôme Verstryngejvers...@gmail.com wrote: ...We have not received an answer to this email. Is there anyone following up on these requests? Is there something special we need to perform/deliver?... You can submit your proposal for discussion at http://wiki.apache.org/incubator/ already, even if you don't have a champion or mentors yet. That might help in getting people interested. -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: [VOTE] Kitty to Enter the Incubator (was PROPOSAL)
No hurry. Please, do us all favor and start a new thread for a vote, unless you really don't want to receive any votes. I can't find the proposal on the wiki either. Many thanks, Bernd On Wed, Sep 15, 2010 at 00:57, Matthew Sacks matt...@matthewsacks.com wrote: Changing subject to VOTE On Sep 8, 2010, at 11:29 PM, Pid wrote: On 09/09/2010 07:15, Greg Stein wrote: Just to clarify: I'm assuming you're saying +1 to the proposal, rather than to my comment. Correct? +1 indeed, to the proposal +1 actually, to the mailing list comment, too. The Incubator PMC might consider that establishing sufficient interest which requires a user list is an indicator of a project approaching the exit criteria, or at least, making substantial progress. p And to clarify for myself: I have no opinion on the proposal itself. I timed out after Java and the next few buzzwords. Thankfully, this proposal didn't say framework or I may have timed out after the first :-P ... my comments were focused on the community aspects around mailing list management, and successfully growing a lively and sustainable critical mass. Cheers, -g On Thu, Sep 9, 2010 at 02:06, Pid p...@pidster.com wrote: +1 (non-binding) Small point: if a Mentor must be a Member, I can't be one, because I'm not. p On 08/09/2010 16:00, Mohammad Nour El-Din wrote: +1 (Notbinding) On Wed, Sep 8, 2010 at 7:22 AM, Greg Stein gst...@gmail.com wrote: On Tue, Sep 7, 2010 at 20:29, Matthew Sacks matt...@matthewsacks.comwrote: ... *Mailing Lists* kitty-dev kitty-commits kitty-user Is there a large user community already? If not, then splitting the community across dev/user does not make sense. You want to keep the users and developers on the same mailing list until one starts to overwhelm the other. By partitioning the lists too early, you risk never reaching critical mass on *either* mailing list. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org 0x62590808.asc - 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] ALOIS to enter the incubator
as soon as you come up with 2 more mentors, you have my +1. Bernd On Thu, Aug 26, 2010 at 18:09, Urs Lerch m...@ulerch.net wrote: Hi, I would like to call a vote for accepting ALOIS for incubation in the Apache Incubator. The full proposal is available below and on the proposal wiki page (http://wiki.apache.org/incubator/AloisProposal). We ask the Incubator PMC to sponsor it, with Scott Deboy volunteering as Champion and Mentor. Additional mentors are warmly welcome. Please cast your vote: [ ] +1, bring ALOIS into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring ALOIS into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thanks, Urs = Preface = ALOIS is a log collection and correlation software with reporting and alarming functionalities. It has been implemented by the Swiss company IMSEC for a customer about five years ago. GPL-licenced, implemented in Ruby and completely based on other OSS-licensed components, it was designed for the open source community right from the start. Now that the software has shown its functioning over several years in production with the one customer and one IMSEC-internal installation, it seems to be the right time to open it to a wider community. = Abstract = ALOIS stands for „Advanced Logging and Intrusion Detection System“ and is meant to be a fully implemented open source SIEM (security information and event management) system. = Proposal = While almost all other SIEM software, be it closed or open source, concentrate on the technological part of security monitoring, ALOIS is aimed to monitor the security of the content. It intends to be pro-active in the detection of potential loss, theft, mistaken modification or unauthorized access. ALOIS works on log messages and thus contains all the basic functionality of a conventional SIEM, as centralized collecting, normalizing, aggregation, analyzing and correlating of all log messages, as well as reporting all security related events. Therefore it can be used as any other SIEM. ALOIS consists of five modules interacting to ensure a scaleable functionality of a SIEM: * Insink is the message sink, which is the receiving entry point for all the different log messages into ALOIS. It is partly based on the syslog-ng software. Insink listens for messages (UDP), waits for messages (TCP), receives message collections (files, emails) and pre-filters them to prevent from message flow overload. * Pumpy is the incoming FIFO buffer, implemented as a relational database tables. which contain the incoming original messages (in raw format). In a complex system setup, there may be several insink instances, e.g. for a group of hosts, for specific types of messages, or for high-avaliablity. * Prisma contains logic to split up the text of log messages into separate fields, based on regular expressions. Actually, prisma is a set of prismi, each one prisma for one type of log message (apache, cisco etc. Several prismi can be applied to the same message. This allows for stacked messages, i.e. forwarded log messages contained in compressed files contained in e-mail messages. The data retrieved form the log messages is stored in a database called Dobby. Due to prisma being written in Ruby, prismi can be applied interactively (when having system access). * Dobby is the central log database. It should be separated from the Pumpy database for availability and performance reasons. The current implementation is based on MySQL. * The Analyzer contains the two sub-systems Lizard and Reptor. Lizard is the analysis engine and user interface of ALOIS, implemented in Ruby on Rails using AJAX. It allows for interactive browsing through the collected data, exclusion/inclusion/selection of data, data sorting, data filtering, creation of views, ad-hoc textual and graphical reporting. Reptor allows for automatic activation of views and comparison of these views' results to a predefined result (pattern matching). In case of mismatch, Reptor sends the result to predefined e-mail addresses. Its modular design guarantees ALOIS to scale from little to large organizations. Since there exists a Debian package, it's easy to build a test system or even a productive system for small environments. Although the software has been in productive use for a few years, there is still a lot of desired functionality missing. The plugability of new connected systems is given, but needs some revision. It is a given goal of the project to allow modules in other programming language. Furthermore, it has been discussed if parts of the existing implementation may be replaced with other proven open source software, e.g. the correlation engine or the web frontend. The other way round, it has been discussed that the filter creation engine would make a good tool
Pls. add me to Incubator group
Hi, can someone with proper karma please add me to the Incubator group. Thanks, Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT 2nd try][VOTE] Move Chukwa to incubator
Ok, let give this a second try: I count the following +1: Chris Mattmann, Alan Cabrera, Bill Rowe, Bernd Fondermann (all binding), Owen O'Malley (in process of being added to Incubator PMC) Greg Reddin, Jerome Boulon, Leif Hedstrom (non-binding). There were no other explicit votes cast. However, some discussion about going directly to TLP. Please note that the Hadoop previously voted -1 for letting Chukwa propose for TLP. Please check the vote result and speak up now if you disagree with the tally and making this vote effective. (Ideally, create new thredads.) Thanks, Bernd On Mon, Jun 21, 2010 at 19:29, Eric Yang ey...@yahoo-inc.com wrote: Please vote as to whether you think Chukwa should move to Apache incubator. The proposal is posted at: http://wiki.apache.org/incubator/ChukwaProposal Thanks Regards, Eric - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Result][Vote] Move Chukwa to incubator
Just a second. (Dropping TO gene...@hadoop.a.o.) Please don't confuse DISCUSSION and VOTE. BTW, it's best practice for a Incubator proposal (or any other type of initiative at Apache) to first have a DISCUSSION or PROPOSAL thread, and then have a vote afterwards, when thread hijacking is less likely. On Wed, Jun 30, 2010 at 18:42, Eric Yang ey...@yahoo-inc.com wrote: Original incubator proposal: http://wiki.apache.org/incubator/ChukwaProposal Vote put forward to incubator: 1. recommend TLP with guides to help the initial pmc, 2. accept incubating with tlp resource naming, but -incubating release naming 3. accept incubating requiring all incubator naming conventions, that might help the incubator simplify this decision. The original vote was about said proposal, not about options. You are tallying a vote that did not take place. Result of the vote: Option 1) Ant Elder, Eric Yang, William A. Rowe Jr. Option 2) Ari Rabkin, Jerome Boulon, Chris Douglas, Greg Reddin Option 3) Bernd Fondermann You seem to have missed a number of votes. Could you please identify binding votes for a proper tally? Owen O'Malley +1 on proposal I am not sure about Chris Mattmann¹s position, but he raised the question about TLP. Is it ok to keep hadoop naming until we graduate to TLP, hence, we only rename once? ³-incubating² will be added to release artifacts. What is next? IMHO, Either Hadoop decides to run a TLP movement, or the Incubator conducts a proper vote. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Move Chukwa to incubator
On Thu, Jun 24, 2010 at 21:21, William A. Rowe Jr. wr...@apache.org wrote: On 6/23/2010 8:12 AM, Bernd Fondermann wrote: On Wed, Jun 23, 2010 at 14:45, ant elder ant.el...@gmail.com wrote: IMHO we should insist on using the incubator naming for the Chukwa website/svn/MLs because I think Chukwa should just go directly to a TLP and if they have to use the incubator naming it may help them decide that the direct to TLP route really is better ;-) I see you blinking here, so I guess this is not just for putting up a strawman ;-) Well folks, it's a fun debate and all, but it isn't helping bring this vote to a conclusion :) Wasn't the debate started just for the sake of hijacking the vote thread? ;-) Seriously, [DISCUSS] before [VOTE] is always recommended. Is anyone in agreement with ant? Otherwise we should just move ahead and can hold a separate vote on allowing tlp resource creation at this time. If the proposers want (Eric?) a three choice vote, 1. recommend TLP with guides to help the initial pmc, 2. accept incubating with tlp resource naming, but -incubating release naming, or 3. accept incubating requiring all incubator naming conventions, that might help the incubator simplify this decision. I don't understand. The Hadoop community released a subproject for Incubation. The Incubator accepts or denies the proposal. In case of denial, the ball is in the Hadoop field again isn't it? At this point, I personally guess that 1. might be the most sensible in terms of resource creation and management; it would simply require the group to vote for an initial chair/VP. Who is the group? The list of initial committers? This PMC? The Hadoop PMC? If they are unsure of their group yet, perhaps one of the other mentors would offer to serve as their chair for the first six months, if they rather would do that? I'm still +1 to do proper Incubation. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Move Chukwa to incubator
On Wed, Jun 23, 2010 at 07:54, Eric Yang ey...@yahoo-inc.com wrote: Besides DOAP file and the incubator nomenclature, I may need help identify the addition responsibilities for Apache PMC. One problem, Chukwa community did not have a vote for PMC Chair because we are not sure what is the right process for this. Meanwhile, I have been writing quarterly report like any other Apache project, only recipient of the report is different. Chukwa releases have been voted by Chukwa community which is similar to Hadoop releases, and managed incremental changes using patches and committers. Code audit has been performed by the committers to ensure we don't bring in license incompatible libraries into Chukwa. Owen O'Malley had trained us these procedures roughly two years ago, and we have been executing the same process ever since. This translate for me into: Chukwa didn't have proper oversight by a PMC (a committee that is, not a single person) at Hadoop. Incubation would fix this using established processes. I think this is the right track, and the people involved, including the Hadoop PMC, ultimatively did the right thing. (Except for not simply growing the Hadoop PMC over time to include committers from every product.) Chukwa has a community of exist user base of 35 people. It would be nice to make Chukwa a special case to skip incubator nomenclature. This would ease the migration path for the existing Chukwa community. Ok with me, at least as far as MLs or SVN are concerned. However, Chukwa must be aware that it is changing PMCs from Hadoop to Incubator. So different rules might apply, like marking release artifacts as -incubating. Let's gather some more feedback on this. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Move Chukwa to incubator
On Wed, Jun 23, 2010 at 14:45, ant elder ant.el...@gmail.com wrote: On Wed, Jun 23, 2010 at 9:53 AM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: On Wed, Jun 23, 2010 at 07:54, Eric Yang ey...@yahoo-inc.com wrote: Besides DOAP file and the incubator nomenclature, I may need help identify the addition responsibilities for Apache PMC. One problem, Chukwa community did not have a vote for PMC Chair because we are not sure what is the right process for this. Meanwhile, I have been writing quarterly report like any other Apache project, only recipient of the report is different. Chukwa releases have been voted by Chukwa community which is similar to Hadoop releases, and managed incremental changes using patches and committers. Code audit has been performed by the committers to ensure we don't bring in license incompatible libraries into Chukwa. Owen O'Malley had trained us these procedures roughly two years ago, and we have been executing the same process ever since. This translate for me into: Chukwa didn't have proper oversight by a PMC (a committee that is, not a single person) at Hadoop. Incubation would fix this using established processes. I think this is the right track, and the people involved, including the Hadoop PMC, ultimatively did the right thing. (Except for not simply growing the Hadoop PMC over time to include committers from every product.) Chukwa has a community of exist user base of 35 people. It would be nice to make Chukwa a special case to skip incubator nomenclature. This would ease the migration path for the existing Chukwa community. Ok with me, at least as far as MLs or SVN are concerned. However, Chukwa must be aware that it is changing PMCs from Hadoop to Incubator. So different rules might apply, like marking release artifacts as -incubating. Let's gather some more feedback on this. Most projects that come to incubate would likely prefer to go straight to the TLP naming. Sure they'd prefer to. Terminating the Incubator would be worth its own thread, though. The last time i recall this came up was here: http://apache.markmail.org/message/ifinvq7wqmeoo5ix ... which is in the context of Subversion. Subversion is on the other end of incubating projects, coming from their own solid standalone ASF-like foundation. IMHO we should insist on using the incubator naming for the Chukwa website/svn/MLs because I think Chukwa should just go directly to a TLP and if they have to use the incubator naming it may help them decide that the direct to TLP route really is better ;-) I see you blinking here, so I guess this is not just for putting up a strawman ;-) Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Move Chukwa to incubator
On Mon, Jun 21, 2010 at 19:29, Eric Yang ey...@yahoo-inc.com wrote: Please vote as to whether you think Chukwa should move to Apache incubator. The proposal is posted at: http://wiki.apache.org/incubator/ChukwaProposal It's best practice to post the full proposal to the list, to have a snapshot archived. Chukwa Proposal Abstract Chukwa is a log collection and analysis framework base on Hadoop Map/Reduce. Proposal Chukwa will develop a open source data collection system for monitoring large distributed systems. Chukwa is built on top of the Hadoop Distributed File System (HDFS) and Map/Reduce framework and inherits Hadoop’s scalability and robustness. Chukwa also includes a flexible and powerful toolkit for displaying, monitoring and analyzing results to make the best use of the collected data. Background Apache Hadoop, lacks a good procedure to monitor and troubleshoot large distributed systems. Chukwa was initially developed at Yahoo Inc headed by Mac Yang, Sunnyvale in 2008. Chukwa was designed as a reference implementation for monitoring large distributed system on top of Hadoop. Since 2009 major parts of the development comes from Internet community contribution. Chukwa is current a Hadoop subproject. Rationale The maintainers and developers of Chukwa are interested in joining the Apache Software Foundation top level project for several reasons: * Apache provide a great community for open source software development environment. * It might open the door for sharing ideas or cooperation with other Apache projects, such as Avro and Hadoop. * Chukwa would like to benefit from Apache's infrastructure. Initial Goals Though the bulk of Chukwa initial development is complete and the framework is running stable, there are still some large areas for future development. Some area we hope to focus on in Apache: * Improve Chukwa Demux map/reduce Job * Refine automated log analysis algorithms * Remove dependency on relational database for reporting Current Status Meritocracy The initial developers are very familiar with meritocratic open source development, both at Apache and elsewhere. Apache was chosen specifically because the initial developers want to encourage this style of development for the project. Community Chukwa is used in many organization which are interested in the advancement of the Chukwa development. Many of these have at least one developer that joined the Chukwa mailing list and so the mailing list is the most important communication platform. The Chukwa community encourages suggestions and contributions from any potential user and developer. Core Developers The initial set of Chukwa committers includes folks from the Hadoop communities. We have varying degrees of experience with Apache-style open source development. Alignment Chukwa is a framework for Apache Hadoop. This is why Apache Hadoop is the most important dependency for Chukwa. And Chukwa is also a particularly good fit for Apache due to integration potential with other projects specifically Avro and Log4j. Known Risks Orphaned products Most of the active developers would like to become Chukwa Committers or PMC Members and have long term interest to develop/maintain and use the code. Inexperience with Open Source Chukwa was started as an open source contribute project to Hadoop in 2008. Many of the committers have experience working on open source projects and there are also at least one developer which has experience as committer on other Apache projects. Homogenous Developers As mentioned above, the current list of committers includes developers from at least two different companies plus many independent volunteers. Reliance on Salaried Developers At this time, many of the code comes from different companies like RAD Lab. Because RAD Lab is a research facility, many of the work is done by students working on their diploma thesis. Relationships with Other Apache Products At this time, the only dependency to other Apache projects is Apache Hadoop. When dependency on relational database is removed, Avro will become the standard serialization framework for Chukwa. A Excessive Fascination with the Apache Brand The Chukwa project exist quite successful on their own and could continue on that path with no problems at all. We expect the Apache top level project brand could help to increase the visibility of the project and so maybe more developers could be interested in the project. Documentation * The existing project page could be found here: http://hadoop.apache.org/chukwa * The Chukwa Architecture: http://hadoop.apache.org/chukwa/docs/current/design.html * The Chukwa mailing list with archive: http://hadoop.apache.org/chukwa/mailing_lists.html Initial Source Source and Intellectual Property Submission Plan The complete Chukwa code is under Apache Software License 2. The complete codebase is already hosted in ASF Repository. External
Re: [VOTE] Move Chukwa to incubator
On Mon, Jun 21, 2010 at 23:37, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 6/21/2010 12:29 PM, Eric Yang wrote: Please vote as to whether you think Chukwa should move to Apache incubator. The proposal is posted at: http://wiki.apache.org/incubator/ChukwaProposal +1 +1 Added myself as a mentor. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Move Chukwa to incubator
On Tue, Jun 22, 2010 at 09:42, ant elder ant.el...@gmail.com wrote: On Mon, Jun 21, 2010 at 8:09 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 6/21/2010 1:31 PM, Owen O'Malley wrote: On Jun 21, 2010, at 11:06 AM, Mattmann, Chris A (388J) wrote: Chukwa has been around for a while now and from my (albeit limited) impression, pretty successful. What's the rationale for going the Incubator route rather than putting up a Board TLP resolution? Just wanted to check, thanks guys! The problem is that none of the Chukwa PMC members have been on any Apache PMCs before. My belief is that having training wheels for a bit would be a good thing. And the podling's committee itself seeks the extra guidance as they become a self-managing committee, so the mentors all agreed with this proposal. If anything, it makes checking off the graduation matrix much simpler as they are already committers, we already have the IP vetting when the code came into Hadoop. We should obviously re-review the grants and trademark assignments during incubation. I'm not totally convinced by that reasoning, wouldn't it be simpler to just go directly to TLP and have those listed here as mentors agree to help out by being on the initial PMC? Maybe simpler, but better? I've only been involved in this process since yesterday or so, but I trust those who set out going the Incubator road. And the project doesn't loose anything with following it, even if it's a detour. The Incubator has more eyeballs than any other PMC and has tools to prepare projects to go TLP. We have far more projects eager to go TLP ASAP without properly preparing their PMCness than those openly saying we want to learn how to do it right first. If it does incubate what would be delaying its graduation? Its already got everything we list in the incubator docs - diverse committers, done several releases etc. IIUC, the only issue right now is that the committers are hesistant to go TLP because they've never been on a PMC before. The current proposal doesn't use the incubator naming for the mailing lists and svn location, from past discussions here it should really be using the incubator naming unless its a very special case. Is this a special case? Good catch. I think the Incubator nomenclature should apply to Chukwa as well. Bernd - 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 Mon, Mar 22, 2010 at 16:49, Donald Whytock dwhyt...@gmail.com wrote: Okay, getting back into this. Offering to mentor? Have I your permission to add you to the proposal in that capacity? Yep. I would not be averse to this project being attached to a bigger project. Did you have a particular one in mind? Nope. Bernd - 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 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
On Tue, Mar 2, 2010 at 00:43, 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. 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. 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/) If you'd want to test against a local server, I recommend using Vysper (http://svn.apache.org/viewvc/mina/sandbox/vysper/trunk/). Bernd 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
Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders
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 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
Re: Droid IP clearance?
On Mon, Feb 22, 2010 at 20:51, Doug Cutting cutt...@apache.org wrote: Thorsten Scherler wrote: The initial code was based on Apache Nutch so all the IP were cleared there. The modification that have been done by myself are all done as ASF committer. There have been code adopted from Henri Yandell patch to HttpComponents which as well had been cleared by himself as ASF committer. The second version was a rewrite from various ASF committer or based on patch submission where we have a software grant. IMOH there are (and never have been) no issues about IP clearance but ATM AFAIK there is no-one actively pursuing the matter. Any help highly appreciated. It sounds like there are in fact no Droid IP clearance issues. Perhaps IP clearance was only mentioned as an issue in the board report because it had not yet been explicitly addressed by the podling? Thanks, Doug +1. Now, we have a complete breadcrump of the code's various stations in our ML archives. That's good. 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: [VOTE] Release UIMA 2.3.0-rc9
On Thu, Jan 21, 2010 at 21:08, ant elder ant.el...@gmail.com wrote: It is quite huge. I haven't looked at every artifact but the ones i did all the licensing etc looked ok and it looks like they understand what they're doing. The copyright in some NOTICE files is Copyright 2006, 2007 which could probably do with being updated, though others are 2009 and from the discussion on legal-discuss a while back i'm not sure thats a blocking issue so +1 from me. AFAIR, copyright notices in file headers only need to be brought up-to-date (literally) when a file is actually changed. Bernd ...ant On Thu, Jan 21, 2010 at 10:13 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, Jan 18, 2010 at 2:48 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Others, please review and vote! The release is pretty complex so it's a bit of work to review it, but it would be great if at least two other IPMC members could spare some time on this. Anyone? BR, Jukka Zitting - 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: Handling of Traffic Server Trademark
On Tue, Jan 19, 2010 at 03:50, Noel J. Bergman n...@devtech.com wrote: Leif Hedstrom wrote: Traffic Server would like to resolve the TradeMark issues. Who would be able to make this call? snip/ Does anyone else have an opinion? Please do offer it. :-) There's a third option: Rename the project. Has this been discussed already? Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
On Wed, Dec 2, 2009 at 18:48, Bhuvaneswaran A bhu...@apache.org wrote: Here's a query related to publishing api docs for Subversion project periodically. We tend to update the api docs generated using doxygen and java doc on a nightly basis. We are evaluating a workaround to publish it periodically. Based on investigation I did so far, most of projects namely apr, hadoop, jakarta seem to place the apidocs in site/ area, not updated periodically though. As our use case is to update periodically, we wouldn't want to commit the auto generated docs in asf repository often. Considering these aspects, here's what we are planning to do: Setup a Hudson job in hudson.zones.apache.org farm that would generate the documentation using doxygen and javadoc. This can be setup to run periodically, may be once a day or once a week. Then, push the documentation files to people.apache.org into one of our accounts using SCP plugin that is already available in Hudson. We may use a passphrase/keyfile for authentication. Please shed some light if this is not the right approach, and/or if you could suggest a better/alternate approach, that would be helpful. -- Regards, Bhuvaneswaran A www.livecipher.com GPG: 0x7A13E5B0 - 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: About Podling Releases
On Tue, Sep 8, 2009 at 12:30, Gurkan Erdogducgurkanerdo...@gmail.com wrote: Hi; I would like to specify some concerns about podling release procedure. As an experienced podling releaser guy from the OpenWebBeans podling , it takes too much days to release internal milestones of the project. I know that podling mentors/committers may delay to VOTE because of doing other business stuffs. But I think that podling releasing is also very important. With delayed releases, we are not able to attract and diverse our community. I wonder is that how can we improve podling release process to decrease this time duration? My proposal is to decrease positive IPMC and PPMC VOTE numbers to 1 instead of 3. Moreover, maybe it is reasonable to add silence consensus on podling releases. One can also think that getting positive votes from podling committers are enough to release without getting IPMC votes. Mmhh. These are all mandatory rules to release as a proper Apache project, which the Incubation is to teach to the podlings. So I don't think it would be helpful or possible to relax those rules. Knowing how to do proper releases is considered by many the main exiting criteria. Is there any other podlings that are suffering from release procedures? I'm sure there are. WDYT? I don't know your particular project's situation, but here are some suggestions to streamline the release process: + Get more mentors onboard, which really care for your project and provide prompt feedback. + Set a deadline for the vote (a vote must run for at least 72 hours, longer is ok.) + Send a reminder 1 day before the vote runs out HTH, Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Tue, Aug 18, 2009 at 17:53, ant elderant.el...@gmail.com wrote: For a while now on general@ we've had people come along during a poddling release votes and raise issues about things that aren't backed up by clear ASF policy or reasonably obvious consensus in behaviour of existing TLPs. Often poddlings just buckle and do a respin as thats easier than debating the point and that has caused the raised issues to be misunderstood as a real problems and it becomes a sort of defacto policy. I don't think we should be blocking poddling releases based on the whims of who ever happens to be active at the time on gene...@. I'd rather see people speaking up, so (potential) issues can be discussed and resolved than people not reviewing release candidates at all, not caring for the project - or even worst - rubberstamping releases with their +1s without even taking a closer look at the release artifacts, for example by judging from the release vote thread, everything looks ok, so here's my +1. Keep whiming! ;-) Its causing lots of frustrations and doesn't make us look particularly smart. Are we? Anyone who easily gets frustrated with objections and confrontations should not be here at the Incubator anyway, that's my advice. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Does an incubation proposal require a codebase?
On Fri, Aug 7, 2009 at 07:55, Noah Slaternsla...@apache.org wrote: Hey, I am thinking about making an incubation proposal for a project I've been wanting to do for a while now. I have list of initial committers and a technical architecture proposal, but no actual code yet. Moreover, in order to provide a seed to grow and ground discussions on technical levels, the ASF incubation rules require the podlings to join the incubation process with an established and working codebase. - http://labs.apache.org/bylaws.html I checked the incubation rules, but couldn't find any mention of this rule. Our hopes were that we could start from scratch as a podling, and grow the code along with the community. Is this going to be possible? You are talking about the Incubator, but referencing the Labs bylaws. Maybe that's what's confusing you. Here's a quick summary what's possible at the ASF: Incubator: Come from the outside with a project (code + community) Labs: Start from scratch (without code nor community) There's a third way: Go to a project which might like your idea and request a sandbox (no code but community). A way of organizing a project having code but without community is left for a (private) exercise. ;-) Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Does an incubation proposal require a codebase?
On Fri, Aug 7, 2009 at 10:24, Noah Slaternsla...@apache.org wrote: On Fri, Aug 07, 2009 at 10:09:49AM +0200, Bernd Fondermann wrote: On Fri, Aug 7, 2009 at 07:55, Noah Slaternsla...@apache.org wrote: Moreover, in order to provide a seed to grow and ground discussions on technical levels, the ASF incubation rules require the podlings to join the incubation process with an established and working codebase. [...] You are talking about the Incubator, but referencing the Labs bylaws. Maybe that's what's confusing you. Nope, I don't think so. The bit that I quoted was from a Labs document, but was talking about rules for the Incubator. I am confused because I can't find anything in the Incubator rules about this. So I'm wondering if this is an omission, or if the Labs document is in error. Labs has no say 'bout what's happening at the Incubator but could be anticipating what's unwritten policy at the Incubator. Incubator: Come from the outside with a project (code + community) We don't have code, but we have a few interested people. Labs: Start from scratch (without code nor community) Not possible, because some of our contributers are not ASF committers. You could start at labs having those contributors contribute via patches/JIRA and the ASF committers committing their stuff. Don't know if this is acceptable to you. Then, sooner or later you'd go to the Incubator where they would become proper committers. ATM, I don't see any other possibility for starting out at the ASF. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Google Wave - anyone?
On Thu, Jul 30, 2009 at 13:30, Christian Grobmeiergrobme...@gmail.com wrote: Yes, Wookie is a server-side Widget repository and runtime/state management application that implements the Google Wave Gadget APIs; it has an API for connecting to applications that manage participants and contexts, which can include waves but also traditional CMS and intranet groups etc. So it could plug into a Wave Server (c) to handle the gadget management task. How complicated would it be to extend Vysper to a Wave Server? As I tried to outline before: The Google Wave protocol, as a XMPP extension, should be relatively easy to implement. We have Message-type stanzas and we are working on the PubSub extension right now, which is needed by the GW-XEP. Implementing the 'rest' of the Wave Provider/Wave Server is a bit more sophisticated job and does not require XMPP Know-How. Bernd I am not deep into Jabber but I think Googles Wave might be one of the next (big) cool things. I am willing to learn and help if other people are interested. you'll find us on d...@mina.apache.org. see you there... Is it possible to build some kind of wave client build on top of wookie? Btw, it feels that wookie is quite similar to Apache Shindig - is it? From the Wookie Proposal: For example, it[the Wookie engine] leverages Apache Shindig (Incubating) to render OpenSocial gadgets. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Google Wave - anyone?
On Wed, Jul 29, 2009 at 15:58, Scott Wilsonscott.bradley.wil...@gmail.com wrote: Wookie implements the Wave Gadget API, which is one part of a Google Wave system, but not the Wave Protocol itself. It might be interesting if Vysper could make use of Wookie for the wave gadgets part. Is Wookie a server-side technology? Otherwise I don't see the link between both. Maybe it could be the other way round (Wookie using Vysper), if Wookie makes use of the XMPP protocol. Of course, when it comes to implementing Wave, all projects should join efforts. Here is a short wrap-up of what you need to implement Wave: + a Wave client - this is a very fat client, and it's also a XMPP client + a server-side Wave Provider, consisting of (a.) Network Server(s) (b.) Wave Store (c.) Wave Server In this setup, I'd see (a.) as a XMPP server running the Wave Protocol (an extension of XMPP), probably tunneling through HTTP[2]. Compared to implementing XMPP, implementing the Wave protocol extension should be relatively easy. The hard and critical part is definitively (c.), with all the Operational Transformation stuff going on. Google starts open sourcing this at [1]. [1] http://code.google.com/p/wave-protocol/ [2] http://xmpp.org/extensions/xep-0124.html Bernd S On 29 Jul 2009, at 12:24, Emmanuel Lecharny wrote: Christian Grobmeier wrote: Hi, Hi, I know my request might be a bit unusual, but is somebody here preparing an idea for implementing the Google Wave Protocol? I might want to follow, if somebody does. You may ask Bernd Fondermann about that. He has started a project called Vysper (http://mina.apache.org/vysper) which is a XMPP server -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.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: Maximum number of Mentors??
2009/7/13 Noel J. Bergman n...@devtech.com: +1 (binding) on the singular change of dropping Mladen Turk and Nick Kew as Mentors since that makes it 5 mentors, which is problematic (3 seems to be the max). Where does that idea come from? Mentors are Incubator PMC members. If more than three (3) want to engage on a project that interests them, why limit it? Any issues that might arise from having more than three (3) would arise in the world outside of the Incubator, too. +1. AFAIR, 3 is the minimum, with less than 3 acceptable in rare cases, but more community is good. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduation for Sanselan [RESULT]
On Mon, Jun 29, 2009 at 19:06, Craig L Russellcraig.russ...@sun.com wrote: With 10 +1 votes from incubator PMC members, and no 0 or -1 votes, this vote passes. The following +1 votes were received: Martin Dashorst (binding) Bertrand Delacretaz (binding) Craig L Russell (binding) Carsten Ziegeler (binding) Emmanuel Bourg Kevan Miller (binding) Niall Pemberton (binding) Yoav Shapira (binding) Felix Meschberger (binding) Paul Fremantle (binding) Vamsavardhana Reddy Jeremias Maerki (binding) Sanselan is officially discharged from the incubator and becomes a subproject of Apache Commons. Many thanks to all who helped along the way. Craig On Jun 21, 2009, at 7:11 PM, Craig L Russell wrote: Hi, Sanselan has been in incubation since September 2007. Sanselan is a pure-java image library for reading and writing a variety of image formats. Monthly and then quarterly reports can be found at http://svn.apache.org/repos/asf/incubator/sanselan/board/ The first official Apache Sanselan incubating release occurred on July 30th, 2008. A few months back we took a final look at Sanselan's status with regard to exiting the incubator. We concluded that while the code and the committer for Sanselan were ready to exit the incubator, community was an issue. We didn't see the prospect for getting enough of a community to graduate Sanselan as a TLP. But Apache Commons was eager to adopt Sanselan, and they voted to do so. Sanselan is now ready to graduate the incubator and assume its role as a subproject of Apache Commons. Please review the checklist at http://incubator.apache.org/projects/sanselan.html and verify that Sanselan is ready. +1 graduate Sanselan into Apache Commons +-0 don't care -1 don't graduate because... Voting will remain open until Thursday June 25. Craig L Russell Incubator PMC, DB PMC, OpenJPA PMC c...@apache.org http://db.apache.org/jdo Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE ABANDONED] Release Apache Incubator Shindig version 1.0 (RC4)
On Mon, Jun 15, 2009 at 10:28, Ian Bostoni...@tfd.co.uk wrote: Hi, This vote has now been in progress for 14 days and has not received the necessary number of votes from the IPMC to make a release. There has been 1 +1 binding vote, 1 +2 non-binding vote and no other votes. The vote on shindig-dev resulted in 7 +1 binding votes, no +0 or -1's Votes so far Paul Lindner +1 (non binding) Ian Boston +1 (non binding) Ant Elder +1 (binding) Given the period of time that this vote has been open, it is unlikely that any more votes will be received and therefore I am closing this vote as abandoned. If there is a reason why members of the IPMC have decided not to vote on this release, I would like to hear them, before spending the time doing another release and wasting the IPMC's time. I will obviously fix the confirmed non blocker issues identified by Sebb, but the PPMC and Shindig community has been wanting and trying to release since January and the expenditure of more effort appears futile *if* there is something fundamentally wrong with the release that is not being said. Thank you Ian Boston. Who are your mentors? There should be at least three of them. They should be recorded on the Shinding website. Please look at other podlings website for what has to be recorded in the Project Info section of that your website, namely mentors and committers. If you have trouble contacting your mentors or any other question you cannot resolve within the project, don't hesistate to ask on gene...@incubator.apache.org. HTH, Bernd On 8 Jun 2009, at 10:24, Ian Boston wrote: Hi, This vote has been in progress for more than 72 hours now. AFICT although we have a number of non binding votes from the PPMC, we have no votes from the Incubator PMC. Votes so far Paul Lindner +1 (non binding) Ian Boston +1 (non binding) There were some other non binding votes cast by members Shindig community, but unfortunately the did not make it to gene...@incubator Having read the voting documentation, which does not mention lazy consensus for releases, I suspect that we should just abandon this vote and start all over again. However before I do that, I would like some advice from the Incubator PMC indicating that is the right thing to do? Thank you Ian On 4 Jun 2009, at 12:28, Ian Boston wrote: Hi, Please review and vote on approving the first release of Apache Shindig version 1.0-incubating. Apache Incubator Shindig is a JavaScript container and implementations of the backend APIs and proxy required for hosting OpenSocial applications. Vote Thread. http://markmail.org/thread/mrk4uwe7mg5e3uho Proposed release: https://repository.apache.org/content/repositories/shindig-staging-002//org/apache/shindig/shindig/1.0-incubating/ SVN Tag is http://svn.apache.org/repos/asf/incubator/shindig/tags/shindig-project-1.0-incubating/ revision 780648 Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, Ian - 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: [DOCUMENTATION ERROR] Documenting sponsorship by another PMC
On Mon, Jun 15, 2009 at 23:30, Noel J. Bergmann...@devtech.com wrote: ant elder wrote: See: http://incubator.apache.org/incubation/Incubation_Policy.html#Approval+of+Pr oposal+by+Sponsor There is an uncorrected defect in that process document. It says, in part, that the sponsoring PMC must provide the Incubator PMC with: * a reference to the results of the vote (so as to provide an audit trail for the records); * a reference to the Candidate's proposal; AND ... * the Mentors, nominated by the Sponsor, who will guide the Candidate through the Incubation Process. At least one nominated Mentor MUST be a member of the Apache Software Foundation. That third one, while partially correct, is in error. Mentors are Incubator PMC Members, and no one can impose Membership on the Incubator PMC. If the proposed Mentors are ASF Members, they can (and must -- we won't do it by implication) request PMC Membership. If the proposed Mentors are not ASF Members, they must request a vote, which is may or may not be successful. Do you have a patch? Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache JSecurity/Ki rename - please submit suggestions!
On Tue, May 19, 2009 at 21:53, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Apache Kleenex because the Kleenex registration refers to a paper product, not a software product. Gasp! Don't let the Kleenex folks hear that there product was not soft ware! Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: This problem of mine
On Tue, May 12, 2009 at 21:46, Craig L Russell craig.russ...@sun.com wrote: On May 12, 2009, at 11:22 AM, Alan D. Cabrera wrote: On May 12, 2009, at 11:12 AM, Craig L Russell wrote: On May 12, 2009, at 10:56 AM, Alan D. Cabrera wrote: On May 12, 2009, at 9:06 AM, Bertrand Delacretaz wrote: On Tue, May 12, 2009 at 5:14 PM, Alan D. Cabrera l...@toolazydogs.com wrote: ...I'd like someone to come up with a concise argument that would allow me to let this go other than nope, it's not the same. Otherwise, I feel that I need to bring up a vote to put the issue to bed once and for all The only thing that I can say is that from the ASF's point of view your project's name is Apache Ki, no just Ki. So, this is an interesting point. Can we change Apache Geronimo's name to Apache WebSphere and get a way with it? The main point is that you and I disagree on whether FixFlyer Ki and Apache Ki are in the same domain. I have neither broad nor deep experience with securities trading systems, but I do know what financial securities are. And I claim that someone knowledgeable enough about computer systems to be in a position to evaluate software for securities trading systems, should know the difference between Java security and Securities Trading. I think you missed my point and that is that they are comparing their Java security system, not the financial instruments, against JSecurity's. Not what I said. Both provide the same functionality where their vertical application overlaps with our horizontal application, that is, Java security. There's no evidence of this that I can see. Maybe we're looking at different source documents? It is not unusual to see companies break out pieces a product line and open source them. So I went to the FixFlyer web site yet again, and can't find any evidence that they are in the same application domain. Neither the Ki Certification web page http://www.fixflyer.com/html-files/KiCertification.html nor their pdf http://www.fixflyer.com/materials/software/Ki/FlyerKiCertification.pdf mentions the word security. Craig Regards, Alan Craig About the actual risks associated with FixFlyer's considering that Apache Ki infringes on their trademarks, the best might be to ask legal-disc...@apache.org. Do we want to get into this kind of tussle straight out of the gate w/ a podling that's been using this name for such short while? What I don't get is why would anyone want to keep the name if there are potential overlaps or troubles ahead? I mean, there are probably better (coding) and harder (releasing, graduating) things to do than getting stuck about the name. Why don't you (as a podling) simply move on with another cool name, for example, just brainstorming here... JSecurity... or something similar? Have fun, Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: This problem of mine
On Tue, May 12, 2009 at 22:58, Les Hazlewood lhazlew...@apache.org wrote: On Tue, May 12, 2009 at 3:55 PM, Bernd Fondermann bernd.fonderm...@googlemail.com wrote: What I don't get is why would anyone want to keep the name if there are potential overlaps or troubles ahead? I mean, there are probably better (coding) and harder (releasing, graduating) things to do than getting stuck about the name. Why don't you (as a podling) simply move on with another cool name, for example, just brainstorming here... JSecurity... or something similar? JSecurity was deemed as a potential naming conflict risk (much in the same way Ki is now), so we dropped it, and finally came to a vote to change the name to Ki. But this resolution took over 4 or 5 months to finally come to a favorable vote, so we didn't want to go through that painful process all over again, since it seemed like no one was willing to come to consensus on other names. It is very difficult to find an even remotely-correlated name in the security space that might not infringe on another site/company/product/trademark/patent. ok, I see. At least, for JSecurity, these conflicts never came up, did they? That's why so many project go with names from biona or mythology. Given the difficulty and the enormous amount of time spent already, we just wanted to move on to focus exactly on the things you mention, and only worry about changing the name yet again if it was absolutely required by the Incubator to do so. That being said, if the Incubator says the Ki podling must change its name, then fine, we'll be happy to do so, but most of us didn't want to spend the effort worrying about it unless necessary. To me, it seems neccessary, but this is just my 2 eurocent. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Commons Incubator
On Sat, Apr 11, 2009 at 21:24, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Sat, Apr 11, 2009 at 10:56 AM, Gavin ga...@16degrees.com.au wrote: -Original Message- From: tcu...@vafer.org [mailto:tcu...@vafer.org] On Behalf Of Torsten snip The incubator approach just doesn't work well for projects that have a very small scope and user base IMO. +1 the smaller the code base, the more problems the incubator has with it micro-libraries are particularly difficult The current incubator is about establishing a project. We rather would to like to have something that helps integration into an existing project. from the incubator perspective, IMO the effort that the incubator has had to put into small code bases has been totally out of proportion and this energy would have been much better invested into stopping some of the larger, higher profile failures. it's time to acknowledge that the incubator only has a certain level of energy and the IPMC should be investing it where the risks and gains are highest. the commons has established an excellent track record in understanding how to develop micro-libraries as a community. if the commons can supply the energy required to create a specialist section for small code bases then this will allow the IPMC to focus it's efforts on the larger code bases. I understand both points of view here. Unfortunately however different circumstances of the code 'donations' are getting differing treatment. My view, and I believe Torstens view is that to become a committer means to join the dev lists, send in patches, be part of the community, gain trust with the project members and then after a while be voted in as a committer. Now if someone has a nice great big chunk of code, or even a whole mini-subproject to donate, then they should so just that, donate the code and if they wish to continue working on that code then send in patches to the list or issue tracker. Eventually you'll get commit access, will have learnt the Apache Way and all is dandy. The 'other' view is I believe mainly Company orientated. Company X pays person Y to work on code that they want to be 'donated' to Project Z (which just happens to have come from Company X in the first place.) The last thing they want is for person Y to go through the Apache Way initiation ceremony that could last months, they want him/her in there carrying on committing to it as usual. Hence we have the 'here's some code, here's a new committer or two to go with it'. The 'other' view imho is wrong and just bypasses what we are about. Every now and then someone has to remind us, we are a group of individuals belonging to a community that works on code. Company Z and all the other Companies out there need to understand this, especially when considering employing someone and paying them to work on open source projects. (Can't you just tell I don’t work for a Company Z) this required enculturalisation of close code bases was a major driving factor behind the setting up of the incubator. the incubator has been successful at doing this. the incubator has been less successful with existing openly developed FOSS projects, and IMO it's few successes have a lot more to do with the qualities of the incoming projects than the effectiveness of it's methods. the incubator has not enjoyed success with small code bases. commons has a wealth of expertise with these kinds of projects. from an IPMC perspective, i think we need to grab this chance to get some help on this. however, IMHO i'm not sure that we can hit upon the right set of rules straight away, and i'm also not sure whether the current proposal is the right approach. i do think we should approve the principle of a specialist incubator for small codebases staffed by experts from the commons. I sympathize with the general desire to be able to grow small code bases at Apache. (We had this discussion in the labs list a short while ago.) And for sure the Common's people have know-how how to handle small projects. But, establishing Commons Labcubator within the Incubator doesn't seem like the right approach to me. Either it's a Commons project, then it should grow in Commons, or it's another project's small code base, then it should be nurtured there, or it's something completely different, then it should grow in Labs (which is language agnostic, BTW). I'd like to re-iterate though, that dealing with (developing and releasing) independent small code bases (in terms of contributors and code) is not easily possible at the ASF at the moment. This is why we lost the Orthrus Lab to Google Code. The more projects and products we host, the more difficult (or impossible) it gets to spot the interesting ones. So this is not only a Commons-specific issue. It also applies to other regular TLPs and Labs as well. Bernd - To unsubscribe,
Re: The graduation of Buildr and Abdera... + Rant
On Fri, Feb 20, 2009 at 16:18, Yoav Shapira yo...@apache.org wrote: On Fri, Feb 20, 2009 at 9:41 AM, Garrett Rooney roo...@electricjellyfish.net wrote: On Fri, Feb 20, 2009 at 2:10 AM, Niclas Hedhman nic...@hedhman.org wrote: Gang, I think that the Graduation of these two projects have not been 'clean'. Both are still listed as Incubating Projects on projects/index.html, as well as part of the Incubator project navigation. Buildr is not listed in projects on www.apache.org, Abdera is listed there. And neither have updated their STATUS pages to reflect the graduation. You know, I was going to leave it at a nice patches welcome, but hell with it. If you're so damn concerned about some web pages not getting updated, fix it your damn self. I've spent more time than I actually have right now updating the 9 million little things that have to get done when Abdera graduated, and opening my email today and hearing that apparently I'm doing a shitty job because I missed some of them was not exactly what I had in mind for starting my day. The entire process of going through incubation with Abdera has been a giant pain in my ass, and I'm sick of it. I no longer have the energy to deal with this anymore. Have fun with your overly complex rules and guidelines, building bureaucracy for the sake of bureaucracy with little to no gain. I'm done with it. +1. Niclas, good luck -- your efforts are appreciated. I'm about to send email to my current projects that I'm quitting as a mentor. I don't have anything to add to the above because Garrett nailed it. It's become too much of a PITA. Wow, this reminds me of the moments when I ask my children to clean up the mess they created when happily playing. And I get very grumpy when _I_ am the one who cleans up in the end, because I some other stuff to do, too. But hey - they are my kids! And we cannot leave it that way. Bernd - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
moving over from labs [Re: [Result] [Vote] accept Droids into incubation]
On Thu, Oct 9, 2008 at 01:34, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On Thu, Oct 9, 2008 at 1:19 AM, Thorsten Scherler [EMAIL PROTECTED] wrote: Can the PMC ACK this result and we'll start the next step of the process? No ACK needed, as it was the Incubator PMC itself who just voted. Regarding the svn move ATM there are two trees under development https://svn.apache.org/repos/asf/labs/droids/trunk https://svn.apache.org/repos/asf/labs/droids/branch/LABS-144/ Where the latest has become kind of trunk. We can merge them if this will ease the work of migrating. I don't think you need anything more complicated than an svn move of labs/droids to incubator/droids. Whether or how you want to merge branches is a project decision that's up to you and the other committers. There is one additional step. According to the lab's bylaws[1], this labling wants to change its status from 'active' to 'promoted'. This is done by a majority vote of the lab PMC + the labling's PI and it should take place on [EMAIL PROTECTED] I think this vote will just go through easily, as we have discussed the transition in all details over at labs already. The incubator is not involved with this - I am just posting here in context. If people have a different take on this process: please post over at labs. thanks, Bernd [1] http://labs.apache.org/bylaws.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] accept Droids into incubation
+1 Bernd On 2008-10-02, Erik Hatcher [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 4:00 PM, Thorsten Scherler wrote: Please vote on accepting Droids into incubation. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sent from Google Mail for mobile | mobile.google.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Project Proposal
On Wed, Sep 24, 2008 at 06:52, Hussain Fakhruddin [EMAIL PROTECTED] wrote: Hi, I have prepared a rough draft of a Proposal which I would want ASF to have a look. I am not sure if this is the correct email where I should be sending it. Please consider it. Your MS Word document attached to the mail didn't make it on the list - it simply got stripped off for security reasons. Please check the following resources about how to approach incubation: http://www.apache.org/foundation/how-it-works.html http://incubator.apache.org/guides/index.html Good luck, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r691545
[cc'ing general@incubator.apache.org to improve awareness that there is something fundamentally going wrong, IMHO] On Sun, Sep 7, 2008 at 13:03, Samul Kevin [EMAIL PROTECTED] wrote: The license header missing mistake is totally my fault,i had't have my done well.Sorry guys-_-!.Bill had suggestted us to post all the report on the mail list. But we had't achieved an agreement in time to put all the reports on the mail list. Where was that discussed? I do not see a public discussion of this on the Bluesky mailing list. Who is we? And by the way, there is no need reach an agreement here. Posting reports and everything else publicly is the _precondition_ to make this an open source project. Tomorrow we'l have a weekly meeting, i wish that we could solve these problems after discussions. And i will propose the team leader to publish content of every meeting we will hold. Hold your meeting on the mailing list, or on a public IRC channel. Everything else is not acceptable. We do not have team leaders here at Apache. But we have clear rules how projects operate. There are plenty of resources (texts) and examples (projects) here at the Incubator and on the other projects how that is supposed to work. Decisions are made in a consent-driven manner, not by team leaders off-list. Everyone has an equal say. No individual is entitled to make a final decision unilaterally. Bernd 2008/9/6 Bernd Fondermann [EMAIL PROTECTED] Hi Bluesky project, Again, I have concerns regarding your svn commits. The recently commited HTML and CSS code misses a license header. Please improve the code as soon as possible, to avoid a veto. Also, I don't remember that the report topics/todo lists contained in that HTML have been discussed as a whole or in more depth on the public list. This concerns me. I'd like to propose that bluesky changes to Review-Then-Commit, instead of Commit-Then-Review because of apparent lack of eyeballs/mentor oversight. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r691545
Hi Bluesky project, Again, I have concerns regarding your svn commits. The recently commited HTML and CSS code misses a license header. Please improve the code as soon as possible, to avoid a veto. Also, I don't remember that the report topics/todo lists contained in that HTML have been discussed as a whole or in more depth on the public list. This concerns me. I'd like to propose that bluesky changes to Review-Then-Commit, instead of Commit-Then-Review because of apparent lack of eyeballs/mentor oversight. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r676177
Hi, I am concerned about the recent commit from the BlueSky project, recorded as revision 676177. This bulk commit looks to me like GPLed code from a third party project has been taken, being modified to obfuscate the origins of this code and then being committed to svn without any prior IP clearance. In detail: * most directories contain a COPYING file with the GPL in it. * some files contain copyright notices from people and organisations not involved with the project, probably the original authors * files like AUTHORS, README probably have been emptied before the commit to remove any reference to their origins * the ASL headers have been added in follow-up commits. I'd like to know from the BlueSky committers what is their own code and what is taken from other projects (which ones)? Who are the respective copyright owners and have they been contacted? I'd propose to remove the code from svn and re-code the project based on committer's own contributions. In addition, BlueSky failed to properly report to the board for half a year now. Now, a report has been posted to bluesky-dev some days ago, but I could not spot it in todays report from Noel posted to [EMAIL PROTECTED] My on-list concerns about xplayer were not addressed in this report. xplayer seems to be (I did not take a closer look) a crucial component for this software, the committers said they would exclude it, resulting in the fact that now the software lacks audio/video capabilities. It looks like xplayer is derived from GPL'ed mplayer and the FFmpeg library has also been mentioned, both said to be having patent issues (that's what I read on wikipedia, I didn't check beyond that). I propose to work around this by using vorbis and related technologies. We (as the incubator) should mentor this project more intensively. Thanks, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BlueSky is clouded
Hi, I just noticed that BlueSky did not report anything since being voted into incubation in January and is not linked from the incubator website. There is activity, on-list and in svn. I posted to their dev list to ping the people there. So, I guess they'd need to report for the next three months? Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven-repository cont.
On Sat, May 31, 2008 at 3:59 PM, Noel J. Bergman [EMAIL PROTECTED] wrote: Robert Burrell Donkin wrote: Every incubator release is also an Apache release http://incubator.apache.org/guides/releasemanagement.html#rules +1 every incubator release is an official apache release While technically accurate, the way you are both using the term conveys a false meaning that would be in conflict with the clear statement in the Incubator Disclaimer: While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. And every time you want to gray that area, you provide more weight for making the division between the Incubator and the rest of the ASF more starkly delineated, which would result in measures more onerous than most under discussion. So let's try and keep that line nice and clear, rather than blur it. --- Noel I dont' get where the contradiction is, or the gray area. 'Release' is about source code, 'project' is about much more: people, code, etc. Let's say, the Incubator publishes a release 'foo-incubating-0.9-src.zip' of podling 'foo'. Say, the released code is stable and has everything we would want from a release. Later, the project gets cancelled while in incubation, for diversity reasons, lack of interest, whatever. So we have (a) a regular release of (b) a failed incubating project. The _release_ refers to the released code, while the podling failed, which the _disclaimer_ is good for. If it wasn't a proper release, well it shouldn't have been released. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Jabber Server
On 11/1/07, Trustin Lee [EMAIL PROTECTED] wrote: Is Vysper using MINA? Sure ;-) BTW Openfire team also uses MINA as their networking layer. smart people, it seems :-) Please don't hesitate to contact the MINA team whenever you have something to say, ask or rant. :) ok, I will subscribe to the list. thanks you for your comments. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Jabber Server
On 10/30/07, Petar Tahchiev [EMAIL PROTECTED] wrote: Hi guys, today I was looking for a Jabber server implemented entirely in Java, and the only results that I got was this: ---(free)--- http://www.codecobra.com/chime/ http://www.open-im.net/ http://www.tigase.org/ http://www.igniterealtime.org/projects/openfire/index.jsp (commercial)--- http://www.adobe.com/special/antepo/?products.opnserver (no longer available - bought by Adobe) Does anyone (besides me) think that we can build something better? Waiting for your suggestions. Sure. Definitively. :-) I am working on a Jabber server in an Apache lab called Vysper (pronounced: whisper). See http://labs.apache.org/labs.html and http://svn.apache.org/repos/asf/labs/vysper/ Any contributions more than welcome! Discussion should happen on [EMAIL PROTECTED] And eventually, if the project gains track, we could aim for incubation. Bernd -- Regards, Petar! Karlovo, Bulgaria. EOOXML objections http://www.grokdoc.net/index.php/EOOXML_objections Public PGP Key at: http://keyserver.linux.it/pks/lookup?op=getsearch=0x1A15B53B761500F9 Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 00F9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Java Jabber Server
On 10/30/07, Deepal jayasinghe [EMAIL PROTECTED] wrote: Petar Tahchiev wrote: Hi guys, today I was looking for a Jabber server implemented entirely in Java, and the only results that I got was this: ---(free)--- http://www.codecobra.com/chime/ http://www.open-im.net/ http://www.tigase.org/ http://www.igniterealtime.org/projects/openfire/index.jsp (commercial)--- http://www.adobe.com/special/antepo/?products.opnserver (no longer available - bought by Adobe) Does anyone (besides me) think that we can build something better? Waiting for your suggestions. I also like to contribute to this , if you are going to implement. sometimes ago I wanted to build a Jabber (XMPP) implementation based Stax implementation. May be this is a good chance for that. I'd like to invite you to contribute to Apache Lab Vysper. I had to implement (reinvent) a XML streaming parser, because those available didn't quite fit (for various reasons). But that's probably due to my lack of expertise in this field. There is still high need for a 'real' XML parser. So, if you have some cycles to spare, help out there. Thanks, Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RAT^H^H^H Proposal
On 10/3/07, Robert Burrell Donkin [EMAIL PROTECTED] wrote: i'm preparing http://wiki.apache.org/incubator/RatProposal but i thought i'd get the most controvercial and difficult aspect out of the way: the name. i quite like the name RAT since it's a play on words a Release Audit Tool which rats on releases. (i was also born in the year of the rat.) so, i expect people to find a thousand good reasons why it shouldn't be used. Au contraire. I like RAT. I read it as short for ratification. And we are having a software zoo here already anyway. Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gauging interest for incubating PDFBox...
On 5/7/07, Jukka Zitting [EMAIL PROTECTED] wrote: Hi, On 5/7/07, Jeremias Maerki [EMAIL PROTECTED] wrote: So, after hearing PDFBox mentioned many times last week, I thought it might be a good idea to ask around inside a wider area to see how the ASF is potentially interested in adopting PDFBox among its projects. At least Jackrabbit and Nutch currently use PDFBox and the library would also be an ideal companion for the Tika toolkit, so I'd be very happy to see PDFBox joining the ASF. :-) +1 Bernd Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Digest-mailing-list (un)subscribe links
Hi, I had problems unsubscribing from the incubator general digest. The ready-to-go unsubscribe link from the mail footer has a doubled -digest which ezmlm doesn't like very much. Same problem seems to apply to the subscribe link. Posting to [EMAIL PROTECTED] probably is not a good idea either. How to deal with that minor issue? [EMAIL PROTECTED] open JIRA? somebody able to quickfix? Bernd On 12 Oct 2006 22:31:55 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: general Digest 12 Oct 2006 22:31:55 - Issue 732 Topics (messages 11459 through 11488): snip/ Administrivia: To subscribe to the digest, e-mail: [EMAIL PROTECTED] To unsubscribe from the digest, e-mail: [EMAIL PROTECTED] To post to the list, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-51) Digest mailing list (un)subscribe link don't work
Digest mailing list (un)subscribe link don't work - Key: INCUBATOR-51 URL: http://issues.apache.org/jira/browse/INCUBATOR-51 Project: Incubator Issue Type: Bug Reporter: Bernd Fondermann Priority: Minor I had problems unsubscribing from the incubator general digest list using the embedded links in the mailing footer. The ready-to-go unsubscribe link from the mail footer has a doubled -digest which ezmlm doesn't like very much. Same with the subscribe link and the posting advice which should read [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
