Re: PMC chairs access to Donations Repo
On Sun, Nov 2, 2008 at 3:47 AM, David Crossley [EMAIL PROTECTED] wrote: Greg Reddin wrote: David Crossley wrote: https://svn.apache.org/repos/asf/incubator/donations/ .^ Is there some documentation that led you astray or just a slip? I didn't type the right URL or even the right path in my email, sorry. Using the path you specified above I was unable to commit a new directory containing sigs and a .zip file. Okay, now we are sure about the URL. Yes i see that people in your situation do not have svn authorisation. It is either members or incubator-pmc - default for the incubator section. I presume that the pmc-chairs group should have access, but it does not currently. To Incubator PMC, should we add a special handler for the incubator/donations/ directory? i'm +1 - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Donations Repo
On Sun, Nov 2, 2008 at 3:12 AM, Greg Reddin [EMAIL PROTECTED] wrote: On Fri, Oct 31, 2008 at 5:26 PM, David Crossley [EMAIL PROTECTED] wrote: https://svn.apache.org/repos/asf/incubator/donations/ .^ Is there some documentation that led you astray or just a slip? I didn't type the right URL or even the right path in my email, sorry. Using the path you specified above I was unable to commit a new directory containing sigs and a .zip file. as david pointed, this is likely to be a permissions issue. you can either wait until we've sorted it out or create a JIRA containing the patch then post a reply. someone with karma will pick it up. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accepting Kato into the Incubator
On Thu, Oct 30, 2008 at 3:02 PM, Craig L Russell [EMAIL PROTECTED] wrote: +1 +1 Good to see JSRs developed completely in the open. +1 - robert Craig On Oct 30, 2008, at 2:14 AM, ant elder wrote: The Kato proposal has been out for discussion for a few weeks now, please vote on accepting the Kato project for incubation. The full Kato proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/KatoProposal. Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accepting Kato into the Incubator
On Sun, Nov 2, 2008 at 10:45 AM, Roland Weber [EMAIL PROTECTED] wrote: ant elder wrote: The Kato proposal has been out for discussion for a few weeks now, please vote on accepting the Kato project for incubation. [...] = Kato - Post-mortem JVM Diagnostics API and RI/TCK for JSR 326 = [...] Nominated Mentors Geir has volunteered to be a mentor. Ant Elder That list looks a bit short, but +1 anyway. (binding) i'm willing to be added as a mentor if this is a problem and kato are happy to have me - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accepting Kato into the Incubator
+1 Niall On Thu, Oct 30, 2008 at 9:14 AM, ant elder [EMAIL PROTECTED] wrote: The Kato proposal has been out for discussion for a few weeks now, please vote on accepting the Kato project for incubation. The full Kato proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/KatoProposal. Here is my +1 ...ant = Kato - Post-mortem JVM Diagnostics API and RI/TCK for JSR 326 = Abstract Kato is a project to develop the Specification, Reference Implementation and Technology Compatibility Kit for JSR 326: Post-mortem JVM Diagnostics API Proposal JSR 326 is intended to be a Java API specification for standardising how and what can be retrieved from the contents of post-mortem artefacts -- typically process and JVM dumps. Project Kato is intended to be the place where the Specification, Reference implementation (RI) and Technology Compatibility Kit (TCK) are openly created. The intention is that the Specification and RI will be developed in tight unison, guided by a user-story-focused approach to ensure that real-world problems drive the project from the beginning. Unusually for new APIs, this project will endeavour to encompass the old and the new. A diagnostic solution that only works when users move to the latest release does little to improve diagnosability in the short term. This project will consume existing dump artefacts as well as possible while developing an API that can address the emerging trends in JVM and application directions. The most obvious of these trends are the exploitation of very large heaps, alternative languages and, paradoxically for Java, the increased use of native memory through vehicles such as NIO. Background Post-mortem versus Live Monitoring: It's worth noting that the term post mortem is used loosely. It does not just imply dead JVMs and applications; JSR 326 also covers living, breathing applications where the dump artefacts are deliberately produced as part of live monitoring activity. Live monitoring generally means tracing, profiling, debugging, or even bytecode monitoring and diagnosis by agents via the java.lang.instrument API . It can also mean analysis of dumps to look for trends and gather statistics. The live-monitoring diagnostic space is well served except for this last area, which is where JSR 326 can help. IBM developed an API called DTFJ (Diagnostic Tooling and Framework for Java) as a means of providing its support teams a basis on which to write tools to diagnose Java SDK and Java application faults. It consists of a native JVM-specific component and the DTFJ API, which was written in pure Java. Rationale JSR 326 exists because of the widely acknowledged limitations in diagnosing Java application problems after the fact. There are many good ways to understand and diagnose problems while they happen, but few credible or pervasive tools exist for helping resolve problems when all has gone suddenly and horribly wrong. Outside of live monitoring there is no standard way to provide diagnostics information, and hence no standard tools. Each tool writer has to figure out how to access the data individually and specifically for each JVM vendor and operating system. This sparsity of tools has meant that users have limited options in diagnosing their own problems, especially unexpected or intermittent failures. Consequently these users turn to the providers of their software to work out what is happening. Application, middleware, and JVM vendors are spending increasing time supporting customers in problem diagnosis. Emerging trends indicate that this is going to get worse. Today JVM heap sizes are measured in small numbers of gigabytes, processors on desktops come in twos or fours, and most applications running on a JVM are written in Java. To help analyse problems in these configurations, we use a disparate set of diagnostic tools and artefacts. If the problem can't be reproduced in a debugger, then things quickly get complicated. There are point tools for problems like deadlock analysis or the ubiquitous Java out-of-memory problems, but overall the Java diagnostic tools arena is fragmented and JVM- or OS-specific. Tool writers have to choose their place in this matrix. We want to change that by removing the need for tool writers to make a choice. By enabling tool writers to easily target all the major JVM vendors and operating systems, we expect the number and capability of diagnostic tools to greatly increase. Tomorrow it gets harder; heap sizes hit 100's of gigabytes, processors come packaged in powers of 16, and the JVM commonly executes a wide range of language environments. We can't tackle tomorrow's problems until we have a platform to address today's. This project is about bringing together people and ideas to create that platform, and we can't think of a better place to do that than in Apache. Initial Goals The code
Re: [VOTE] Accepting Kato into the Incubator
ant elder wrote: The Kato proposal has been out for discussion for a few weeks now, please vote on accepting the Kato project for incubation. [...] = Kato - Post-mortem JVM Diagnostics API and RI/TCK for JSR 326 = [...] Nominated Mentors Geir has volunteered to be a mentor. Ant Elder That list looks a bit short, but +1 anyway. (binding) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Meeting with members of podlings at ApacheCon
Hi Everyone, My name is Yeliz (phonetically Yeah-Liz). I am a PhD student and an Open Source researcher from Syracuse University. You guys see me and my colleagues wearing pith helmets at ApacheCon. This year we are working on a project to understand what makes podlings successful. My professor, Kevin Crowston had shared this with a number of ASF members, who thought it was a good idea and could be beneficial for ASF. So I am looking forward to meeting and talking to the members of podlings to understand what they go through. I am not sure who will be here in New Orleans and from which podling. For those of you who are attending ApacheCon--I would appreciate if you would drop me a line and introduce yourself or say hi at when you see me (a female wearing the pith helmet) during ApacheCon in new Orleans and say hi. And yes, you can take a picture with my pith helmet :) In fact, many have done so in the past.. Thanks and looking forward to talking to you. Yeliz. -- Ms. Yeliz Eseryel Ph.D Candidate in Information Science Technology Syracuse University School of Information Studies Teaching Blog: http://enterprisesystems.blogspot.com twitter.com/yeliz yelix.blogspot.com --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Meeting with members of podlings at ApacheCon
On 2 Nov 2008, at 11:15, Yeliz Eseryel wrote: So I am looking forward to meeting and talking to the members of podlings to understand what they go through. I am not sure who will be here in New Orleans and from which podling. For those of you who are attending ApacheCon--I would appreciate if you would drop me a line and introduce yourself or say hi at when you see me (a female wearing the pith helmet) during ApacheCon in new Orleans and say hi. Yeliz, why not set this up as part of the BarCamp for those in New Orleans. Feel free to dovetail it with my already proposed session on FOSS and Education: How do we encourage the teaching and study of open development and open source. , I added the study part thinking of you folk. http://barcamp.org/BarCampApache Ross And yes, you can take a picture with my pith helmet :) In fact, many have done so in the past.. Thanks and looking forward to talking to you. Yeliz. -- Ms. Yeliz Eseryel Ph.D Candidate in Information Science Technology Syracuse University School of Information Studies Teaching Blog: http://enterprisesystems.blogspot.com twitter.com/yeliz yelix.blogspot.com --- - 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]
[jira] Created: (INCUBATOR-100) document the process for a podling that has decided to go to dormant status
document the process for a podling that has decided to go to dormant status --- Key: INCUBATOR-100 URL: https://issues.apache.org/jira/browse/INCUBATOR-100 Project: Incubator Issue Type: Task Components: site Reporter: David Crossley Document the process. Some steps were thoughtfully provided by Leo and Matthieu for TripleSoup: Re: TripleSoup going into dormant mode http://markmail.org/message/kavm65g65x55wqr5 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Donations Repo
On Sun, Nov 2, 2008 at 2:31 PM, Robert Burrell Donkin [EMAIL PROTECTED] wrote: as david pointed, this is likely to be a permissions issue. you can either wait until we've sorted it out or create a JIRA containing the patch then post a reply. someone with karma will pick it up. As PMC Chair, he should have Karma to add himself at the right spot in the authorization file, right? Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
