Re: [DISCUSS] Commons RDF to join the Apache Incubator
For your convenience, here's the proposal text for CommonsRDF: = Apache Commons RDF incubation proposal = TableOfContents() == Status == Draft == Abstract == Commons RDF is a set of interfaces for the RDF 1.1 concepts that can be used to expose common RDF-1.1 concepts using common Java interfaces. == Proposal == The main motivation behind this simple library is revise an historical incompatibility issue. This library does not pretend to be a generic api wrapping those libraries, but a set of interfaces for the RDF 1.1 concepts that can be used to expose common RDF-1.1 concepts using common Java interfaces. In the initial phase commons-rdf is focused on a subset of the core concepts defined by RDF-1.1 (URI/IRI, Blank Node, Literal, Triple, and Graph). In particular, commons RDF aims to provide a type-safe, non-general API that covers RDF 1.1. In a future phase we may define interfaces for Datasets and Quads. The goal is to provide a compact API that could be implemented by the upcoming versions of the main Java toolkits (Apache Jena 3.0 and OpenRDF Sesame 4.0) as well as for other libraries (OWLAPI) and other JVM languages (Banana RDF and so on). In addition, the project could provide some simple implementations suitable for some basic scenarios. But the major and established Java toolkits will always remain the recommend implementations to use. == Background == In the Java world there has been historically an incompatibility issue between the two major RDF toolkits: Apache Jena and OpenRDF Sesame. Many libraries have tried to wrap them, but besides technical considerations, they normally end up being unmaintained. Together, we came up with the idea of Commons RDF for solving the incompatibility problem. The community has been in healthy development at Github, including participants from the major Java RDF toolkits. The natural path to Apache Commons Sandbox has been studied, but we think that in this phase of the project, which focuses on the API design and actively involves the developers of existing toolkits, it is better to have a more focused community and infrastructure. Rather than a new Top-Level Project, the goal is still to graduate as part of Apache Commons, that is when API has achieve the required maturity and the project goes into maintenance mode. Part of the motivation for doing the incubator process would therefore be to bring together the existing Commons RDF community in the Apache Way, mature the API, and then gradually prepare the Commons RDF community for working within the larger Apache Commons community. == Rationale == The library comes from the need for providing a generic and neutral API for RDF 1.1 that everybody can transparently use without bounding the design to concrete implementations. It is the result of cooperation between contributors to the main Java toolkits, and will try to be available in a timely manner to influence the major version updates Jena 3.0 and Sesame 4.0. == Initial Goals == * Evolve the API towards a generalized and agreed shape * Bootstrap basic implementations * Support the implementation == Current Status == The API is already quite agreed by all involved players, and it's been started to be prototyped, both by the major toolkits and by simple implementations. === Meritocracy === Commons RDF has been completely designed by committee using git workflows, where every single feature has been discussed based on a Pull Request. We plan to keep such methodology where the commons understanding comes first than personal decisions. === Community === Commons RDF addresses the developers who are working with Semantic Web technologies in the JVM. The initial committers are core contributors to that community. === Core Developers === * Sergio Fernández (wikier dot apache dot org) * Andy Seaborne (andy dot apache dot org) * Peter Ansell (ansell dot apache dot org) * Stian Soiland-Reyes (stain at apache dot org) * Reto Gmür (reto at apache dot org) === Alignment === Commons RDF comes to help in the integration of the different ASF projects using RDF technologies, where Apache Jena can be integrated with others which use Sesame (Any123 and Marmotta). In addition, proposals by other projects (Clerezza and Stanbol) can be also aligned. == Known Risks == === Orphaned Products === Probably one of the major risks will that the API provided does not fit well in the development plan of the main Java toolkits. But we try to minimize such risk by having on board core developers of those framework, the API will live or die on its own merits. === Inexperience with Open Source === The committers have large experience with open source development and ASF communities. === Homogeneous Developers === The initial list of developers come from five different organizations and four different countries. === Reliance on Salaried Developers === Although the project is also in the strategic agenda of project of our current employers, so far the
Re: Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator
I didn't read the documentation carefully enough to quote details, but it appeared that the efficiency and asynchronous nature of the parameter server is considered to be a key factor in scalability and performance. The performance numbers that I read compared singa to H2O and showed a very considerable performance advantage for singa. This is very interesting because H2O is a very high performance system. Another factor that stood out in my reading was the fact that while Singa performs very, very well on the problems shown, scaling breaks down a bit at moderate cluster sizes. The commentary in the report attributes this to limitations in parameter server scaling. I find it an intriguing hypothesis that the synchronous updates that H2O does may well cause much the same effect as a poorly scaled parameter server. On Tue, Feb 10, 2015 at 3:59 PM, Edward J. Yoon edward.y...@samsung.com wrote: I think that, one of the big differences is that Singa is written in C++. Awesome, I'd be the first client. And anything from architectural viewpoint? -- Best Regards, Edward J. Yoon -Original Message- From: Ted Dunning [mailto:ted.dunn...@gmail.com] Sent: Wednesday, February 11, 2015 8:37 AM To: general@incubator.apache.org Subject: Re: Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator On Tue, Feb 10, 2015 at 3:33 PM, Edward J. Yoon edward.y...@samsung.com wrote: My coworker is working on implementing DNN on Apache Hama (which supports general-purpose BSP computing and Pregel-like graph framework). If Hama is leveraging InfiniBand and GPUs in the future, what will be the major difference bt Hama-based DistBelief clone and Singa project? And, how much performance difference bt async and sync? I think that, one of the big differences is that Singa is written in C++. Another is that Singa runs now. The present tense is always very powerful when it comes to software. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: -incubator in versions of podling maven artifacts
Since the only official release is the source release, perhaps that's the only place where we in fact need a policy? On Tue, Feb 10, 2015 at 9:39 PM, Niclas Hedhman nic...@hedhman.org wrote: On Wed, Feb 11, 2015 at 7:49 AM, Stian Soiland-Reyes st...@apache.org wrote: I think formally the requirement is just that there is incubating somewhere in the released downloadables, it doesn't have to be part of the version number Originally it was a matter of the user can't avoid notice that the project is incubating. So anywhere, he/she can enter it as a dependency it needed to be present. Since many uses Maven, that meant it had to be part of group, artifact, version or classifier. If the project only releases a source tarball, then it needs to go onto that, and so on. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Commons RDF to join the Apache Incubator
ATTENTION IPMC! If anybody is out there wants a low-stress Mentoring gig, this is it. And if you're an RDF neutral outsider, you'll be helping this project to achieve its goals, just by showing up. On Tue, Feb 10, 2015 at 3:14 PM, Stian Soiland-Reyes st...@apache.org wrote: Right - I think it would be good to leave as a decision to be made by the PPMC when we get closer to graduation. One problem with TLP is that we would likely need a different name ;-) So it would be advantageous in some ways to sort this out now. How good a fit is this project for Commons? Is it similar in scope and size to other Commons components? Any comments from current members of the Commons community? Should we be concerned about potential umbrella project issues, such as degrading signal-to-noise ratio on the Commons lists? Anybody else care to weigh in on the prospect of graduating a TLP which is anticipated to have low but sustainable activity? Agree, Commons RDF is a slightly different proposal - in a way we need the incubator mainly to mature the API (e.g. fight over method names) and grow the community, rather than to be a podling to learn the Apache Way and battle with NOTICE files. Given who's involved, this is going to be as easy as Mentoring gig as ever comes around. It's worth contemplating whether this project should be submitted as a TLP. Perhaps the initial group is not quite large enough and there aren't quite enough Apache Members, and long-term sustainability won't be established until the API negotiations succeed and the user community grows -- but still... The Champion's main work is to help formulate the proposal. That work is essentially done -- so it doesn't matter too much who takes that role, now. Are Andy and Reto opting out out as a gesture of openness to Sesame? Sergio has effectively been the Champion for this proposal, but I guess he's not technically admissible as the Champion needs to be a Member or Director. It's not uncommon for someone other than the Champion to do most of the hard work of drawing up the proposal, honestly. (I coordinated the drafting of the Lucy Incubator proposal long before I got the Member merit badge which qualifies me to serve as a Champion. It was the most educational activity I've ever undertaken at Apache.) Peter, who I see is active in Sesame, indicates that either Reto or Andy would be acceptable. If it would suit the community to have an outsider Champion, though, I'm willing to serve. To be honest there are other tasks around Apache that I need to attend to and I would rather be the one who hooked you up than take on a formal role -- so if another outsider is willing I'll stand aside. But I can't ignore the cost/benefit ratio here. We were hoping to also get some RDF neutral mentors. See above. :) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: -incubator in versions of podling maven artifacts
On Wed, Feb 11, 2015 at 7:49 AM, Stian Soiland-Reyes st...@apache.org wrote: I think formally the requirement is just that there is incubating somewhere in the released downloadables, it doesn't have to be part of the version number Originally it was a matter of the user can't avoid notice that the project is incubating. So anywhere, he/she can enter it as a dependency it needed to be present. Since many uses Maven, that meant it had to be part of group, artifact, version or classifier. If the project only releases a source tarball, then it needs to go onto that, and so on. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
Re: [DISCUSS] Apache Zest pTLP proposal
[-board] Roman, I am also pleased to see your effort, and likewise comments/edits on page are not available to me, so I post here... I am wondering why there is anything about the committers at all? 1. All committers on the project are also subscribed to the private@ ML of a pTLP 2. Any member of the community can nominate new committers. The vote is conducted as usual (with only PMC members having binding votes) however it is expected that PMC members are going to vote last and simply validate the consensus of the community. especially since a few paragraphs earlier, it is said; committers can be chosen however the community decides and The Board doesn't care about committership, so the pTLP can do whatever it wants in that regard. It seems a bit inconsistent. // Niclas On Tue, Feb 10, 2015 at 2:35 PM, Roman Shaposhnik r...@apache.org wrote: Hi! an existing open source community seeking to enter ASF has decided to try an alternative route and participate in the pTLP experiment. Please refer to: https://cwiki.apache.org/confluence/display/COMDEV/Provisional+TLP for an up-to-date record and documentation on what pTLP is and how it relates to the traditional Incubation process. At this point we would like to invite IPMC to help us with shaping up the pTLP proposal to a point where we can successfully submit it to the ASF board. Please comment on the Apache Zest pTLP proposal and feel free to provide your feedback directly on the ComDev wiki: https://cwiki.apache.org/confluence/display/COMDEV/Proposal+for+Apache+Zest+pTLP Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
Re: Practical next steps for pTLP experiment
Roman, Under the JIRA section, I made a mistake earlier; https://ops4j1.jira.com/browse/ZEST should be https://ops4j1.jira.com/browse/QI Niclas On Tue, Feb 10, 2015 at 2:48 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Mon, Feb 2, 2015 at 4:47 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Mon, Feb 2, 2015 at 1:41 PM, Benson Margulies bimargul...@gmail.com wrote: ...2: 'let's go over to comdev and volunteer to build some documentation for an alternative launch mechanism'. This experiments with expanding comdev in the direction The momentary impulse is (2). You might find it tolerable. Yes, as long as it's done and discussed openly on the comdev list. Please help with both: https://cwiki.apache.org/confluence/display/COMDEV/Provisional+TLP https://cwiki.apache.org/confluence/display/COMDEV/Proposal+for+Apache+Zest+pTLP Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
Re: [DISCUSS] Commons RDF to join the Apache Incubator
I guess, if there is no single aspect to discuss, we can move forward with an official vote, right? On 05/02/15 08:49, Sergio Fernández wrote: Hello everyone, I would like to propose Commons RDF, a small library providing a common API for RDF 1.1. The current draft of the proposal is here: http://wiki.apache.org/incubator/CommonsRDF The main motivation behind this simple library is revise an historical incompatibility issue in the Java world. In particular, commons RDF aims to provide a type-safe, non-general API that covers RDF 1.1. The path for the project is clear. But in this phase Commons RDF has to focus on the API design, which actively involves developers of existing toolkits, so it is better to have a more focused community and infrastructure than the Commons Sandbox. Then we have come to the conclusion that incubation is probably the best path, and then gradually prepare the Commons RDF community for working within the larger Apache Commons community. Therefore we hope the possible conflict with the name of this podling would not been seen as a problem during incubation. We would gladly welcome additional volunteers to act as mentors on the project, as well as a champion, preferable someone with any relationship with the Apache Common community. Thanks! Andy, Peter, Stian, Reto and Sergio -- Sergio Fernández Senior Researcher Knowledge and Media Technologies Salzburg Research Forschungsgesellschaft mbH Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria T: +43 662 2288 318 | M: +43 660 2747 925 sergio.fernan...@salzburgresearch.at http://www.salzburgresearch.at - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Is the Incubator a product? If so, why are there so few bugs?
On 9 February 2015 at 21:59, John D. Ament johndam...@apache.org wrote: I noticed that as well. I'm assuming it's in part because no one has access to the incubator JIRA. How come ? of course you need a jira account, but incubator jira does not seem to have specially closed permissions. https://issues.apache.org/jira/browse/INCUBATOR/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel John On Mon Feb 09 2015 at 3:57:23 PM Julian Hyde jh...@apache.org wrote: Guess how many bugs have been logged against the Incubator in the last 2 years? Only four[1]. The recent discussions about effective mentoring got me thinking. I know that my mentors are busy people, so I don't bother them with a question unless I've first tried to find the answer. In fact, most of the time I don't want to be mentored as such: I just want the Incubator to provide a clear process that I can find using five minutes and a couple of google searches. It seems clear (at least to me) that the Incubator provides a product. That product is an explanation of the Apache process, as clear as possible, and as accessible as possible. When the process is not clear, that is a bug in the product. So, when a discussion on this list did not yield a clear answer, I logged a bug[2]. That's when I discovered that virtually no one else is logging bugs against the Incubator, and I found that really surprising. Let me expand on the product metaphor. The Incubator provides guidance on the Apache process, and the projects follow it, learn, and due course graduate. The product here is the explanation of the Apache process. The customers here are the incubation projects. The product is imperfect and always changing, but everyone wants to improve it, and the way to do that is by logging issues. The contract is that the customers (the projects) commit to logging the issues they encounter (and if possible make contributions to fix those issues), and the the producer (the Incubator) commits to resolve those issues in a timely fashion. So then, why is the Incubator not imploring the projects to log more issues? A very straight and very fine argumentation, I like it a lot (and agree with it). rgds jan i. Julian [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20INCUBATOR [2] https://issues.apache.org/jira/browse/INCUBATOR-129 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Draft Report February 2015 - please review
Hi, I can reply about SAMOA. We want to create bylaws because the default voting process for code changes in Apache is too strict for us (3 +1 binding votes). Being a small community, we felt that we needed a lower bar to move faster. My understanding is that we need bylaws to specify that, but maybe I missed something and I'm happy to be corrected. Cheers, -- Gianmarco On 10 February 2015 at 00:35, Marvin Humphrey mar...@rectangular.com wrote: Hello, Incubator community, As discussed in a recent thread on Mentoring, the draft report email provides an opportunity for cross-cutting feedback. So here goes! The top-level report was not yet complete when the draft was sent out (and what sections were there I wrote), so I have nothing to say about that. But I have some comments in response to the podling reports for Droids, HTrace, Ripple, SAMOA, and Sirona which I hope will prove constructive. Droids Droids aims to be an intelligent standalone robot framework that allows to create and extend existing droids (robots). Droids has been incubating since 2008-10-09. Three most important issues to address in the move towards graduation: 1. Activity 2. Name Search Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? None. We need to continue the name search. Branding has replied to the issue and provided additional searches that need to performed. It is hoped that these can be finished in the new couple weeks. How has the community developed since the last report? No change. How has the project developed since the last report? No change. Date of last release: 2012-10-15 When were the last committers or PMC members elected? 2012-05-07 Signed-off-by: [ ](droids) Thorsten Scherler [x](droids) Richard Frovarp Shepherd/Mentor notes: It's my understanding that Droids is basically a mature product with no pressing need for further development, not unlike some dormant Apache TLPs who neverthess still have PMC members hanging around able to make releases and respond to user inquiries. I think the greater IPMC ought to stay aware, though, that Droids has very, very low activity: 3 dev list emails in the last quarter (39 in the last year), no user list, and no commits since April 2013. The only thing between Droids and retirement is our deference to Richard and Thorsten. They form the potential core of a community, but it has yet to develop in 6 years of incubation. HTrace HTrace is a tracing framework intended for use with distributed systems written in java. HTrace has been incubating since 2014-11. Three most important issues to address in the move towards graduation: 1. Continue to grow the HTrace community 2. Continue to develop and release stable HTrace incubating artifacts 3. Continue to explore the integration of the HTrace framework into other Apache products Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? Around January 20th HTrace successfully made the first release whilst in the Apache Incubator. This was the outcomes of no-less than 10 release candidates and as many VOTE's. In all every release candidate was very well managed with HTrace community providing excellent feedback to the release manager. Rather than then entire 10 release candidate exercise being a pain point for the community, it appears to have strengthened all involved. Well done HTrace. How has the community developed since the last report? It is early incubating days for HTrace. The community has attracted in particular a new member who is doing a sterling job on a new UI for HTrace. Additionally it should be noted that the entire htrace-3.1.0-incubating release effort has certainly brought the existing community on leaps and bounds. How has the project developed since the last report? The project has progressed significantly. In fact, it was highlighted on at least one occasion that documentation supporting a release candidate should be further clarified/improved due to the dynamic progressive nature of the HTrace codebase. As an early incubating project this is accepted as a positive move. Date of last release: 2015-20-01 When were the last committers or PMC members elected? ??? Signed-off-by: [X](htrace) Jake Farrell [ ](htrace) Todd Lipcon [X](htrace) Lewis John Mcgibbney [ ](htrace) Andrew Purtell [X](htrace) Billie Rinaldi [X](htrace) Michael Stack 10 release candidates is a lot. Were the difficulties primarily the result of the community needing to develop and document its own release routines? It sounds like that was the case, which would be reasonable. But if, say, determining compliance with
Re: Draft Report February 2015 - please review
On 10 February 2015 at 11:44, Gianmarco De Francisci Morales g...@apache.org wrote: Hi, I can reply about SAMOA. We want to create bylaws because the default voting process for code changes in Apache is too strict for us (3 +1 binding votes). Being a small community, we felt that we needed a lower bar to move faster. My understanding is that we need bylaws to specify that, but maybe I missed something and I'm happy to be corrected. You do not need bylaws for that, all you need is a discussion among the PMCs and a mail thread that shows consensus. The (P)PMC can make its own rules, as long as it is discussed and consensus is reached (of course the few Incubator and ASF rules cannot be overwritten). Especially for small communities code changes need to be flexible. I am however not sure why think 3 +1 is needed for a code change, can it be you mix release vote with code changes ? In incubator you do need 3 +1 votes from IPMC to cut a release and of course consensus in the PPMC, but that is not something the project can overwrite with bylaws. rgds jan i. Cheers, -- Gianmarco On 10 February 2015 at 00:35, Marvin Humphrey mar...@rectangular.com wrote: Hello, Incubator community, As discussed in a recent thread on Mentoring, the draft report email provides an opportunity for cross-cutting feedback. So here goes! The top-level report was not yet complete when the draft was sent out (and what sections were there I wrote), so I have nothing to say about that. But I have some comments in response to the podling reports for Droids, HTrace, Ripple, SAMOA, and Sirona which I hope will prove constructive. Droids Droids aims to be an intelligent standalone robot framework that allows to create and extend existing droids (robots). Droids has been incubating since 2008-10-09. Three most important issues to address in the move towards graduation: 1. Activity 2. Name Search Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? None. We need to continue the name search. Branding has replied to the issue and provided additional searches that need to performed. It is hoped that these can be finished in the new couple weeks. How has the community developed since the last report? No change. How has the project developed since the last report? No change. Date of last release: 2012-10-15 When were the last committers or PMC members elected? 2012-05-07 Signed-off-by: [ ](droids) Thorsten Scherler [x](droids) Richard Frovarp Shepherd/Mentor notes: It's my understanding that Droids is basically a mature product with no pressing need for further development, not unlike some dormant Apache TLPs who neverthess still have PMC members hanging around able to make releases and respond to user inquiries. I think the greater IPMC ought to stay aware, though, that Droids has very, very low activity: 3 dev list emails in the last quarter (39 in the last year), no user list, and no commits since April 2013. The only thing between Droids and retirement is our deference to Richard and Thorsten. They form the potential core of a community, but it has yet to develop in 6 years of incubation. HTrace HTrace is a tracing framework intended for use with distributed systems written in java. HTrace has been incubating since 2014-11. Three most important issues to address in the move towards graduation: 1. Continue to grow the HTrace community 2. Continue to develop and release stable HTrace incubating artifacts 3. Continue to explore the integration of the HTrace framework into other Apache products Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? Around January 20th HTrace successfully made the first release whilst in the Apache Incubator. This was the outcomes of no-less than 10 release candidates and as many VOTE's. In all every release candidate was very well managed with HTrace community providing excellent feedback to the release manager. Rather than then entire 10 release candidate exercise being a pain point for the community, it appears to have strengthened all involved. Well done HTrace. How has the community developed since the last report? It is early incubating days for HTrace. The community has attracted in particular a new member who is doing a sterling job on a new UI for HTrace. Additionally it should be noted that the entire htrace-3.1.0-incubating release effort has certainly brought the existing community on leaps and bounds. How has the project developed since the last report? The project has progressed
Re: [DISCUSS] Commons RDF to join the Apache Incubator
On 11 February 2015 at 07:31, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Feb 10, 2015 at 7:21 AM, Stian Soiland-Reyes st...@apache.org wrote: The natural path to Apache Commons Sandbox has been studied, but we think that in this phase of the project, which focuses on the API design and actively involves the developers of existing toolkits, it is better to have a more focused community and infrastructure. Rather than a new Top-Level Project, the goal is still to graduate as part of Apache Commons, that is when API has achieve the required maturity and the project goes into maintenance mode. If Commons is OK with this, I imagine this is a fine plan -- good enough for entering incubation. I also think it would be OK for the project to decide it wants to become a TLP. Whether the project joins Commons or becomes its own TLP won't impact the number of people qualified to work on it. Some Apache TLPs are effectively in maintenance mode and have very low activity, but still have PMC members willing to answer user questions, make security releases and file still here quarterly reports. That seems like a legitimate aspiration for this project. A potential Jena destination also seems as though it would have certain advantages, though my naive speculation is that it might be sub-optimal in terms of providing neutral territory for negotiating a common API for Jena and Sesame. I don't think it would be appropriate inside of Jena for similar reasons, although not just related to Sesame, as there are other JVM toolkits that we also want to attract in a neutral way. For similar reasons it wouldn't be appropriate within the other related Apache projects, although it will likely be used by all of them in the end (Any23/Marmotta/Stanbol/Clerezza/Taverna). In any case it seems likely that if the project achieves its design goal, there will be people willing to work on it as long as both Jena and Sesame remain viable. That makes it different from other potential maintenance mode TLPs which are in danger of stagnation because they cannot renew their communities. Both Jena and Sesame will remain viable for a while to come IMO, based on the commercial users of both platforms and their respective communities are both well-established and active. Is that take roughly accurate, Sergio et al? === Mailing lists === * commons-rdf-dev * commons-rdf-commits Those sound like final mailing lists rather than Incubator ones. I might have expected these instead: d...@commons-rdf.incubator.apache.org comm...@commons-rdf.incubator.apache.org Do you expect to keep separate mailing lists after graduation, or will traffic be shunted onto existing Commons mailing list like d...@commons.apache.org and comm...@commons.apache.org? I would expect the level of discussion and commits to go down just after graduation, per our goal to have a stable common interface, so being then integrating into the main commons dev would be the likely channel. However, unlike previous APIs, we do have the advantage of Java-8 default methods, so we can also add to the API while maintaining backwards compatibility, so we are open for additions even after the initial version of the API is finalised. * Sergio Fernández (wikier dot apache dot org) * Andy Seaborne (andy dot apache dot org) * Peter Ansell (ansell dot apache dot org) * Stian Soiland-Reyes (stain at apache dot org) * Reto Gmür (reto at apache dot org) Lots of Apache experience in this group. Four are PMC members of at least one Apache project. Andy and Reto are ASF Members. Andy and Sergio are both IPMC members. Stian is a core contributor of the Taverna podling. You probably haven't been getting much feedback because there's a lot going on in the Incubator right now and everybody figures that with a group like that you're in good shape. :) === Champion === * TBD The Champion's main work is to help formulate the proposal. That work is essentially done -- so it doesn't matter too much who takes that role, now. Are Andy and Reto opting out out as a gesture of openness to Sesame? Sergio has been the Champion from the beginning, but anyone who is at the right community position from the team would be great. === Nominated Mentors === * Benedikt Ritter (britter at apache dot org) * TBD Benedikt is a member of the Commons PMC, but he's not a member of the IPMC nor an Apache Member -- so although Commons input is important, unfortunately it's not a valid nomination. I'd nudge newly elected IPMC member Rob Vesse, but maybe the roster is already Jena-heavy? I don't think that is an issue. Rob Vesse would be very appropriate for that position IMO given his experience. Cheers, Peter - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Practical next steps for pTLP experiment
On Mon, Feb 2, 2015 at 4:38 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I missed a few important points in this thread last week, with which I disagree: On Tue, Jan 27, 2015 at 7:28 PM, Greg Stein gst...@gmail.com wrote: ...1) Draft a template resolution. Starting in the wiki is fine, but you'll want to involve board@ when you have your first draft done IMO board members have more important things to do than work on draft resolutions for new projects, Read it again, Bertrand: TEMPLATE RESOLUTION. The Board doesn't let arbitrary resolutions just drop on our desk. We expect them to be in a form that we agree with. Thus, any pTLP resolution must fit our expectations. That means how does this look, Board? what needs to change? Part of that has already occurred, when I provided some feedback on the (concrete) Zest resolution. A template still needs to be created from that. and it's also important for drafts of new projects to be discussed in public. If only to allow new people and mentors to jump in. Resolutions don't need to be discussed, since they are fill in the blank from a template. What needs to be discussed with the Board, is that template. I strongly suggest discussing such draft resolutions on this list. Even if the Incubator PMC is not formally involved in managing those pTLPs, this list is where the know-how about creating new projects resides, I see no reason to move that work elsewhere. Already agreed to. No need to beat that dead horse. ...2) Create a ComDev page discussing what it means to be a provisional TLP I don't understand why people want these things to move to comdev - did you even ask the comdev PMC about this? It sounds like people want to send a bunch of tasks their way, without even asking. It was brought up on dev@ just like it should, Bertrand. Stop assuming the worst. I see no reason for the pTLP process definition to happen outside of the Incubator, which is the PMC tasked with bringing new projects to the ASF. Who ever said the Incubator has the exclusive Right to be the only way to become part of the Apache Software Foundation? New approaches can be discussed anywhere. At the end of the day, it will be the Board who votes on a pTLP resolution. -g
Re: [DISCUSS] Commons RDF to join the Apache Incubator
On Tue, Feb 10, 2015 at 7:21 AM, Stian Soiland-Reyes st...@apache.org wrote: The natural path to Apache Commons Sandbox has been studied, but we think that in this phase of the project, which focuses on the API design and actively involves the developers of existing toolkits, it is better to have a more focused community and infrastructure. Rather than a new Top-Level Project, the goal is still to graduate as part of Apache Commons, that is when API has achieve the required maturity and the project goes into maintenance mode. If Commons is OK with this, I imagine this is a fine plan -- good enough for entering incubation. I also think it would be OK for the project to decide it wants to become a TLP. Whether the project joins Commons or becomes its own TLP won't impact the number of people qualified to work on it. Some Apache TLPs are effectively in maintenance mode and have very low activity, but still have PMC members willing to answer user questions, make security releases and file still here quarterly reports. That seems like a legitimate aspiration for this project. A potential Jena destination also seems as though it would have certain advantages, though my naive speculation is that it might be sub-optimal in terms of providing neutral territory for negotiating a common API for Jena and Sesame. In any case it seems likely that if the project achieves its design goal, there will be people willing to work on it as long as both Jena and Sesame remain viable. That makes it different from other potential maintenance mode TLPs which are in danger of stagnation because they cannot renew their communities. Is that take roughly accurate, Sergio et al? === Mailing lists === * commons-rdf-dev * commons-rdf-commits Those sound like final mailing lists rather than Incubator ones. I might have expected these instead: d...@commons-rdf.incubator.apache.org comm...@commons-rdf.incubator.apache.org Do you expect to keep separate mailing lists after graduation, or will traffic be shunted onto existing Commons mailing list like d...@commons.apache.org and comm...@commons.apache.org? * Sergio Fernández (wikier dot apache dot org) * Andy Seaborne (andy dot apache dot org) * Peter Ansell (ansell dot apache dot org) * Stian Soiland-Reyes (stain at apache dot org) * Reto Gmür (reto at apache dot org) Lots of Apache experience in this group. Four are PMC members of at least one Apache project. Andy and Reto are ASF Members. Andy and Sergio are both IPMC members. Stian is a core contributor of the Taverna podling. You probably haven't been getting much feedback because there's a lot going on in the Incubator right now and everybody figures that with a group like that you're in good shape. :) === Champion === * TBD The Champion's main work is to help formulate the proposal. That work is essentially done -- so it doesn't matter too much who takes that role, now. Are Andy and Reto opting out out as a gesture of openness to Sesame? === Nominated Mentors === * Benedikt Ritter (britter at apache dot org) * TBD Benedikt is a member of the Commons PMC, but he's not a member of the IPMC nor an Apache Member -- so although Commons input is important, unfortunately it's not a valid nomination. I'd nudge newly elected IPMC member Rob Vesse, but maybe the roster is already Jena-heavy? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: -incubator in versions of podling maven artifacts
On Tue, Feb 10, 2015 at 6:50 PM, Benson Margulies bimargul...@gmail.com wrote: Since the only official release is the source release, perhaps that's the only place where we in fact need a policy? I would really encourage us to keep this for Maven. Especially for Maven where you may have no clue about the status of the project. And honestly, I don't see what's the big deal of having -incubating in a version string. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Practical next steps for pTLP experiment
On Tue, Feb 10, 2015 at 1:07 AM, Niclas Hedhman nic...@hedhman.org wrote: Roman, Under the JIRA section, I made a mistake earlier; https://ops4j1.jira.com/browse/ZEST should be https://ops4j1.jira.com/browse/QI Fixed! As a side note: I really need to figure out how to make sure this is a real wiki that allows folks to collaborate. Stay tuned -- I'll try to ping the ASF INFRA tomorrow. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Zest pTLP proposal
On Tue, Feb 10, 2015 at 10:49 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: Also, great job on writing this up. I have a few amendments, which I will just put into email since I can’t do so on the wiki: Man, this is annoying -- let me see what I can do. I really don't think I can take on this sisyphean task of maintaining it all by myself -- I need to figure out how to enable the rest of the community to contribute to the docs ;-) Drill has just adopted the Github approach of putting the site into Markdown format and using conventional version control on it. Then we munch the site into static HTML using Jekyll and push it into SVN to deploy. Works. Dead simple.
Re: -incubator in versions of podling maven artifacts
On Tue, Feb 10, 2015 at 9:56 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: On Tue, Feb 10, 2015 at 6:50 PM, Benson Margulies bimargul...@gmail.com wrote: Since the only official release is the source release, perhaps that's the only place where we in fact need a policy? I would really encourage us to keep this for Maven. Especially for Maven where you may have no clue about the status of the project. And honestly, I don't see what's the big deal of having -incubating in a version string. +1. This is a very useful practice. One of the first actions of a newly top-level project should be to make a release and that is a perfect time to remove the mark. It's a great transition ritual.
Re: [DISCUSS] Apache Zest pTLP proposal
On Mon, Feb 9, 2015 at 10:49 PM, Chris Mattmann mattm...@apache.org wrote: Hi Roman, I can’t seem to comment on the COMDEV wiki page. Also, great job on writing this up. I have a few amendments, which I will just put into email since I can’t do so on the wiki: Man, this is annoying -- let me see what I can do. I really don't think I can take on this sisyphean task of maintaining it all by myself -- I need to figure out how to enable the rest of the community to contribute to the docs ;-) bq. Initially, a pTLP's PMC is only allowed to consist of ASF Members. s/ASF Members/ASF Members and individuals identified as initial PMC members on the pTLP proposal*/ * - incoming PMC members on the pTLP not already ASF members will need to be justified in the incoming proposal. Fixed! Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Practical next steps for pTLP experiment
On Tue, Feb 10, 2015 at 3:35 PM, Greg Stein gst...@gmail.com wrote: Who ever said the Incubator has the exclusive Right to be the only way to become part of the Apache Software Foundation? New approaches can be discussed anywhere. At the end of the day, it will be the Board who votes on a pTLP resolution. Resolution R2, paragraph 3: http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt That being said, it is perfectly in bounds for new resolutions to be proposed and considered. Also worth reading (search for proposed resolution): http://apache.org/foundation/records/minutes/2012/board_minutes_2012_07_25.txt -g - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Draft Report February 2015 - please review
Hi, When reviewing the podling (as a shepherd) I at first allso though it odd, however they have looked into what other projects are doing and are using RTC not CTR. The discussion (as I understand it) is about accepting non committer code not all code changes. This is the relevant thread [1] and in particular [2]. Thanks, Justin 1.http://markmail.org/thread/etghyo5w5zykuhtp 2. http://markmail.org/message/a4xu7wacfchj3o6k - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Commons RDF to join the Apache Incubator
On 10 February 2015 at 20:31, Marvin Humphrey mar...@rectangular.com wrote: I also think it would be OK for the project to decide it wants to become a TLP. Whether the project joins Commons or becomes its own TLP won't impact the number of people qualified to work on it. Some Apache TLPs are effectively in maintenance mode and have very low activity, but still have PMC members willing to answer user questions, make security releases and file still here quarterly reports. That seems like a legitimate aspiration for this project. Right - I think it would be good to leave as a decision to be made by the PPMC when we get closer to graduation. One problem with TLP is that we would likely need a different name ;-) A potential Jena destination also seems as though it would have certain advantages, though my naive speculation is that it might be sub-optimal in terms of providing neutral territory for negotiating a common API for Jena and Sesame. Right, the idea is for this to get a common, neutral ground. Although several of the existing implementations, including Jena and Clerezza, already have the 'abstract' sense of this API, but Commons RDF API aims to be common across those, and not to pick sides. So we have agreed that the new API has to live outside the bigger frameworks. In any case it seems likely that if the project achieves its design goal, there will be people willing to work on it as long as both Jena and Sesame remain viable. That makes it different from other potential maintenance mode TLPs which are in danger of stagnation because they cannot renew their communities. I imagine the API would not evolve much once it stabilizes - there's only that much maintenance you can do on an Java interface :). But there are additional things we are trying out, like a simple reference implementation, compliance tests, and event notifications. Some general utility functions could also evolve later (e.g. Copy complete graph from implementation A to implementation B) - but during incubation we would want to focus on the core interfaces and integration with the existing implementations. As our community evolves, I guess documentation would also play a role - the API aims to be common across the RDF implementations - therefore users of the API could be considered a single community (compare with say the JAXB API) - so some usage documentation and tutorials could be appropriate. This would however point out to details in the (Apache and non-Apache) implementations. Those sound like final mailing lists rather than Incubator ones. I might have expected these instead: d...@commons-rdf.incubator.apache.org comm...@commons-rdf.incubator.apache.org My guess is that Sergio just suggested classic addresses out of habit. :-) Personally I would agree with the above. Do you expect to keep separate mailing lists after graduation, or will traffic be shunted onto existing Commons mailing list like d...@commons.apache.org and comm...@commons.apache.org? Right - part of the community building (if we continue the Commons route) is to gradually move (the decreasing) traffic to the existing dev@commons lists. Commons don't want to split the community with new component-specific lists, which we can understand. However we felt that to start out with growing the Commons RDF community on dev@commons would be a bit of a challenge (300 to 1000 messages/month!) - so part of the motivation for incubation is to have a more separate space within Apache while we flesh out API design and implementation questions - and then whoever survives so to speak should be able to move along as we join @commons. :-) Lots of Apache experience in this group. Four are PMC members of at least one Apache project. Andy and Reto are ASF Members. Andy and Sergio are both IPMC members. Stian is a core contributor of the Taverna podling. You probably haven't been getting much feedback because there's a lot going on in the Incubator right now and everybody figures that with a group like that you're in good shape. :) Agree, Commons RDF is a slightly different proposal - in a way we need the incubator mainly to mature the API (e.g. fight over method names) and grow the community, rather than to be a podling to learn the Apache Way and battle with NOTICE files. As you see below, though - we still need volunteer mentors. The Champion's main work is to help formulate the proposal. That work is essentially done -- so it doesn't matter too much who takes that role, now. Are Andy and Reto opting out out as a gesture of openness to Sesame? Sergio has effectively been the Champion for this proposal, but I guess he's not technically admissible as the Champion needs to be a Member or Director. === Nominated Mentors === * Benedikt Ritter (britter at apache dot org) * TBD Benedikt is a member of the Commons PMC, but he's not a member of the IPMC nor an Apache Member -- so although Commons input
Re: Draft Report February 2015 - please review
+1 to jan's comments Ideally you should not be carrying out votes for code changes unless you can't progress without it. In some Apache projects I've participated in I don't think we've ever held a formal vote on code changes. It's fairly common to informally use +1/0/-1 to expression opinions as part of our design discussions but we haven't ever had the need to call a formal vote. You should always be trying to have discussions first and come to a consensus such that you can just go ahead with the proposed changes. In the event that someone votes -1 then that should be treated as a veto and you need to go back to the drawing board and/or discuss further until their concerns are addressed and the -1 is withdrawn http://apache.org/foundation/voting.html#votes-on-code-modification If your community is small then hopefully it should be easy to reach a consensus Rob On 10/02/2015 11:26, jan i j...@apache.org wrote: On 10 February 2015 at 11:44, Gianmarco De Francisci Morales g...@apache.org wrote: Hi, I can reply about SAMOA. We want to create bylaws because the default voting process for code changes in Apache is too strict for us (3 +1 binding votes). Being a small community, we felt that we needed a lower bar to move faster. My understanding is that we need bylaws to specify that, but maybe I missed something and I'm happy to be corrected. You do not need bylaws for that, all you need is a discussion among the PMCs and a mail thread that shows consensus. The (P)PMC can make its own rules, as long as it is discussed and consensus is reached (of course the few Incubator and ASF rules cannot be overwritten). Especially for small communities code changes need to be flexible. I am however not sure why think 3 +1 is needed for a code change, can it be you mix release vote with code changes ? In incubator you do need 3 +1 votes from IPMC to cut a release and of course consensus in the PPMC, but that is not something the project can overwrite with bylaws. rgds jan i. Cheers, -- Gianmarco On 10 February 2015 at 00:35, Marvin Humphrey mar...@rectangular.com wrote: Hello, Incubator community, As discussed in a recent thread on Mentoring, the draft report email provides an opportunity for cross-cutting feedback. So here goes! The top-level report was not yet complete when the draft was sent out (and what sections were there I wrote), so I have nothing to say about that. But I have some comments in response to the podling reports for Droids, HTrace, Ripple, SAMOA, and Sirona which I hope will prove constructive. Droids Droids aims to be an intelligent standalone robot framework that allows to create and extend existing droids (robots). Droids has been incubating since 2008-10-09. Three most important issues to address in the move towards graduation: 1. Activity 2. Name Search Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? None. We need to continue the name search. Branding has replied to the issue and provided additional searches that need to performed. It is hoped that these can be finished in the new couple weeks. How has the community developed since the last report? No change. How has the project developed since the last report? No change. Date of last release: 2012-10-15 When were the last committers or PMC members elected? 2012-05-07 Signed-off-by: [ ](droids) Thorsten Scherler [x](droids) Richard Frovarp Shepherd/Mentor notes: It's my understanding that Droids is basically a mature product with no pressing need for further development, not unlike some dormant Apache TLPs who neverthess still have PMC members hanging around able to make releases and respond to user inquiries. I think the greater IPMC ought to stay aware, though, that Droids has very, very low activity: 3 dev list emails in the last quarter (39 in the last year), no user list, and no commits since April 2013. The only thing between Droids and retirement is our deference to Richard and Thorsten. They form the potential core of a community, but it has yet to develop in 6 years of incubation. HTrace HTrace is a tracing framework intended for use with distributed systems written in java. HTrace has been incubating since 2014-11. Three most important issues to address in the move towards graduation: 1. Continue to grow the HTrace community 2. Continue to develop and release stable HTrace incubating artifacts 3. Continue to explore the integration of the HTrace framework into other Apache products Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? Around January 20th HTrace successfully made the first
RE: Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator
Just out of curious. My coworker is working on implementing DNN on Apache Hama (which supports general-purpose BSP computing and Pregel-like graph framework). If Hama is leveraging InfiniBand and GPUs in the future, what will be the major difference bt Hama-based DistBelief clone and Singa project? And, how much performance difference bt async and sync? Thanks. -- Best Regards, Edward J. Yoon -Original Message- From: 윤진석 [mailto:edward.y...@samsung.com] Sent: Wednesday, February 11, 2015 8:32 AM To: edward.y...@samsung.com Subject: Re: Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator --- Original Message --- Sender : Thejas Nairthejas.n...@gmail.com Date : 2015-02-04 08:58 (GMT+09:00) Title : Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator The Relationship with Other Apache Products section has been updated. The reference to H2O in that section has been removed, and other projects have been added. Thanks for the feedback! On Wed, Jan 28, 2015 at 10:27 AM, Thejas Nair wrote: Thanks for pointing that out Henry! Yes, looks like H20 is not an apache project, I should have verified that. I will edit that, and revisit that section along with the folks in Singa community. On Tue, Jan 27, 2015 at 6:55 PM, Henry Saputra wrote: Quick immediate comment that Apache H2O is not really Apache project. I assume you are referring to https://github.com/h2oai/h2o (or https://github.com/h2oai/h2o-dev) ? - Henry On Tue, Jan 27, 2015 at 5:29 PM, Thejas Nair wrote: Hello everyone, I would like to propose the inclusion of Singa as an Apache Incubator project. Here is the proposal - https://wiki.apache.org/incubator/SingaProposal Please review the proposal and give feedback. I am planning to start a vote after 7 days if the proposal looks good. We are also seeking additional Apache mentors for the project. Thanks, Thejas == Singa Incubator Proposal Abstract SINGA is a distributed deep learning platform. Proposal SINGA is an efficient, scalable and easy-to-use distributed platform for training deep learning models, e.g., Deep Convolutional Neural Network and Deep Belief Network. It parallelizes the computation (i.e., training) onto a cluster of nodes by distributing the training data and model automatically to speed up the training. Built-in training algorithms like Back-Propagation and Contrastive Divergence are implemented based on common abstractions of deep learning models. Users can train their own deep learning models by simply customizing these abstractions like implementing the Mapper and Reducer in Hadoop. Background Deep learning refers to a set of feature (or representation) learning models that consist of multiple (non-linear) layers, where different layers learn different levels of abstractions (representations) of the raw input data. Larger (in terms of model parameters) and deeper (in terms of number of layers) models have shown better performance, e.g., lower image classification error in Large Scale Visual Recognition Challenge. However, a larger model requires more memory and larger training data to reduce over-fitting. Complex numeric operations make the training computation intensive. In practice, training large deep learning models takes weeks or months on a single node (even with GPU). Rational Deep learning has gained a lot of attraction in both academia and industry due to its success in a wide range of areas such as computer vision and speech recognition. However, training of such models is computationally expensive, especially for large and deep models (e.g., with billions of parameters and more than 10 layers). Both Google and Microsoft have developed distributed deep learning systems to make the training more efficient by distributing the computations within a cluster of nodes. However, these systems are closed source softwares. Our goal is to leverage the community of open source developers to make SINGA efficient, scalable and easy to use. SINGA is a full fledged distributed platform, that could benefit the community and also benefit from the community in their involvement in contributing to the further work in this area. We believe the nature of SINGA and our visions for the system fit naturally to Apache's philosophy and development framework. Initial Goals We have developed a system for SINGA running on a commodity computer cluster. The initial goals include, * improving the system in terms of scalability and efficiency, e.g., using Infiniband for network communication and multi-threading for one node computation. We would consider extending SINGA to GPU clusters later. * benchmarking with larger datasets (hundreds of millions of training instances) and models (billions of parameters). * adding more built-in deep learning models. Users can train the built-in models on their datasets directly. Current Status
Re: Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator
On Tue, Feb 10, 2015 at 3:33 PM, Edward J. Yoon edward.y...@samsung.com wrote: My coworker is working on implementing DNN on Apache Hama (which supports general-purpose BSP computing and Pregel-like graph framework). If Hama is leveraging InfiniBand and GPUs in the future, what will be the major difference bt Hama-based DistBelief clone and Singa project? And, how much performance difference bt async and sync? I think that, one of the big differences is that Singa is written in C++. Another is that Singa runs now. The present tense is always very powerful when it comes to software.
-incubator in versions of podling maven artifacts
Hi Incubator, I'd like some context about the requirement of adding -incubating in the file name of podling releases. http://incubator.apache.org/guides/releasemanagement.html http://incubator.apache.org/guides/release-java.html#best-practice-maven It seems we require adding -incubating in the version for maven artifacts which breaks Semantic versioning as hyphen is used for pre-releases. It is also confusing as we vote on a version number but that's not what we use as the artifact version. We are already publishing the source release in the incubator project and have incubating in its file name as well as DISCLAIMER files. So it seems to me that adding it in the maven artifact is a bit overkill. Every release as to get through the vote of the IPMC anyway so it's not like podlings releases are not vetted appropriately. opinions from the IPMC? Julien
Re: -incubator in versions of podling maven artifacts
Agree about the worry about breaking semantic versioning. OSGi-wise for example this is a bit tricky, where you have to do 0.5.3.incubating instead to ensure incubating is a qualifier rather than part of the 3. But if the project is publishing Maven artifacts, then I believe it's pretty clean if a project release time-line goes like this: (groupId:artifactId:version) org.apache.thingie:thingie-api:0.5.0-incubating org.apache.thingie:thingie-api:0.6.0-incubating org.apache.thingie:thingie-api:0.6.1 org.apache.thingie:thingie-api:1.0.0 .. rather than varying the groupId or artifactId before/after graduation. Here 0.6.1 is still a patch release from 0.6.0-incubating (so not breaking anything), but community-wise it is sending a stronger signal. I think formally the requirement is just that there is incubating somewhere in the released downloadables, it doesn't have to be part of the version number. On 10 February 2015 at 23:25, Julien Le Dem jul...@ledem.net wrote: Hi Incubator, I'd like some context about the requirement of adding -incubating in the file name of podling releases. http://incubator.apache.org/guides/releasemanagement.html http://incubator.apache.org/guides/release-java.html#best-practice-maven It seems we require adding -incubating in the version for maven artifacts which breaks Semantic versioning as hyphen is used for pre-releases. It is also confusing as we vote on a version number but that's not what we use as the artifact version. We are already publishing the source release in the incubator project and have incubating in its file name as well as DISCLAIMER files. So it seems to me that adding it in the maven artifact is a bit overkill. Every release as to get through the vote of the IPMC anyway so it's not like podlings releases are not vetted appropriately. opinions from the IPMC? Julien -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator
I think that, one of the big differences is that Singa is written in C++. Awesome, I'd be the first client. And anything from architectural viewpoint? -- Best Regards, Edward J. Yoon -Original Message- From: Ted Dunning [mailto:ted.dunn...@gmail.com] Sent: Wednesday, February 11, 2015 8:37 AM To: general@incubator.apache.org Subject: Re: Re: [DISCUSS] [PROPOSAL] Singa for Apache Incubator On Tue, Feb 10, 2015 at 3:33 PM, Edward J. Yoon edward.y...@samsung.com wrote: My coworker is working on implementing DNN on Apache Hama (which supports general-purpose BSP computing and Pregel-like graph framework). If Hama is leveraging InfiniBand and GPUs in the future, what will be the major difference bt Hama-based DistBelief clone and Singa project? And, how much performance difference bt async and sync? I think that, one of the big differences is that Singa is written in C++. Another is that Singa runs now. The present tense is always very powerful when it comes to software. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
