Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 08/11/10 18:32, Jeremy Carroll wrote: To make the commons discussion more concrete I would suggest the following items for the commons: - an IRI library - some code to do with vocabularies. - connecting to a URL and doing semweb aware content negotiation (this is typically done badly) (Actually the IRI code should probably be wider, Jena initially used the xerces URI code but then the needs exceeded what they supported) Jeremy Good idea. The IRI code is independent of the rest of Jena and is valuable in it's own right. ARP (Jena RDF/XML parser) is also independent of the Jena code structure and once was (is it still possible to get just ARP?). It's just the final step of generation that turns the output of parsing into Jena-specific objects. Might be worth splitting out if it would be useful. The lowest level of RIOT parsing, which defines the tokens for creating any of the Turtle family of langauges, is not Jena dependent. The actual RIOT parsers themselves are as they directly generate Jena-specific objects to avoid the copy overhead. It's a performance trade-off. [RIOT is a set of faster parsers for non-XML serializations of RDF, currently part of ARQ, but should migrate to Jena core when fully stable. - original need was parsers for formats capable of delivering to the TDB database at full loading speed without heavy CPU load.] But the command line tools based on RIOT which parse or validate one format are reusable - they use Jena internally, but the input and output are completely standard. The RDF validator Eyeball is also a useful tool in its own right. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 08/11/10 17:30, Ian Dickinson wrote: Hi Donald, On 08/11/10 17:01, Donald Whytock wrote: Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? I looked around in db.apache.org and I couldn't see anything that said what the goals of that project are, separate from the goals of the individual sub-projects. Where should I be looking? As others have noted, the three semantic web-related projects currently being proposed have rather different objectives and provide different capabilities. I personally don't object in principle to factoring out common code or needs where that's useful, but +1 to Olivier: let's wait until a clear requirement is identified. I agree. I don't think that a semantic XYZ is useful if that makes semantic some sort of different software. Semantic web technology is getting used more widely and a semantic commons or formal grouping of projects risks creating the idea that it's all or nothing, which isn't the case, hopefully. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
I haven't understood yet the relationship of Stanbol and Clerezza to be able to say anything about how a commons area between those two systems might work. In terms of direct dependencies, does Stanbol just directly depend on Clerezza and only indirectly on Sesame, Jena rdf2go and the OWLAPI that the proposal lists? Jena has two levels of API, the Model/Statement/Resource that applications usually use, and the SPI Graph/Triple/Node thathe the storage and inference layers plug into. Roughly, speaking, the API faces upwards to applications and the SPI downwards to components. There is also the same design for the support for RDF datasets for SPARQL. SPARQL, especially SPARQL Update, works on quads for named graphs. There are significant investments by users in uses of both API and SPI and the cost of change for users isn't trivial. Worse, the SPI is used by systems that are distributed on making any change over messy. There needs to be a real advantage to change. Speaking personally, I'm not strongly motivated by a common API; I don't think it helps the semantic web enough compared with other things I could work on. If others are working on one, I'll do what I can to make my contributions work as smoothly as possible with that through discussing what hooks and flexibility I can contribute to Jena to make it work smoothly with other systems. I'm not particularly worried about there being several APIs since that's the state we're in and I don't see it changing particularly quickly because there are large investments in deployed systems that exists. As some of these systems themselves are distributed onwards, chnage woudl be slow. Most of my contribution is storage and query which works at the lower level anyway, so it has less effect on me but the SPARQL related parts of the public APIs are mostly my fault. I am currently working on a SPARQL 1.1 compliant server - the on-the-wire standardization is more important. Working on storage and query does result in a slight obsession with efficiency - storage and query need to be tightly coupled for performance. Jeremy identified the IRI library as a potential contribution to a commons area. It is free-standing, and does not use or call any Jena RDF code - it depends only on ICU4J (and JUnit + Jflex in the build). The client-side content negotiation code in Jena could do with an upgrade so if there is system-independent code that can be reused for the systems here and more widely, that would be great. I would use it as I need to provide code-level access to for client SPARQL 1.1 access. If nothing else, shared knowledge and expertise would move things along faster, and even if functionality needs tying to specific systems, having all the projects in Apache greatly helps community. Andy PS Reto - GVS [*] isn't on the list of thing to contribute to Apache as we're focusing on the core system that is used and we support. But that does not preclude including GVS either now or later. It is covered by our agreement-in-principle with HP. Do you want to do that? [*] Reto wrote a graph versioning system for Jena several years ago. On 08/11/10 21:39, Reto Bachmann-Gmuer wrote: Hi Jeremy One of Clerezza aims was to use an RDF api that is maximally close to RDF abstract syntax and semantics, on this RDF core api we have different façades and utilities as well as a frontend adapter implementing the jena API. Related standards like SPARQL and the various serialization formats are supported as well, respective engines can be added at runtime (when running in a OSGI container). We decided to design our own API as we found the various API available (jena, openrdf, rdf2go) would neither be as modular nor as close to the spec as we wanted them to be. The API comes with the typical utilities like a command line tool and a maven plugin for the transformation of vocabularies into classes Apart from core part tightly coupled to RDF and related specs Clerezza also provides a framework for implementing rest applications (JAX-RS). The encourages design pattern is that requests are answered in terms of RDF (i.e. a graph and typically a selected resource within this graph), clerezza takes care about content-negotiation and for RDF formats the serializer registered for that media type is used. For non RDF formats a template (typically a Scala Server Pages) is selected and takes care of the rendering. I described this parts of Clerezza because they seem to be quite close to what you suggest for commons. As it is hard to share utilities without having shared APIs for the core stuff our code deals with I think some efforts in this area could have the greatest benefit. If you have some time, I would like to encourage feedback on the respective APIs as currently used in Clerezza - The core API for (mutable) graphs in: http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html -
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 09/11/10 16:22, Florent Guillaume wrote: On Tue, Nov 9, 2010 at 1:19 PM, Andy Seaborne andy.seabo...@epimorphics.com wrote: Jeremy identified the IRI library as a potential contribution to a commons area. It is free-standing, and does not use or call any Jena RDF code - it depends only on ICU4J (and JUnit + Jflex in the build). Please note that Abdera already has an IRI library. http://svn.apache.org/repos/asf/abdera/java/trunk/dependencies/i18n/src/main/java/org/apache/abdera/i18n/iri/ Florent, Thanks for pointing that out. I see it has a test suite as well and it would be good to make sure we've got things right. Illegal IRIs in data have been a bit of a plague in RDF data and the IRI library (written by Jeremy) is a response to that. It checks both rules for specific IRI schemes and also recommended forms as IRIs are often com pared for equality. The library is quite picky. It includes profiles for RDF URI references, IRI and the compromise we use in Jena as a balance of legacy and spec exactness. There is an online test service for RDF data in non-RDF/XML formats at: http://sparql.org/data-validator.html The IRIs are checked with the IRI library. Andy A few examples: http://example/a b Code: 17/WHITESPACE in PATH: A single whitespace character. These match no grammar rules of URIs/IRIs. These characters are permitted in RDF URI References, XML system identifiers, and XML Schema anyURIs. http://example/a[]b Code: 0/ILLEGAL_CHARACTER in PATH: The character violates the grammar rules for URIs/IRIs. http://example:80/ Code: 13/DEFAULT_PORT_SHOULD_BE_OMITTED in PORT: If the port is the default one for the scheme it should be omitted. http://example:80/ Code: 14/PORT_SHOULD_NOT_BE_WELL_KNOWN in PORT: Ports under 1024 should be accessed using the appropriate scheme name urn:xyz Code: 61/SCHEME_PATTERN_MATCH_FAILED in PATH: The scheme specific syntax rules are violated. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 09/11/10 16:59, Jeremy Carroll wrote: I could be accused of having gone overboard ... yes ... :-) Having changed job and looking at this from a different perspective I am less convinced by the pickiness. At least leave the picky mode there, please. It's been very helpful in working with data generated by one organisation and used by another. Script generated IRIs have been Once dubious data gets into a database, it's troublesome to get it out. Having the data storage only cover the required spec common ground is better. TDB uses the IRI profile (not RDF URI references) as strict as possible except that these two warnings are switched off: ViolationCodes.UNWISE_CHARACTER that is {, }, |, \, ^, ` It's the | that I found used in generated IRIs. Whitespace is handled separately. are syntax errors. ViolationCodes.UNREGISTERED_IANA_SCHEME because people invent schemes for data. I did find the most strict mode a bit too strict :-) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 10/11/10 23:28, Jeremy Carroll wrote: - The core API for (mutable) graphs in: http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/org/apache/clerezza/rdf/core/TripleCollection.html#filter(org.apache.clerezza.rdf.core.NonLiteral,%20org.apache.clerezza.rdf.core.UriRef,%20org.apache.clerezza.rdf.core.Resource) IteratorTriple filter(NonLiteral subject, UriRef predicate, Resource object) vs http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Graph.html#find(com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node) ExtendedIteratorTriple find(Node s, Node p, Node o) seems to be the fundamental choice. The latter was the choice Chris Dollin and I made in 2002/2003 and I still find it preferable, for program uniformity, to the closer to the spec choice in Clerezza. We were writing the spec at the same time, and I always saw it as a description of a Web exchange format, and not of a programming interface (for instance implementing RDF Semantics Rec is hard with the Clerezza interface). Isn't the model interface operation a more appropriate comparision because that is what the application sees? StmtIterator listStatements(Resource s, Property p, RDFNode o) Graph.find is the SPI interface to storage. The Graph level has named variables, not just RDF terms. SPARQL uses this, heavily. In SPARQL, literals can occur in any position during query processing. Patterns involving literals as subjects, or as predicates, just simply don't match the data (section 12.3.1). Once upon a time, when we were going Jena1-Jena2, the idea was that the application API was just one presentation. There could be other RDF APIs over the SPI. There's not been a second RDF presentation API but the design concept was there and still is. All the interfaces in the API are mainly implemented only once, and I'm not aware of any users which use the extensibility within the Resource API anymore (Parliament/BBN used to - I think they now use an associated datastructure to map to internal information for any API resources/literals from their storage). The Resource-level API implementation could be simplified if theer is only one implementation of that presentation. There is generality in Jena that we thought was a good idea at the time but looking at way the world has gone since, not all of it is used or useful nowadays. Better use of factory/interface at the SPI would be more helpful. The experimental Jena3 core also has extension nodes and graph nodes with an eye to future possible needs from the standards world. I am not quite sure what that means in terms of this discussion which is more procedural than technical. Same here. Advice on an appropriate discussion forum welcome - while we're in a state of exploring the relationships of projects, I'm guessing that here is the only common place there is. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Accept Jena into the Incubator
On 12/11/10 08:40, Nick Kew wrote: On 8 Nov 2010, at 23:36, Ross Gardler wrote: I am pleased to offer, for your consideration, the following proposal to accept Jena, a semantic web framework into the incubator. The text of the proposal is copied here for your convenience and can be found at http://wiki.apache.org/incubator/JenaProposal Strong +1 in principle. I'd offer to mentor, but I see you now have plenty. One niggle: have you clarified somewhere that all the dependencies licenses are Apache-compatible? The openjena.org page referenced relies on references that are broken links! Grr ... rotting links ... Where? I'll fix them ASAP. Checking: http://openjena.org/Licenses/index.html I found the links for JUnit and WoodSToX have rotted. Anything else gone bad? Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Accept Jena into the Incubator
On 13/11/10 02:23, Jeremy Carroll wrote: On 11/12/2010 6:05 PM, Benson Margulies wrote: CyberNeko and TagSoup both have acceptable licenses. Some people prefer TagSoup because it does not require Xerces. Have you read http://www.apache.org/legal/resolved.html? No I hadn't. That is very useful. A first reaction, concerning the GRDDL dependencies, is: 1) BrowserLauncher needs to go - I will make the code changes 2) Saxon dependency is a B 3) Cyberneko is fine - Jena already has dependencies on Xerces Cyberneko 1.9 is Apache License v2 (from the project page on SF). GRDDL depends on an older v0.9 which has it's own license, if I understand correctly. Jeremy - you understand the issues and code here. Is the text added to the proposal OK and can we assume you will either resolve the legal issue or modify the codebase of the GRDDL reader to amke it a non-issue. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Accept Jena into the Incubator
On 13/11/10 13:32, Ross Gardler wrote: All, Resolving IP issues are a part of the incubation process not the acceptance process It is not necessary to delay entry into the incubator because some o these issues need to be satisfactorily resolved. The Jena developers are aware of this and have undertaken to do what is required in meetings with myself as Champion. Can one of the Jena team please add a note to this effect in the proposal in order to remove any doubt about this. Done. The text added says: [[ The initial committers overtake to resolve all IP and copyright issues that concern the dependencies of the initial source and of any contributions in accordance with Apache requirements for graduating from incubator status. All contributions to the Jena codebase are under BSD-style license. The majority of copyright is held by HP. Some copyright is held by others, as noted in the codebase. This includes contributions from the initial committers below and any other contributions. ]] At this point, any of the Jena initial committers can revise that text otherwise lazy consensus applies. I'd like to call a vote on Jenas entry but am unable to do so until this discussion is resolved. I am going to assume the addition of a commitment to resolve these issues are sufficient to move forwards (lazy consensus). Ross Andy PS We recently removed a dependency on json.org code. I know Apache allows it but some organisations found that license difficult to work with. - 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 Thu, Nov 25, 2010 at 10:48 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Nov 25, 2010 at 1:14 AM, Jeremy Carrolljer...@topquadrant.com wrote: On 11/24/2010 3:58 PM, Emmanuel Lecharny wrote: But this is like if you are working in an office in front of a collegue : most of the time, you don't chit-chat, you work. And when it comes to make a decision impacting the whole project, then the discussion is moved to the ML. In the Jena team, several committers work in one office, I am one of the ones who doesn't - moreover, I am an 8hr time shift away. The real-time comms of the office chit-chat is simply a fact of life. I guess clarity about what the risks are and how we should address them would be useful... I think it just comes down to everything must happen on the dev list and make sure your project is open new people and outsiders. As long as anything that has a significant impact on the project is discussed/decided on the dev list, and people who cannot attend the out-of-list discussions do not feel left out, I think you'll be fine. -Bertrand All project decisions I can recall for Jena have been whole-group. The Jena committers are heavy email users and while once-upon-a-long-time ago we did sometimes have F2F meetings (when we were all in the same timezone, indeed same UK building) email was and is the major means of communication. As we are now a distributed team, email has been the means of communication. The one phone meeting we've had was arranged (by email) precisely to include everyone possible especially Jeremy. In the past, I can remember stepping away from my desk for a few minutes for coffee to come back to 10's of messages (bounced of a US server of course) of Jena discussions between people a few feet apart. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shepherd assignments July 2013
On 17/07/13 06:49, Ross Gardler wrote: Ross Gardler Marmotta Looks good. Releases made, Committers brought in. Mentors appear to be watching. Recommend mentors consider graduation sooner rather than later. The mentors have. The podling is reluctant to leave the nest :-) (This mentor is now in standby mode) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Marmotta as TLP
+1 On 04/11/13 08:59, Jakob Frank wrote: Hi all, the Marmotta podling, whose goal is to provide an Open Platform for Linked Data, entered incubation in December 2012. Since then, the codebase has stabilized and two releases were published following ASF policies and guidelines. The community has grown, two new committers have joined the development team and more people joined the mailing lists. The last incubator report lists Marmotta as Ready to graduate [1], the Marmotta community has decided to take this step [2] and agreed on a Graduation Resolution Draft [3] which is also attached below. The resolution draft was posted to general@incubator.a.o for discussion [4] and raised no concerns, now please cast your votes: [ ] +1 Graduate the Marmotta podling from Incubator [ ] +0 Indifferent to graduation status of the Marmotta podling [ ] -1 Reject graduation of the Marmotta podling from Incubator because... The vote will be open for at least 72 hours starting now. Best, Jakob on behalf of the Marmotta community [1] http://s.apache.org/marmotta-graduation-vote [2] http://s.apache.org/marmotta-graduation-result [3] http://s.apache.org/marmotta-graduation-resolution [4] http://s.apache.org/dYt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On 10/11/13 09:04, ant elder wrote: How about simply changing the rules for Incubator releases so that they don't require at least three binding votes, but instead make it at least three votes only one of which must be binding. That would mean there would still be the element of oversight that a mentor vote gives but avoids all the problems with not having three mentors. I'm sure the board would grant the Incubator authority to implement that change. ...ant Having some mechanism to give real, effective value to the PPMC votes seems like an excellent idea. Whether it is this exact proposal or something else, I don't know. At the moment, the PPMC votes are not essential which I find a bit odd. Maybe make some/all the mentor votes being votes on the process of the release (IP checking included), not the content. (Or maybe different mentor vote classes is just complexity.) Doing IP the first time seems to come a surprise for podlings (in my very limited experience). But once one or two people on the PPMC get it, it's time to handover that responsibility to the PPMC. Andy On Sun, Nov 10, 2013 at 8:00 AM, Alex Harui aha...@adobe.com wrote: IMO, there are two problems: 1) We're trying to train folks to manage IP for their community but they have to seek approval from folks are aren't as vested in their community. My analogy is telling a new city council member: Welcome to the city council. For the next year all of your decisions will require ratification by 3 state senators. 2) Release voting takes a long time. It would seem like tools should be able to reduce the time on several of the steps, except for this one from [1] compile it as provided, and test the resulting executable on their own platform. Sometimes I think about trying to get on the IPMC and helping some podling get a release out but: A) Really, I just want to help check the legal aspects of a podling's release and don't have bandwidth to want to take on the other roles implied by being on the IPMC. B) I don't want to take the time to figure out how to build and test a release that I have no vested interest in. Now, incubating releases are not official releases, right? So why have such time- consuming requirements to get approval from the IPMC? Let's assume that the podling folks tested the building and operation of the source package. Could we build an ant script that any IPMC member or any PMC member from any TLP (to expand the pool of potential helpers to folks who supposedly know how) can run just to check: 1) source package has the name incubating 2) source package is signed 3) unzip source package 4) grab a tag from SVN/Git 5) Diff 6) Run Rat (without any fileset exclusions) Then some podling writes to general@ and says: can we get legal approval to release? Please run the release checker ant script with the following inputs url to package url to SVN/Git tag Then it could run while I read through all of the other ASF emails and eventually I get a report that contains mainly a list of non-Apache files in the RAT report that I review and comment on if needed. To me, if you're reviewing a RAT report, you are a building inspector who has looked around inside. Can we make it that simple? For sure, if any podling member is qualified for IPMC before graduation they should be nominated and added, and I suppose we could also approve them to cast binding votes as a release checker which may be a lower bar and maybe less of a time commitment, but I think if it is possible to have a larger group of folks approve incubating releases mainly be reviewing RAT reports that might make it easier for a podling to get a release out the door and still assist in the training of the podling's future PMC members. [1] http://www.apache.org/dev/release.html#approving-a-release My two cents (probably more), -Alex On 11/9/13 9:38 PM, Marvin Humphrey mar...@rectangular.com wrote: On Sat, Nov 9, 2013 at 4:11 AM, Dave Brondsema d...@brondsema.net wrote: On 11/09/2013 02:23 AM, Jake Farrell wrote: If mentors are not performing their duties to vote on a given releases for a podling, then it is up to the IPMC as a whole to help that podling by doing the do diligence and casting a vote. We all asked to be apart of the IPMC or where honored by a nomination and accepted the role. It is up to us to show these podlings what the Apache was really means. These projects have all come to the ASF and we (the IPMC) have openly voted them into incubation, its up to us to help them succeed. While this is true in theory it's hard in practice to wrangle those votes together. That's not the only problem. While IPMC volunteers who perform freelance release reviews keep the Incubator from grinding to a halt, our reliance on them undermines the Incubator's effectiveness as an IP clearinghouse. I wish that we would redirect those volunteer energies elsewhere. IPMC members who vote +1 on an initial incubating release are
Re: Cultivating Outstanding IP Stewards
On 17/11/13 11:17, Upayavira wrote: On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote: On 11/16/13 8:47 AM, Upayavira u...@odoko.co.uk wrote: Alex, I'm not sure I see the difference between a release auditor and an IPMC member. If someone is sufficiently clued up to audit a release, then they're surely ready to join the Incubator PMC. Am I missing something? To me, there is more responsibility in being on the IPMC, like reviewing proposals for new podlings and voting on their graduation and becoming a mentor. Personally, that's why I don't want to be on the IPMC, but I might be willing to help IP audit a podling's release. Just like some projects don't have all committers on the PMC, a Release Auditor is just someone who can do that specific task, and there is no need to vote them in if they are already on some other TLP PMC because any member of a TLP PMC supposedly knows how to do release auditing. My interest is in a lesser level of involvement, where someone has shown merit within their own PPMC and can get a binding vote there, but no-where else. That feels to me like a very useful intermediate step to have. I agree, except for the no-where else part. If you know how to check a RAT report and have an idea of what should be in the NOTICE files, you should be able to help out any other podling by reviewing their release and casting a binding vote so they can learn how to do that. I'd say that 3 IPMC members must vote to give a person Release Auditor status if they are not already on a TLP PMC. Consider this: I am an the Flex PMC but not the IPMC, but if I join the PPMC of some new podling, why shouldn't I be able to cast a binding vote for that podling's releases? With a two tier model - with PPMC membership granting voting rights on podling releases, then a podling would start with just mentors on its PPMC. If you clearly knew what you were doing, you'd get voted onto the PPMC pretty quickly, and thus you'd be able to vote on your releases. I am concerned that it would be dis-empowering to the incoming community if at least the active and major developers of the podling were not on the PPMC at the start. Andy Upayavira - 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] Enable Release Checklist Experiment
+1 On 14/12/13 14:42, Dave wrote: +1 On Sat, Dec 14, 2013 at 9:11 AM, Joseph Schaefer joe_schae...@yahoo.comwrote: +1 On Dec 13, 2013, at 11:31 PM, Henry Saputra henry.sapu...@gmail.com wrote: So it begins =) +1 Thanks for leading the effort, Marvin - Henry On Fri, Dec 13, 2013 at 12:59 PM, Marvin Humphrey mar...@rectangular.com wrote: Greetings, As the next step in our ongoing efforts to reform the release voting process, I propose that we run an experiment allowing the PPMC members of select podlings to earn binding votes under limited circumstances by completing a release checklist. For participating podlings, the Incubator's release management guide... http://incubator.apache.org/guides/releasemanagement.html ... would be supplanted by the following documents: http://incubator.apache.org/guides/release_manifest.txt http://incubator.apache.org/guides/release.html The scope of this VOTE is limited to approving the following patch to our policy page: https://paste.apache.org/k4vJ Here is the patch content minus markup: 2013 Alternate Release Voting Process Select podlings pre-cleared by a majority vote of the IPMC MAY participate in an alternate release voting process: Should a Podling decide it wishes to perform a release, the Podling SHALL hold a vote on the Podling's dev list and create a permanently archived Release Manifest as described in the Experimental Release Guide. At least three +1 votes from PPMC members are required (see the Apache Voting Process page). If the majority of PPMC 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. Formal approval requires three binding +1 votes and more positive than negative votes. Votes cast by members of the Incubator PMC are always binding. For all releases after the first, votes cast by members of the PPMC are binding if a Mentor approves the Release Manifest. Please note that the proposed change is both incremental and reversible: * It is incremental because podlings must be opted in by vote of the IPMC to participate. * It is reversible because once the experiment has run its course the policy change can be reverted with zero impact through lazy consensus. Those who may have questions about the legitimacy of allowing binding votes from non-IPMC members should see this post from Roy Fielding: http://s.apache.org/v7 Please vote: [ ] +1 Yes, apply the patch enabling the experiment. [ ] -1 No, do not apply the patch enabling the experiment. This majority VOTE will run for 7 days and will close at 13:00 PST on Friday, December 20, 2013. Votes cast by members of the Incubator PMC are binding. Here is my own +1. Marvin Humphrey - 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: Hoya Proposal
On 13/01/14 20:25, Bertrand Delacretaz 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. The j-e-n in Jena is like Jen-kins or Gen-er-al. It is derived from Jennifer http://en.wikipedia.org/wiki/Jennifer_%28given_name%29 which is often, but not here, with nn: http://en.wikipedia.org/wiki/Jenna Andy -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Hoya Proposal
As a project name Jena has been in use for the project for about 13 years now. 1.0 was 9 Jan 2001. A mere 983K (zipped). The discussion is about Hyena for Hoya. Andy On 13/01/14 23:38, sebb wrote: Jenny ? On 13 January 2014 22:21, Ted Dunning ted.dunn...@gmail.com wrote: Too many people will read that as Jena, the city in Thuringia. https://en.wikipedia.org/wiki/Jena -1 On Mon, Jan 13, 2014 at 1:57 PM, Andy Seaborne a...@apache.org wrote: On 13/01/14 20:25, Bertrand Delacretaz 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. The j-e-n in Jena is like Jen-kins or Gen-er-al. It is derived from Jennifer http://en.wikipedia.org/wiki/Jennifer_%28given_name%29 which is often, but not here, with nn: http://en.wikipedia.org/wiki/Jenna Andy -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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Is a Software Grant Agreement always needed for IP Clearance?
On 05/04/14 16:19, Craig L Russell wrote: Hi Rob, If you developed the code during the time the ICLA and CCLA were in effect (from February 2012) I don't see a need to file additional paperwork. Craig As a matter of good practice, when is it best to use the IP Clearance process? In this case, we have a significant area of new functionality, written by Rob, who has appropriate xCLAs on file. It is within the projects charter. The code was written solely by Rob and developed outside the project's code repository. The IP Clearance Template (point 3) says an SG and CCLA must be in place and it is sent to the secretary. It does not seem necessary as the existing CCLA is on file. As a significant new piece of code, it does seem worth recording the acceptance by the project. What's the best practice? Andy On Apr 5, 2014, at 8:08 AM, Rob Vesse wrote: Hi All I’m in the process of carrying out IP Clearance for some code developed outside of the ASF that my employer (Cray) has now agreed to contribute to the Apache Jena project where I am a committer and PMC member. In this case the software was developed entirely by myself though obviously Cray holds the copyright. I have an ICLA on file for myself and Cray filed a CCLA for me when I originally joined the Apache Jena project as a committer and PMC member. In this scenario is a SGA actually needed to carry out IP Clearance of the contributed code or are the existing ICLA and CCLA sufficient? Thanks, Rob Vesse Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.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: [PROPOSAL] 3 month deadline on CLA item
On 02/08/11 11:24, Stefan Bodewig wrote: On 2011-08-02, Henri Yandell wrote: As can be seen elsewhere, I'm on a self-given mission to clean up the history of podlings by getting them to sign off on the following checklist item: Check and make sure that the papers that transfer rights to the ASF been received. It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. I view this as the first item that a podling should be dealing with, along with setting up the committers and getting that first codebase in. By comparison, a website is a nice to have and community is just icing. Dealing with, completing is a different issue. Proposal time. In parallel to cleaning up history, I'd like to stop the rot going forward. I'd like to propose that each new podling has 3 months (or another calendar length if that feels too short/too long) to get the checklist item signed off. I'm partial to 3 months as we would make them report monthly until they have the item signed off, perhaps with 6 months as a 'do we retire the podling?' checkpoint. +1 in general but three month may be too short, I'm leaning to the report monthly until done with a checkpoint - and six month feels good to me. Currently I'm mentor of a podling where one of the original contributors who enthusiastically supported the move to the ASF has gone MIA for several month now without any sort of CLA or grant in sight. In such a situation you hope your reminder mails have been lost, there is some sort of vacation and things will work out. You wait until you realize it is time to act because nothing is going to happen. In such a case three month get eaten up quickly. Stefan My experience with the Jena podling is that getting a Software Grant can take a seemingly long time. It's not a priority item for anyone in the the granting organisation so everything just goes slow. It took us about 8 months to do the process and that was a starting point of already had discussions that, in principle, the organisation would make the grant. Keeping it at the top of the podling todo list is good - our mentors were good at doing that. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Any23 to join the incubator
On 04/09/11 11:02, Michele Mostarda wrote: Hi Nick, On 4 September 2011 10:32, Nick Kewn...@apache.org wrote: On 3 Sep 2011, at 16:01, Davide Palmisano wrote: http://wiki.apache.org/incubator/Any23Proposal Hmmm. Could've done with something like that a decade or so ago. It's been a while since I worked with the semweb, but I might take an interest. We hope so! How would Any23 relate to well-known semweb libraries such as Redland family? Currently we use Sesame [1], which is an RDF library really similar to Jena. which is: http://incubator.apache.org/jena/ There's a nice collection of semantic web related projects now in incubator. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Add Any23 to the Apache Incubator
Accept Any23 into the Apache Incubator +1 (non-binding) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release jena-2.7.0-incubating (RC1)
Please vote on releasing the following as Apache Jena version 2.7.0-incubating This will be the first incubator release for Jena at Apache. == Overview Jena is a Java framework for building Semantic Web applications. Jena provides a collection of tools and Java libraries to help to develop semantic web and linked-data apps, tools and servers. Jena is composed of a number of modules. Historically, they have been released semi-independently, sort of flying in formation. We intend to switch to a more integrated build process and we want to create the time to do that by making this first Apache release now. For this first release, we need to release several modules at once as none have been released at Apache before. Our apologies for the extra checking work this results in. It also makes building everything from scratch involve more steps than an integrated build would do. Jena is delivered as maven artifacts for the jar for each module. It is also delivered as zip file containing all the jars and their dependencies so users have a download and unpack option. The version number of the release aligns with the main artifact and the packaged download. Different modules have different version numbers. Detailed version numbers: jena-top 0-incubatingParent POM jena-iri 0.9.0-incubatingIRI parsing library jena-core 2.7.0-incubatingMain Jena APIs for RDF and OWL. jena-arq 2.9.0-incubatingSPARQL query engine. apache-jena 2.7.0-incubatingDownload, with all dependencies. == Project vote Apache archives: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201112.mbox/%3C4EEDE5F6.1070409%40apache.org%3E Markmail: http://markmail.org/message/dob5hsk46ldqkqt4 == Maven staging repository https://repository.apache.org/content/repositories/orgapachejena-334/ == Proposed dist/ area: http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/ == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS == SVN tags Each module is currently tagged with the version and -RC-1 to denote the first release candidate for this release cycle. If voted on successfully, the tag will be changed (svn mv) to the same but minus the -RC-1. https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/tags/jena-top-0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/IRI/tags/jena-iri-0.9.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/jena/tags/jena-core-2.7.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/tags/apache-jena-2.7.0-incubating-RC-1/ == Website Including details of this proposed release: http://jena.staging.apache.org/jena/ Please vote on this release: [ ] +1 Approve the release of Apache Jena 2.7.0-incubating [ ] -1 Don't release, because ... This vote will be open until: Thursday 22/December 23:59 UTC (72 hours from the same hour tonight). As well as the vote, we'd also appreciate any feedback for improving our release process and project generally. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release jena-2.7.0-incubating (RC1)
Please vote on releasing the following as Apache Jena version 2.7.0-incubating This will be the first incubator release for Jena at Apache. == Overview Jena is a Java framework for building Semantic Web applications. Jena provides a collection of tools and Java libraries to help to develop semantic web and linked-data apps, tools and servers. Jena is composed of a number of modules. Historically, they have been released semi-independently, sort of flying in formation, not as a single unit. We intend to switch to a more integrated build process and we want to create the time to do that by making this first Apache release with a hybrid of the way we used to do it and a more integrated build. For this first release, we need to release several modules at once as none have been released at Apache before. Our apologies for the extra checking work this results in. It also makes building everything from scratch involve more steps than an integrated build would do. Jena is delivered as maven artifacts for the jar for each module. It is also delivered as zip file containing all the jars and their dependencies so users have a download and unpack option. The version number of the release aligns with the main artifact and the packaged download. Different modules have different version numbers. Detailed version numbers: jena-top 0-incubatingParent POM jena-iri 0.9.0-incubatingIRI parsing library jena-core 2.7.0-incubatingMain Jena APIs for RDF and OWL. jena-arq 2.9.0-incubatingSPARQL query engine. apache-jena 2.7.0-incubatingDownload, with all dependencies. == Project vote Apache archives: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201112.mbox/%3C4EEDE5F6.1070409%40apache.org%3E Markmail: http://markmail.org/message/dob5hsk46ldqkqt4 == Maven staging repository https://repository.apache.org/content/repositories/orgapachejena-334/ == Proposed dist/ area: http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/ == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS == SVN tags Each module is currently tagged with the version and -RC-1 to denote the first release candidate for this release cycle. If voted on successfully, the tag will be changed (svn mv) to the same but minus the -RC-1. https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/tags/jena-top-0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/IRI/tags/jena-iri-0.9.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/jena/tags/jena-core-2.7.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/tags/apache-jena-2.7.0-incubating-RC-1/ == Website Including details of this proposed release: http://jena.staging.apache.org/jena/ Please vote on this release: [ ] +1 Approve the release of Apache Jena 2.7.0-incubating [ ] -1 Don't release, because ... This vote will be open until: Wednesday 21/December 23:59 UTC (72 hours from the same hour tonight). As well as the vote, we'd also appreciate any feedback for improving our release process and project generally. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Questions for projects
On 30/01/12 17:32, Jukka Zitting wrote: Jena When can I vote on your graduation? Jena's report is already signed off on the wiki: [*] http://wiki.apache.org/incubator/February2012 The project is discussing graduation. Plan: * Graduation preparation (checking, drafting the scope/charter, resolution, chair, more checking) * There are no technical or infrastructure items blocking graduation. Andy [*] hey - we're early for once - long may it last! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release jena-tdb-0.9.0-incubating (RC2)
The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. == Overview This will be the second incubator release for by Jena; it's the first Apache release for the TDB module. Jena is composed of a number of modules. Historically, they have been released semi-independently, sort of flying in formation. We intend to switch to a more integrated build process and we want to create the time to do that by making this first Apache release of TDB now. Jena TDB is currently delivered as maven artifacts for the jar and also a single distribution file as a zip or tar.gz containing all the jars and their dependencies so users have a download and unpack option. == Project vote Result: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F324DFA.2050800%40apache.org%3E Call for VOTE: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F2DA188.6080105%40apache.org%3E == Staging repository https://repository.apache.org/content/repositories/orgapachejena-192/ Direct link to TDB area in staging: http://s.apache.org/apache-jena-tdb-0.9.0-incubating-RC-2/ == Proposed dist/ area: The following will be added to the existing distribution area: http://people.apache.org/~andy/dist-tdb-0.9.0-RC2/ will be added to: http://www.apache.org/dist/incubator/jena/ == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS == SVN tag The module is currently tagged with the version and -RC-2. If voted on successfully, the tag will be changed (svn mv) to the same but minus the RC labelling. https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-2/ Please vote on this release: [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating [ ] -1 Don't release, because ... This vote will be open until: Saturday 11/February 23:59 UTC (72 hours from the same hour tonight). As well as the vote, we'd also appreciate any feedback for improving our release process and project generally. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)
Hi there, We're short for votes for this release. Is there anything the podling can do, such as co-ordinate different checking undertaken, to help IPMC to vote on this release? Andy On 08/02/12 13:03, Andy Seaborne wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. == Overview This will be the second incubator release for by Jena; it's the first Apache release for the TDB module. Jena is composed of a number of modules. Historically, they have been released semi-independently, sort of flying in formation. We intend to switch to a more integrated build process and we want to create the time to do that by making this first Apache release of TDB now. Jena TDB is currently delivered as maven artifacts for the jar and also a single distribution file as a zip or tar.gz containing all the jars and their dependencies so users have a download and unpack option. == Project vote Result: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F324DFA.2050800%40apache.org%3E Call for VOTE: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F2DA188.6080105%40apache.org%3E == Staging repository https://repository.apache.org/content/repositories/orgapachejena-192/ Direct link to TDB area in staging: http://s.apache.org/apache-jena-tdb-0.9.0-incubating-RC-2/ == Proposed dist/ area: The following will be added to the existing distribution area: http://people.apache.org/~andy/dist-tdb-0.9.0-RC2/ will be added to: http://www.apache.org/dist/incubator/jena/ == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS == SVN tag The module is currently tagged with the version and -RC-2. If voted on successfully, the tag will be changed (svn mv) to the same but minus the RC labelling. https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-2/ Please vote on this release: [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating [ ] -1 Don't release, because ... This vote will be open until: Saturday 11/February 23:59 UTC (72 hours from the same hour tonight). As well as the vote, we'd also appreciate any feedback for improving our release process and project generally. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)
Hi sebb, Thanks very much for the time and feedback - we'll be back when we've fixed these problems. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. == Major changes since RC-2 + Distribution has it's own content for NOTICE/LICENSE files which rolls up information for the redistributed binaries. + jar file META-INF/NOTICE says Apache Jena - module TDB at the top. + source-release.zip does not contain a trunk/ copy. + New dist/ layout The existing released files will need to moved to this layout. The KEYS file is copied into the proposed dist/ area for clarity. == Project vote Result: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4614CB.9010802%40apache.org%3E including 1 IPMC vote (Benson Margulies) Call for VOTE: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F40CE69.2080402%40apache.org%3E The following was noted in the jena-dev RC-4 vote: * The license information for Plugged-In software is in the distribution LICENSE file twice. == Staging repository https://repository.apache.org/content/repositories/orgapachejena-001/ Direct link to TDB area in staging: http://s.apache.org/vcp == Proposed dist/ area: The following will be added to the existing distribution area: http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/ will be added to: http://www.apache.org/dist/incubator/jena/ Note: we will reorganise the current dist/ area to fit into this style of layout. == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS == SVN tag The module is currently tagged with the version and -RC-4. If voted on successfully, the tag will be changed (svn mv) to the same but minus the RC labelling. https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/ Please vote on this release: [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating [ ] -1 Don't release, because ... This vote will be open until: Sunday 26/February 23:59 UTC (72 hours from the same hour tonight). Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)
On 12/02/12 12:22, sebb wrote: ... lots of useful comments ... Hi sebb, We have just posted a vote on an RC-4 - this reply is to some of the specific points you raised: Please vote on this release: [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating [ ] -1 Don't release, because ... The binary NL files need to be sorted out before release. The tag and the packaging also need to be sorted out before release. We believe these have been addressed. The dist area has been changed to [DIR] download/ [DIR] source-release/ The SVN tag has been redone without a recursive trunk. The distribution has it's own LICENSE and NOTICE files that roll up the binaries incorporate in the distribution. The jars need to contain valid NOTICE files; however the files start as follows: TDB Copyright 2012 The Apache Software Foundation Changed to Apache Jena - Module TDB The top-level dir contains binary zip and tar archives, but no source archive. The subdir jena-tdb-0.9.0-incubating/ contains what appears to the the source archive, but only as a zip. This is produced by mvn -Papache-release (unmodified) which produces just source-release.zip Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On 23/02/12 18:32, sebb wrote: Hi sebb, Thanks for the review, == Staging repository https://repository.apache.org/content/repositories/orgapachejena-001/ This contains zip and tar.gz binary and source archives, which should be deleted as they are not useful to Maven. There are two addition classifiers used: source-release and distribution. To take the file jena-tdb-0.9.0-incubating-source-release.zip specifically, this gets there because mvn release:perform -Papache-release puts it there. This seems to be the practice elsewhere as well: e.g. https://repository.apache.org/content/repositories/releases/org/apache/sling/org.apache.sling.engine/2.2.4/ For distribution: We distribute through maven but also many of our users are not experienced developers but students, including ones new to java. To make it as easy as possible for this category of user, we ship a distribution which is the collection of jars needed for use without a maven/ivy infrastructure. This is created in the maven target/ area - and it is then renamed into the dist/ area as apache-jena* by the distribution build script. Maven forces the name to be jena-tdb- on staging whatever assembly root name is given. I seem to have missed some document somewhere - what is the correct way to handle this? Pointer? == SVN tag The module is currently tagged with the version and -RC-4. If voted on successfully, the tag will be changed (svn mv) to the same but minus the RC labelling. https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/ There are a lot of source files without AL headers. These need to be fixed. Could you say which ones you mean? Following the recent discussion on this (LEGAL-124), I thought the conclusion was it wasn't necessary on short files with little or no creativity or value. The files in testing/ are short test files - we do put the ASF header on the manifests. e.g: https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/testing/Pattern/pattern-1.rq PREFIX : http://example/OTHER SELECT * { :NoSuchNode ?p ?z . ?x ?p ?z } I found A total of 118 files that do not contain th line Licensed to the Apache Software Foundation (ASF) under 67 under testing/ 25 are scripts 12 are NOTICE/LICENSE/DEPENDENCIES etc. and then there setting and eclipse files that you have commented on before. (aside: we tried autogenerating Eclipse files following previous comments but encountered problems with eclipse:eclipse which we are investigating) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
We distribute through maven but also many of our users are not experienced developers but students, including ones new to java. To make it as easy as possible for this category of user, we ship a distribution which is the collection of jars needed for use without a maven/ivy infrastructure. That's fine, so long as the NL files agree with the contents. They should do. This is created in the maven target/ area - and it is then renamed into the dist/ area as apache-jena* by the distribution build script. Maven forces the name to be jena-tdb- on staging whatever assembly root name is given. Again that's OK, but the layout of the dist area - and the naming convention - is very confusing. There is no direct correspondance between the binary and source archives. It should be immediately obvious how to find the source and corresponding binary, but that's not the case at present. The directory structures align: /download/jena-tdb-0.9.0-incubating /source-release/jena-tdb-0.9.0-incubating but since this isn't /binaries and /sources we'll build about RC - we'll be back in a week to 10 day I hope. The scripts can all have AL headers; there are some XML files as well that could have them. I will put either short or full AL headers on the scripts. find . -name \*xml | xargs grep -L Licensed to the Apache Software Foundation | xargs wc -l 39 ./testing/Deployment/pom.xml 8 ./src/main/java/com/hp/hpl/jena/tdb/tdb-properties.xml 8 ./src/main/resources/org/apache/jena/tdb/tdb-properties.xml 55 total and tdb-properies.xml has 2 Java properties. Andy There is one Java file that has no AL header. 12 are NOTICE/LICENSE/DEPENDENCIES etc. These are OK and then there setting and eclipse files that you have commented on before. (aside: we tried autogenerating Eclipse files following previous comments but encountered problems with eclipse:eclipse which we are investigating) No need to autogenerate; just don't store them with the default names or paths. Perhaps store them under a resources/eclipse directory. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
sebb, What I'm trying to get to at the moment is something that enables a release of TDB and we can apply to next module. jena is a number of modules, we have released 3 (5 actually - 2 are the parent POM and the distribution maker for the core) already; TDB is the sixth, and there are 3 more in the pipeline. People have been asking for more packaging forms - WAR file for the server functionality, OSGi for Jena as a whole, which seems to be a non-trivial exercise. One of the ones to come is not a simple jar build - it's a server that can used as a jar, as a combined dependencies jar or run from the command line. I'm trying to understand the constraints required so that will be smooth(er). We are discussing rebuilding our build strategy but doing so, and to get it working reliably and stably will take time. We chose to release with what we have, and not let reworking the build system become critical path for graduation. The apache-jena-tdb... is then merely being a renamed file for browsing apache-jena-tdb-0.9.0-incubating-distribution.zip (c.f. Ant which has renamed items in it dist/ant) I referred to Ant specifically because the incubator documentation for podling releases picks ant and httpd out as examples to look at. ant has top level items for easy discovery which are renamed duplicates of things in binaries/ `-- source-release `-- jena-tdb-0.9.0-incubating What's the point of the subdirectory? because there are other modules with their own source-release artifact. The TDB release items will be merged into the existing directory. We had been following a layout like CXF where source-release and binaries are in the same directory. Given that is where a the maven-driven process puts them, someone taking the source releease doing mvn package is going to look in target/ and expect created items to be there. That was the RC-2 proposal for dist for TDB. If, as seems necessary, we have to adopt a different layout, we'll reorganise the existing release items into the same structure. Would a structure: dist |-- binaries | `-- jena-tdb-0.9.0-incubating | |-- jena-tdb-0.9.0-incubating-distribution.tar.gz | |-- jena-tdb-0.9.0-incubating-distribution.zip | |-- jena-tdb-0.9.0-incubating-javadoc.jar | |-- jena-tdb-0.9.0-incubating-sources.jar | |-- jena-tdb-0.9.0-incubating.jar The jars are not generally needed for dist/ |-- download | |-- apache-jena-tdb-0.9.0-incubating-distribution.tar.gz | |-- apache-jena-tdb-0.9.0-incubating-distribution.zip Are these the same as the distribution archives above? `-- source-release `-- jena-tdb-0.9.0-incubating What's the point of the subdirectory? |-- jena-tdb-0.9.0-incubating-source-release.zip Name does not agree with binary archives + the .asc, .md5 .sha1 files be acceptable? Or with download/ removed its files at the top level? I still find it very confusing. e.g. where is the source file for jena-tdb-0.9.0-incubating-distribution.tar.gz? jena-tdb-0.9.0-incubating-source-release.zip Given the way maven classifiers work, it is a reasonable expectation of the user to find the various classifier artifacts in target/ after mvn package Why is there a download directory and a binaries directory? Like ant, I pulled out the items which are download-unpack-go. The dist areas serves several audiences - for (new) users, not necessarily experienced maven users, we have the Jena website (we use Apache CMS to produce the website, not maven by the way) simply point to download/ (mirrored). Ditto URLs handled out on the web as being the place to go to download Jena. I don't mind if it's download/ or (like ant) at the top level. Andy Mocked up at: http://people.apache.org/~andy/dist-tdb-proto/ See my mockups at: http://people.apache.org/~sebb/dist-tdb-proto/ one - parallel binaries/ and source/ two - single directory named after the release. The latter is likely to be easier to manage when moving to svnpubsub. $ ls -1R ./one: KEYS binaries source ./one/binaries: apache-jena-tdb-0.9.0-incubating-distribution.tar.gz apache-jena-tdb-0.9.0-incubating-distribution.zip ./one/source: apache-jena-tdb-0.9.0-incubating-source-release.zip ./two: KEYS apache-jena-tdb-0.9.0-incubating ./two/apache-jena-tdb-0.9.0-incubating: apache-jena-tdb-0.9.0-incubating-distribution.tar.gz apache-jena-tdb-0.9.0-incubating-distribution.zip apache-jena-tdb-0.9.0-incubating-source-release.zip - 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 jena-tdb-0.9.0-incubating (RC-4)
`-- source-release `-- jena-tdb-0.9.0-incubating What's the point of the subdirectory? because there are other modules with their own source-release artifact. The TDB release items will be merged into the existing directory. So why don't you do the same for the download directory? The download/ directory would be for all modules. But as I said, top level work for me as well. One place where you can get all the jena-related unpack-and-go files. Is that not possible? We had been following a layout like CXF where source-release and binaries are in the same directory. I still find it very confusing. e.g. where is the source file for jena-tdb-0.9.0-incubating-distribution.tar.gz? Sorry, that was a mistake - I meant where is the source for the dowload file apache-jena-tdb-0.9.0-incubating-distribution.tar.gz As per ant example - there is a correctly named and positioned file and also a copy (and rename) elsewhere. The specific rename is because, long term, post rework the build, we think apache-jena-... will be the packaged up forms and jena-... the core jars but that isn't really the issue here. A systematically named file is available. What I care about is that it is: - more difficult to find the source than some of the binaries, because of the extra directory level. Maybe I don't understand how should we manage multiple modules with currently have independent version numbers. The proposal is have: /sources/jena-arq-2.9.0-incubating/ /sources/jena-core-2.7.0-incubating/ /sources/jena-iri-0.9.0-incubating/ /sources/jena-tdb-0.9.0-incubating/ /binaries/jena-arq-2.9.0-incubating/ /binaries/jena-core-2.7.0-incubating/ /binaries/jena-iri-0.9.0-incubating/ /binaries/jena-tdb-0.9.0-incubating/ Is this better? /jena-arq-2.9.0-incubating/sources/ /jena-arq-2.9.0-incubating/binaries/ /jena-core-2.7.0-incubating/sources/ /jena-core-2.7.0-incubating/binaries/ /jena-iri-0.9.0-incubating/sources/ /jena-iri-0.9.0-incubating/binaries/ /jena-tdb-0.9.0-incubating/sources/ /jena-tdb-0.9.0-incubating/binaries/ Can we put easy to find files in /? - not at all clear how to find the source for some of the binaries, as it is at a different level and with a different name. /sources/jena-tdb-0.9.0-incubating/jena-tdb-VER(-classifier)? /binaries/jena-tdb-0.9.0-incubating/jena-tdb-VER-source-release are at the same level. We did have a form like sling uses, split per module. - binaries are available as tar.gz and zip, but source only as zip Sorry - I thought I'd answered this earlier. We use org.apache:apache which comes down to this (in assemblies/source-release.xml) which just makes a zip. assembly idsource-release/id formats formatzip/format /formats componentDescriptors componentDescriptorassemblies/source-shared.xml/componentDescriptor /componentDescriptors /assembly so we just followed that. It's a tradeoff - reuse unchnaged vs forking it. For the .jar.gz: we used to ship a zip, which any Java systems must have access to as jar files are zip archives. Adding .tar.gz was courtesy for people wanting files in those forms because it very little work to help them. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [ATTN] Incubator releases distribution area reminder!
On 24/02/12 16:56, Daniel Shahaf wrote: Mark Struberg wrote on Fri, Feb 24, 2012 at 09:17:57 +: PS: txs to Daniel Shahaf for pointing me at the current docs I didn't :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org As I'm discovering, the incubator guides aren't completely clear :-) 1/ Incubator guide: [[ Distribution policy with regard to releases is simple: The Incubator insists that artifacts for {podling} are contained within www.apache.org/dist/incubator/{podling}. ]] which does not mention the maven repository at all, and says that artifacts go in the dist/incubator/ area. Two meanings of artifact - maven artifact and Apache product. 2/ If the intention is to strongly suggest specific layouts then the text: [[ Best Practice Layout A podling is free to choose a suitable layout for its released artifacts within the podling distribution directory. It is recommended that standard layouts (commonly used by other projects) be studied ]] could be revised to include the constraints 3/ [[ Often symbolic links are created from the root of the project distribution directory to the latest version of each release. This allows scripts or users to easily locate the latest release. ]] is at odds with http://www.apache.org/dev/mirror-step-by-step.html [[ 9. Do not use symbolic links in mirrored directories! ]] although that does say Note: This file contains out-of-date information. Sorry - I do read the documentation sometimes ;-) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] [ended] Release jena-tdb-0.9.0-incubating (RC-4)
Currently, this vote has 2 +1 and some comments. This release vote isn't going to get the necessary 3 +1's so is being closed. We'll be back with another RC. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. -- Main changes from RC-4: + Added license to scripts, and XML files. small test files don't have a license; test manifests do. + New layout of dist/ http://markmail.org/message/oh5stsl2ikbslobs -- PPMC vote: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4E9B97.7060901%40apache.org%3E We have one IPMC +1 from this thread. Staging repository: https://repository.apache.org/content/repositories/orgapachejena-001/ Proposed dist/ area: http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-5/ This will be added to the existing released modules. Keys: http://www.apache.org/dist/incubator/jena/KEYS SVN tag: https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-5/ The module is tagged with the version and RC-5 to indicate the release candidate in this release cycle. If voted on successfully, the tag will be changed (svn mv) to the same name but minus the RC designation. Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't release, because ... This vote will be open until: Wednesday 7/March 23:59 UTC (3 whole days: 72 hours from the same hour tonight). Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
On 08/03/12 09:14, Paolo Castagna wrote: Thank you ant. We still need 2 more votes, right? We need one more IPMC vote. We have Benson on the project vote thread on jena-dev@i and ant from general@i. Please - one more IPMC +1! Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] [Result] Release jena-tdb-0.9.0-incubating (RC-5)
On 04/03/12 22:19, Andy Seaborne wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. -- ... Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Don't release, because ... This vote will be open until: Wednesday 7/March 23:59 UTC (3 whole days: 72 hours from the same hour tonight). Result of the vote for release of Jena TDB 0.9.0 (RC-5) on jena-dev: The vote passes. +1 votes: 3 IPMC votes: Benson Margulies ant elder Leo Simons 0 votes: none -1 votes: none Call for the VOTE email and thread: Vote started 2012-03-04: http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C4F53EA65.4030604%40apache.org%3E Thanks everyone, Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release Jena Fuseki 0.2.1-incubating
Hi, Here is a vote on a release for Jena Fuseki module, 0.2.1-incubating. This RC-2 of this release. Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open until: Wednesday 21/March 23:59 UTC (3 whole days: 72 hours from the same hour tonight). jena-dev thread: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201203.mbox/%3C4F63A159.7010506%40apache.org%3E Staging repository: https://repository.apache.org/content/repositories/orgapachejena-081/ Proposed files and structure to merge with existing Jena dist/ area: http://people.apache.org/~andy/merge-jena-fuseki-0.2.1-RC-2/ Keys: http://www.apache.org/dist/incubator/jena/KEYS SVN tag: https://svn.apache.org/repos/asf/incubator/jena/Jena2/Fuseki/tags/jena-fuseki-0.2.1-incubating/ Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
This is a call for vote to graduate the Apache Jena podling from Apache Incubator to be a top level project. Jena entered incubation in November 2010. The project has added two new committers and PPMC members, made several releases and has a diverse committer base. The user and development communities are active. The PPMC has indicated [1,2,3] that it believes the project is ready to graduate as a top-level project with the resolution draft below. We ask that the IPMC approve this graduation request though this VOTE. [1] Vote: http://s.apache.org/jena-graduation-vote [2] Result: http://s.apache.org/jena-graduation [3] Request for comments: http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C5C4A33CB-B122-43A8-B082-CBD63B526DE7%40cray.com%3E On behalf of the Apache Jena PPMC, Andy - [ ] +1 Recommend to the ASF Board that Apache Jena Proposal is ready to graduate to being a top level project. [ ] 0 [ ] -1 Do not graduate Apache Jena because ... The vote will be tallied no earlier than: Thursday April 5th, at 23:59 UTC. - X. Establish the Apache Jena Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to accessing, storing, querying, publishing and reasoning with semantic web data while adhering to relevant W3C and community standards. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Jena Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Jena Project be and hereby is responsible for the creation and maintenance of software related to accessing, storing, querying, publishing and reasoning with semantic web data while adhering to relevant W3C and community standards; and be it further RESOLVED, that the office of Vice President, Apache Jena be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Jena Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Jena Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Jena Project: * Andy Seaborne (andy) * Benson Marguilies (bimargulies) * Chris Dollin (chrisdollin) * Damian Steer (damian) * Dave Reynolds (der) * Ian Dickinson (ijd) * Paolo Castagna (castagna) * Rob Vesse (rvesse) * Stephen Allen (sallen) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andy Seaborne be appointed to the office of Vice President, Apache Jena, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Jena PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Jena Project; and be it further RESOLVED, that the Apache Jena Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Jena podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Jena podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] Graduate Apache Jena as a Top Level Project
Result for the graduation vote for Apache Jena on general@i.a.o: +1: Bertrand Delacretaz Benson Margulies Chris Mattmann Alan Cabrera Andreas Kuckartz (non-binding) Leo Simons Jukka Zitting Matthew Franklin 0: None -1: None so we're delighted to announce that the vote has succeeded. Thanks everyone! Andy on behalf of the Jena project [ ] +1 Recommend to the ASF Board that Apache Jena Proposal is ready to graduate to being a top level project. [ ] 0 [ ] -1 Do not graduate Apache Jena because ... The vote will be tallied no earlier than: Thursday April 5th, at 23:59 UTC. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Adding branding items to graduation requirements
P.S. Jena looks fairly good, although missing (TM) after the first use of name, and needs to tweak homepage text a little. I like their logo! Thanks for that - what are those tweaks (either email or JIRA) and we'll get them fixed. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: May reports due in ten days
On 22/04/12 12:55, Jukka Zitting wrote: Ready to graduate: Jena, Lucene.NET, NPanday, OpenNLP Jena graduation has been approved by the board. We need to do the graduation process now ... Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Graduation tasks : (was INFRA-4767)
Seeing INFRA-4767 ... Need to update the website 1) List of VPs Also, if a VP position changes, please update the web-site file at: http://www.apache.org/foundation/index.html using the CMS application, or update: https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/index.mdtext 2) Index of TLPs https://svn.apache.org/repos/asf/infrastructure/site/trunk/templates/blocks/projects.mdtext Is projects.mdtext something a graduating project needs to update? I'm happy to do it for Jena - it's not in http://i.a.o/guides/graduation.html#notes-on-hand-over so it hasn't been done so far. Anywhere else need doing? Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Graduation tasks : (was INFRA-4767)
sebb - thanks for the pointers. Andy On 09/05/12 01:33, sebb wrote: On 8 May 2012 23:22, Andy Seabornea...@apache.org wrote: Seeing INFRA-4767 ... Need to update the website 1) List of VPs Also, if a VP position changes, please update the web-site file at: http://www.apache.org/foundation/index.html using the CMS application, or update: https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/index.mdtext 2) Index of TLPs https://svn.apache.org/repos/asf/infrastructure/site/trunk/templates/blocks/projects.mdtext Is projects.mdtext something a graduating project needs to update? Yes, once the TLP.apache.org website is available. I'm happy to do it for Jena - it's not in http://i.a.o/guides/graduation.html#notes-on-hand-over so it hasn't been done so far. Anywhere else need doing? DOAP file needs creating and adding to the list [1] If you already have one it will need updating, and files.xml updated with the new location. The PMC chair should have sufficient karma to update that. [1] https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza status (Was: [Incubator Wiki] Update of August2012 by BertrandDelacretaz)
On 11/08/12 12:33, Reto Bachmann-Gmür wrote: On Thu, Aug 9, 2012 at 9:56 PM, Andy Seaborne a...@apache.org wrote: On 08/08/12 23:16, Jukka Zitting wrote: If the efforts to grow or reactivate the community fail, would it be a good idea to seek to join forces with some related projects like Stanbol, Any23 or UIMA? Or do you feel that there are still enough active people to allow the project to function as a standalone TLP (able to reach 3 PMC votes for releases, etc.)? Or Jena. I think from the scope of the application (platform for semantic web applications) clerezza is the closest to jena. However from the software architecture clerezza is signifantly closer to Stanbol. Main elements of clerezza are a very spec close layered RDF API and a platform based on OSGi, not sure how much the Jena community is interested in these. Ask them :-) If it helps, Jena can add OSGi-packaged components. I see various rdf.jena in the Stanbol parent. Maybe we should take this to (stanbol|clerezza)-dev for detailed discussion. Andy Reto - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Any23 from the Apache Incubator
On 16/08/12 14:41, Mattmann, Chris A (388J) wrote: Hi Folks, We have already called and completed a community VOTE with the Any23 community and the Tika PMC and they have positively recommended Any23's graduation from the Incubator. VOTE: http://s.apache.org/fU RESULT: http://s.apache.org/VAl I am now calling for a VOTE with the Incubator PMC to graduate Any23 from the Incubator. I'll leave the VOTE open for at least the next 72 hours. [ ] +1 Graduate Any23 from the Apache Incubator. [ ] +0 Don't care. [ ] -1 Don't graduate Any23 from the Apache Incubator because... The Any23 draft board resolution is pasted for your consideration below. Thank you! Cheers, Chris Mattmann Any23 Champion P.S. Here's my +1! +1 (binding) The community and project are in good shape. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [VOTE] Graduate Apache Any23 from the Apache Incubator
WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to the automatic crawling, parsing and analyzing of data to produce RDF. Chris wrote: How about: related to automatic crawling, parsing, analyzing, producing, and converting RDF data? Minor: [[ related to automatic crawling, parsing, analyzing, producing, and converting *of* RDF data ]] Sound better? sebb wrote: At first glance, with the previous version in mind, it seems better. But when re-read in isolation the phrase implies to me that only RDF data is involved. == Not sure how well known RDF is as a TLA. For avoidance of doubt, perhaps put: RDF (Resource Description Framework) data where necessary. +1 to RDF (Resource Description Framework) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Linda
On 17/11/12 09:01, Sergio Fernández wrote: Hi Roy, we were aware of the possible conflict/confusion with the name; but since the Linda model is quite old, not really spread nowadays and completely far away of the Linked Data topic, personally I can't see a really big issue here. But of course the Incubator PMC has a deeper knowledge of such a kind of decisions and its implications, so we'll do out best to address it during this discussion. Anyway, we'd prefer to focus the discussion on the proposal itself. After all, the name is something we can change. But the project is something important to discuss. BTW, regarding that, in other to provide some more background about the proposal, I'd also like to point you the slides we presented one week ago at ApacheCon Europe: http://slidesha.re/VUQ7ia Thanks for all your feedback. Best, On 16.11.2012 19:30, Roy T. Fielding wrote: I suggest choosing a different name. http://en.wikipedia.org/wiki/Linda_%28coordination_language%29 We generally don't use names that have been (and continue to be) used extensively by other software projects. Roy You're right changing the name can be done later but the name tends to get embedded both in the system (e.g. URLs, JIRA project) and more importantly in people knowing about the community. Renaming for the community is hard and risky - I would say it is easier to sort it out as part of project initialization if you believe the name change is likely. I did a quick search and found 2 lindas: Linda Spaces (the blackboard system that, I guess, is triggering the comments here) and TCP Linda, a parallel execution environment (which may well be related to the blackboard linda). TCP Linda == http://www.gaussian.com/g_prod/linda.htm Linda spaces leads to JavaSpaces so is a known name in the Java world at least. There is a SourceForge project linda (but looks dormant) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Marmotta
On 19/11/12 11:20, Sebastian Schaffert wrote: Hi all, we have had a brainstorming round and came up with the suggestion Apache Marmotta as a new name. We looked a bit and the name seems not to be taken yet, so there would probably no legal issues with the name. Why Marmotta? It is Italian for marmot, one of the predominant animals in the mountains around us. It also is very social (i.e. links) and digs deep tunnels (looks for data). It is more or less easy to pronounce (only contains a and o as vowels and no unpronouncible combinations). The animal itself has typically a very positive association (cute) and would also provide easy branding with images and logos. What do you think? The helpful documentation is at: http://incubator.apache.org/guides/names.html Greetings, Sebastian For Marmot (English spelling, added by Google as I am in the UK) found: http://www.lrz.de/services/software/parallel/marmot/ http://burlymarmot.com/ - a software company. which is a different spelling so helps differentiate. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Marmotta
On 20/11/12 10:05, Sergio Fernández wrote: Hi, we were internally discussing that the project would benefit a lot from having a mentor outside of the core Semantic Web community. Then he/she could help us to address those issues of which are not fully aware when you work so close in a topic. For instance, someone from the REST community would be great! Any volunteer(s)? Cheers, Two of the three mentors are new to mentoring and fairly new to Apache, each having done once round the incubator loop in a recent projects (Jena, Stanbol) as project members. We're feeling a bit light on Apache history and breadth. The project would benefit from a mentor with a longer Apache history - someone who can give a wider perspective about culture and community - who ensures we establish the wider ideals of the foundation into the Marmotta community. Volunteer? (Or a mentor-mentor?) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Marmotta
A quick update on the Marmotta proposal. Thanks everyone for the comments. The proposal should reflect the discussions. One of the mentors is not yet formally a member of IPMC so we're waiting until we have three formal mentors before calling the proposal vote. (and still, ideally, looking for an experienced mentor - I'm looking like the old timer on the projects mentor list!) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Accept Marmotta into the incubator
that the future development will occur on both salaried and volunteer time, particularly by participants from the Linked Data community. == Relationships with Other Apache Projects Although current RDF/SPARQL support in LMF is build on top of OpenRDF Sesame API, Marmotta is closely related to many Apache projects, such as Stanbol, Jena and Any23. See “Alignment” above. == An Excessive Fascination with the Apache Brand While we expect the Apache brand may help attract more contributors, our interests in starting this project is based on the factors mentioned in the Rationale section. == Documentation Documentation for the current project can be found at: http://lmf.googlecode.com http://doc.lmf.googlecode.com/hg/api/index.html http://doc.lmf.googlecode.com/hg/rest/index.html http://doc.lmf.googlecode.com/hg/client/index.html == Initial Source LMF (formerly KiWi) has been developed since 2008. It is important to say that the whole LMF will not be contributed to Marmotta, actually only those parts that make up the Linked Data Platform functionality (Linked Data Server, RDF Store, SPARQL, LDCache, Versioning, Reasoner and LDPath) . The idea is to focus Marmotta much more in the core needs, keeping all surrounding functionalities (Media-related modules and Semantic Search, basically) out of the initial scope. Although the community will be who ultimately decides what are the relevant modules. Since LMF is a very modular software artifact it will be pretty easy to make such partitioning to kick-off Marmotta. The current source code can be found at Google Code: http://lmf.googlecode.com == Source and Intellectual Property Submission Plan Salzburg Research Forschungsgesellschaft mbH is the sole copyright owner of the initial code to be contributed, so should not be any problem with the standard IP clearance process. Current licence is already Apache Software License 2.0. == External Dependencies Most of current dependencies should have Apache compatible licenses, including BSD, CDDL, CPL, MPL and MIT licensed dependencies. We are aware of some incompatible licenses right now, but we will work to solve this issue. See Appendix A for a detailed list of dependencies. == Cryptography Does Not Apply. == Required Resources Mailing lists marmotta-dev marmotta-commits marmotta-users Repository git://git.apache.org/marmotta.git Issue Tracking Jira: MARMOTTA (Kanban board enabled at GreenHopper) Other Resources Jenkins/Hudson for builds and test running. Wiki for internal documentation purposes Blog to improve the project dissemination == Initial Committers Sebastian Schaffert (sebastian dot schafftert at salzburgresearch dot at) Thomas Kurz (thomas dot kurz at salzburgresearch dot at) Jakob Frank (jakob dot frank at salzburgresearch dot at) Dietmar Glachs (dietmar dot glachs at salzburgresearch dot at) Sergio Fernández (sergio dot fernandez at salzburgresearch dot at) Rupert Westenthaler (rwesten at apache dot org) == Affiliations All initial committers are currently affiliated to Salzburg Research Forschungsgesellschaft mbH. == Sponsors = Champion Andy Seaborne (andy at apache dot org) = Nominated Mentors Fabian Christ (fchrist at apache dot org) Nandana Mihindukulasooriya (nandana at apache dot org) Andy Seaborne (andy at apache dot org) = Sponsoring Entity Apache Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Retirement decision making
On 29/11/12 14:53, Bertrand Delacretaz wrote: On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera l...@toolazydogs.com wrote: ... Would you also add the three or more active PMC members requirement? What constitutes active?... IMO the bare minimum is being able to find three PMC members to vote on things when needed. Once a project gets below this limit it's in trouble and usually headed for the attic, but that's not the only possibility - see Resolution to reboot the Apache Xalan PMC at http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt for example. I think we need to be a bit careful about graduating a podling that is a minimum viable project. That's not say it shouldn't be done but if it's minimal, and looks ropey, then we're aren't doing us or them any favours if the project looks likely to get into problems quite soon. After all, graduation itself requires project resource. Andy -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] Accept Marmotta into the incubator
Thank you to everyone who has taken part in the reviewing the proposal. The voting thread is from: http://s.apache.org/yj The vote results: There were 13 +1 votes, of which 10 were binding. No 0 or -1 votes. The vote passes. Andy Votes: (* = binding) Ross Gardler * Fabian Christ Andy Seaborne * Alan Cabera * Bertrand Delacretaz * Nandana Mihindukulasooriya * Dave Fisher * Alexei Fedotov Ted Dunning * Chris Mattman * Ralph Goers * Jakob Homan * Andreas Kuckartz - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Marmotta into the incubator
On 29/11/12 20:51, Peter Ansell wrote: On 29 November 2012 21:28, Andy Seaborne a...@apache.org wrote: == Relationships with Other Apache Projects Although current RDF/SPARQL support in LMF is build on top of OpenRDF Sesame API, Marmotta is closely related to many Apache projects, such as Stanbol, Jena and Any23. See “Alignment” above. Hi Andy, Any23 is also based on the OpenRDF Sesame API, so it doesn't seem to fit in a list after Although. It may be easier to fit it in the list before saying Although. In addition, Stanbol can theoretically work with OpenRDF Sesame API through Clerezza, or through OWLAPI with my extensions that have not yet been accepted into the OWLAPI trunk. May be easier to avoid saying Although altogether. Good luck Marmotta team! Peter, The dev mailing list is up and running so do come and join the discussions. New style naming: dev AT marmotta.incubator.a.o Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How to use an apache webpage
On 20/12/12 05:33, Joe Schaefer wrote: All webpages we host are works in progress subject to change when better consensus emerges. Please do not affix any labels to the pages describing them as drafts as that only serves to discourage others from working on them. Normative policy documents are few and far between and you will recognize them by their self-descriptions as such. Every interested party is welcome to collaborate with us to produce more informative and accurate webpages through the CMS. Please help out where you can. Our documentation becomes increasingly authoritative as more and more people refer to it in positive ways; ie the best documents wear well over time. HTH Sent from my iPhone I've always found the draft label confusing and as a newbie, suggesting that content is not yet active but will become so at some time. But it seems from this thread it means descriptive or advice or non-normative in W3C-standards-speak. To me, any non-draft documents is documenting current state and subject to change. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Expressing priorities about release reviews
On 13/01/13 12:45, Benson Margulies wrote: ... 3. Most of the reviewing in this area is done by sebb. We're lucky to have him paying attention to this at all, because it sure seems sometimes as if no one else does. Adding all of this up, I've got a very modest proposal. Let's create a checklist, put it prominently at the top of the relevant doc, and then see if we can't improve the visibility of this. Sebb, could I ask you to dump your checklist into this email thread? +1 We need to clone sebb's reviewing process as good practice and it would pull together the knowledge about NL. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
On 25/03/13 08:41, ant elder wrote: On Mon, Mar 25, 2013 at 8:36 AM, Upayavira u...@odoko.co.uk wrote: Now, you might argue that mentoring is a lot more than voting, but we could create another bottleneck in getting release votes through, requiring votes from incubator PMC members who are not particularly focused on the podling. Thats exactly what i would argue, mentoring is a lot more than voting on releases. Many (most?) poddlings don't get three mentor votes on releases anyway and have to come to general@ so changing to have non-PMC mentors isn't going to make that worse than it already is. ...ant I agree mentoring is a lot more than voting. One point though (not suggesting new process) - there is some value in coming to general@ at least once in the podlings incubation. It brings in a wider perspective and understanding because small-N mentors on a podling may not themselves have a complete awareness of everything. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Taverna workflow
On 25/09/14 19:19, Suresh Marru wrote: If you need a mentor, count me in. I actively contribute to Apache Airavata, and will be happy to bring our experiences from a similar journey. Infact Ross queried on airavata lists few years ago about potential taverna move to airavata/apache(Ross mentioned it further in this thread), good to see finally its happening. Integrating plugin community into the apache project (once its voted in) seems to be a low hanging fruit to diversify. On 25/09/14 17:36, Suresh Srinivas wrote: If you you need a volunteer, I am available. Hi there, It being Friday, and Stian is about to be away, I've added you both to the mentors list. Taverna has a long history so getting as much experience from mentors will be very valuable. Thanks Andy PS I put Michael in as Not formally a mentor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Taverna workflow
On 14/10/14 16:51, Marlon Pierce wrote: Hi all-- I'm a bit late on this but I would also like to serve as a mentor. I'm a PMC member of Apache Airavata and Apache Rave, and I've also served as a mentor for Apache Stratos. Marlon Marlon, Thank you for the offer - I've added you to the the mentor list on the proposal. Andy On 9/26/14, 10:18 AM, Andy Seaborne wrote: On 25/09/14 19:19, Suresh Marru wrote: If you need a mentor, count me in. I actively contribute to Apache Airavata, and will be happy to bring our experiences from a similar journey. Infact Ross queried on airavata lists few years ago about potential taverna move to airavata/apache(Ross mentioned it further in this thread), good to see finally its happening. Integrating plugin community into the apache project (once its voted in) seems to be a low hanging fruit to diversify. On 25/09/14 17:36, Suresh Srinivas wrote: If you you need a volunteer, I am available. Hi there, It being Friday, and Stian is about to be away, I've added you both to the mentors list. Taverna has a long history so getting as much experience from mentors will be very valuable. Thanks Andy PS I put Michael in as Not formally a mentor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Accept Taverna into the Apache Incubator
Following the discussion earlier in the thread: https://www.mail-archive.com/general@incubator.apache.org/msg45241.html I would like to call a Vote for accepting Taverna as a new incubator project. The proposal is available at: https://wiki.apache.org/incubator/TavernaProposal Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC [ ] +1 accept Lens in the Incubator [ ] ±0 [ ] -1 because... Only Votes from Incubator PMC members are binding, but everyone is welcome to contribute to the process. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Taverna into the Apache Incubator
Dmitriy Repchevsky dmitry.repchev...@bsc.es Donal K. Fellows donal.k.fell...@manchester.ac.uk Finn Bacall finn.bac...@manchester.ac.uk Hajo Nils Krabbenhöft h...@krabbenhoeft.de Ian Dunlop ian.dun...@manchester.ac.uk Ingo Wassink i.h.c.wass...@ewi.utwente.nl Julián Garrido jgarr...@iaa.es Mark Wilkinson ma...@illuminae.com Luke McCarthy elmccar...@gmail.com Robert Haines rhai...@manchester.ac.uk Shoaib Sufi shoaib.s...@manchester.ac.uk Steffen Möller moel...@inb.uni-luebeck.de Stian Soiland-Reyes st...@soiland-reyes.com (ICLA on file.) Stuart Owen so...@cs.manchester.ac.uk In addition to the Core Team (mentioned earlier), this list also reflects Taverna's existing meritocracy as it includes plugin developers whose contributions have been merged into the main code base. We acknowledge that not all of these are likely to continue as Core developers, but would like to encourage that during the Incubating process. Affiliations The majority of the initial committers are employed by University of Manchester as part of the myGrid team, including responsibilities for contributing to and supporting Taverna. http://www.mygrid.org.uk/about-us/people/core-mygrid-team/. Dmitriy Repchevsky is employed by the Barcelona Supercomputing Center, including responsibilities for contributing to Taverna. Steffen Möller is employed by University of Lübeck. Julián Garrido is employed by Instituto de Astrofísica de Andalucía. Sponsor Champion Andy Seaborne Nominated Mentors Andy Seaborne Chris Mattmann Suresh Srinivas Suresh Marru Marlon Pierce Offers of participation, not formally a mentor: Michael Joyce Sponsoring Entity The Incubator. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Taverna into the Apache Incubator
[ ] +1 accept Taverna in the Incubator [ ] ±0 [ ] -1 because... +1 (binding) Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [] Accept Taverna into the Apache Incubator
yes - s/Lens/Taverna/ (sigh) On 16/10/14 18:27, jan i wrote: +1 binding (assuming its Taverna, and there has been a simple copy/paste error). have fun. jan I. On 16 October 2014 18:48, Alan D. Cabrera l...@toolazydogs.com wrote: +1 - binding I assume that you mean Taverna instead of Lens. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] Accept Taverna into the Apache Incubator
To: general@incubator.apache.org This VOTE passes with 13 +1 binding votes Suresh Marru Alan D. Cabrera jan I Ralph Goers Bertrand Delacretaz Andy Seaborne Suresh Srinivas Chris Mattmann Jean-Baptiste Onofré Jake Farrel Leif Hedstrom Jean-Louis Monteiro Roman Shaposhnik and no 0's or -1's I'll start the podling setup process. Thank you everyone. Andy On 16/10/14 16:54, Andy Seaborne wrote: Following the discussion earlier in the thread: https://www.mail-archive.com/general@incubator.apache.org/msg45241.html I would like to call a Vote for accepting Taverna as a new incubator project. The proposal is available at: https://wiki.apache.org/incubator/TavernaProposal Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC [ ] +1 accept Taverna in the Incubator [ ] ±0 [ ] -1 because... Only Votes from Incubator PMC members are binding, but everyone is welcome to contribute to the process. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator PMC/Board report for Nov 2014 ([ppmc])
On 27/10/14 14:15, Marvin wrote: Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 19 November 2014, 10:30 am PST. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, Nov 5th). Please submit your report with sufficient time to allow the incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Thanks, The Apache Incubator PMC Taverna wasn't in the incubator template so I added a section for it to make sure it didn't get lost. No shepherd assignment. Have I failed to find some place that needs updating so the template includes Taverna? Or was it just timing, because we only started late in October? Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Git write access for podlings
On 02/01/15 16:40, David Nalley wrote: On Fri, Jan 2, 2015 at 5:36 AM, Stian Soiland-Reyes st...@apache.org wrote: Git allows you to commit as whoever you want - e.g. like in SMTP email, the headers are decided by the sender. SVN on the other hand will show the authenticated user in the commit log. So - speaking as a former sysadmin - it sounds a bit daring to let anyone new to Apache from a fresh Incubator proposal to also get instant write access to all Incubator projects, including those that are just about to graduate. From a git commit log perspective, this is true, but we also retain push records that show us the user authenticated as, as well as the IP Address they are pushing commits from. In example: https://git-wip-us.apache.org/logs/asf/incubator-nifi.git I looked at Jena's log and until Dec 2 this year, the IP address was always @http.192.168.0.58 and since 2014-12-03 there are likely looking true IP addresses but of the NAT gateway used. Andy That said - assuming there has not been any reported abuse of this global write access - then it is a very good sign of all the new committers being responsible people - or perhaps they just didn't know they had that write access to begin with :). It's a trust-thing - I remember when I started my first proper sysadmin job, and on day one received the root passwords for systems running web and email for 30.000 students. Don't mess it up was implicit. Apache Commons has already given write access to *all* ASF committers [1] - which would presumably include any incubator committers. If it's good enough for for Commons, it should be good enough for Incubator. Part of moving to Apache is also to trust all your committers. [1] https://mail-archives.apache.org/mod_mbox/commons-dev/201412.mbox/%3ccab917rjy57z-4pnwthvr9tuq7y3td8usg8jcmhvdthalwho...@mail.gmail.com%3E Even with the danger of introducing a bigger temptation by explicitly documenting the incubator-wide write policy - I would still +1 to document this so you are aware and don't accidentally push back (as git workflow is to commit locally and it is a bit easy to accidentally do git push) - with a clause that this does not mean you have formally become a committer on the other incubator projects. I would propose to also improve documentation at http://wiki.apache.org/general/GitAtApache http://www.apache.org/dev/git.html http://www.apache.org/dev/writable-git so it does not give impression you have to use SVN-with-git-mriroring or that writeable GIT is experimental. I don't know enough about the particular setup at git.apache.org yet to do it myself. sigh I thought we had removed all of the experimental labels. Thanks for finding these. --David - 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] TinkerPop: A Graph Computing Framework [RE-SUBMISSION]
Looks good but there is one part that wasn't clear to me. In this proposal, the TinkerPop2 repos appear in the initial source listing as well, but are not in the submission plan. Is TinkerPop2 also part of the proposal? Is there is risk in it being a burden on the project? Conversly, if it is difficult to disentangle TinkerPop2 and TinkerPop3 (copyright, IP), then non-granting of it might lead to hard issues later. Andy R. Initial Source TinkerPop https://wiki.apache.org/incubator/TinkerPop is currently hosted on GitHub https://wiki.apache.org/incubator/GitHub: https://github.com/tinkerpop/. The following repositories would like to be migrated to ASF. TinkerPop3 https://wiki.apache.org/incubator/TinkerPop3 https://github.com/tinkerpop/tinkerpop3 Blueprints (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2) https://github.com/tinkerpop/blueprints Pipes (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2) https://github.com/tinkerpop/pipes Frames (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2 https://github.com/tinkerpop/frames Gremlin (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2) https://github.com/tinkerpop/gremlin Rexster (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2) https://github.com/tinkerpop/rexster S. Source Intellectual Property Submission Plan TinkerPop https://wiki.apache.org/incubator/TinkerPop has required CLAs from contributors in the past to ensure solid IP provenance. TinkerPop https://wiki.apache.org/incubator/TinkerPop plans to submit a Software Grant for the content in the following repositories: https://github.com/tinkerpop/tinkerpop3 We plan to transfer to the ASF the TinkerPop https://wiki.apache.org/incubator/TinkerPop trademark as well as the commissioned artwork for TinkerPop https://wiki.apache.org/incubator/TinkerPop logos and the http://tinkerpop.com http://tinkerpop.com/ and http://tinkerpop.org http://tinkerpop.org/ domains.
Re: [DISCUSS] Commons RDF to join the Apache Incubator
On 11/02/15 10:02, Rob Vesse wrote: Marvin Yes I would be willing to be a mentor for this podling if there isn't sufficient volunteers and they would be willing to have me Thank you - added! (before you change your mind :-)) I agree that there is a tendency then to make the podling Jena heavy but I have had zero involvement in the Commons RDF effort to date and the API they are talking about currently is at a level of a stack that I have historically contributed nothing to nor do I particularly use so hopefully I would be seen as relatively neutral. To be honest I wouldn't have the bandwidth to get actively involved in the code design) efforts (nor do I particularly want to) and thus would only want to be a mentor. Understood. As you said this would probably be a relatively easy mentoring gig with most of the effort being around just keeping an eye on the community to sign off and comment on reports and to review release as and when they come around. I hope you'll bring in your experience from other projects, inside and outside Apache. On 10/02/2015 20:31, Marvin Humphrey mar...@rectangular.com wrote: (sorry to chop but it's a long way down) 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. Ack. Are Andy and Reto opting out out as a gesture of openness to Sesame? Sergio has done a great job of pulling the proposal together. I have a one-podling-at-a-time policy and Taverna is already filling the slot. In my experience, champion also gets involved in the initial bootstrap tasks, and in this case I would hope we can easily share those tasks around. Andy Rob On 10/02/2015 20: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. 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
Re: [DISCUSS] Commons RDF to join the Apache Incubator
On 11/02/15 08:14, Sergio Fernández wrote: On 10/02/15 21:31, Marvin Humphrey wrote: 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? Completely :-) Yes. Personally, I'd keep the destination open for both TLP and Apache Commons, then see where we are at graduation time. A lot of (good) things can happen during incubation. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: proposal: mentor re-boot
On 08/01/15 16:48, Chip Childers wrote: On Wed, Jan 07, 2015 at 08:18:59PM -0800, Marvin Humphrey wrote: Retiring the role of Champion sounds like an idea whose time has come. We gave the Champion additional oversight responsibilities a while back -- but how many times since then has having that additional layer made a difference? My 2 cents: In my experience, the Champion is a useful concept for the purpose of having discussions with the incoming project's community *before* they become a podling. I've acted as a champion for one podling so far, as well as acted in this role for one community that ended up *not* wanting to incubate. I see this as a valuable activity (I don't care what it's called), because it's important that incoming projects understand what they are signing up for. As much as it's an investment for the ASF to accept podlings, it's an investment for the inbound communities to make the proposal. For the project that I acted as a Champion for, I considered that part of the work to be done when they became a podling. I also asked to be a mentor, and am doing so now... and being a mentor is a bit different from that initial introduction. In the end though, regardless of what we name things, podlings should have support from people here in the incubator from the time they start considering the move to the time they become a TLP. +1 The other minor aspect of champion can making sure getting bootstrap happens quickly. Other mentors may not immediately be active, or as well known to the podling. It is admin smoothing over the transition, not vital, but helpful. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [GROOVY] mailing lists are ready, see you there!
Great - it's good that was the understanding on the lists anyway and notification of the action is a good idea as Bertrand notes; it's also highlighting the move (can't assume all the user list subscribers have groked that!). A read-only-ish list like commits is not an issue. Andy (This it's on the web so I can use it On 27/03/15 06:25, Paul King wrote: Only users from the previous list will be added and there was an assumption that all code/patches sent to that list would be Apache licensed by default. So, not quite the same thing but as long as we warn people and tell them how to unsubscribe, I think auto subscribing them would be OK? Cheers, Paul. On 27/03/2015 8:21 AM, Andy Seaborne wrote: Signing up to Apache list means the user is making an explicit act of joining a place where code (or pointers to code) sent is granted to Apache. Implicit subscription muddies the waters for contributions. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept CommonsRDF into the Apache Incubator
On 27/02/15 19:19, Lewis John Mcgibbney wrote: Hi general@, Over the last while a number of individuals have been putting together a proposal and gathering interest in proposing Commons RDF for acceptance into the Apache Incubator. Having worked our way through the Incubator documentation checklists - http://incubator.apache.org/guides/proposal.html#formulating, we are now brining this proposal back to the general@ list. 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. The current CommondRDFProposal document can be found at - https://wiki.apache.org/incubator/CommonsRDFProposal This thread is therefore aimed at obtaining general consensus from the incubator community on whether the proposal document is suitable and whether the project as described should begin an incubation period at Apache. The VOTE is therefore as follows [ ] +1 I am happy with Commons RDF entering incubation [ ] +0/-0 I am neither yay or nay [ ] -1 I am not happy with this proposal because The VOTE will be open for at least 72 hours. p.s. Here is my +1 PPMC binding I'm not sure what the protocol is here, or even if there is one! But here's my +1 (binding) if it counts. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [STATUS] WAS [DISCUSS] Commons RDF to join the Apache Incubator
On 22/02/15 19:52, Lewis John Mcgibbney wrote: Hi Folks, I've read through the commentary on the recent [DISCUSS] thread for Commons RDF [0]. It is not clear to me what the outcome was really... can anyone else provide a fresh insight as to where this proposal is going and what is required to progress it from status draft to status proposal? Thanks in advance Lewis [0] *http://s.apache.org/Vtk http://s.apache.org/Vtk* Sergio is out for a bit, back soon. Since there is no rush (?), no one has rushed ... Andy On 12/02/15 14:12, Sergio Fernández wrote: I'll be out for a couple of weeks. But my colleagues in the proposal will keep involved in the discussion. Then let's hope in that time someone will have jumped in and we can move forward with the formal process. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [STATUS] WAS [DISCUSS] Commons RDF to join the Apache Incubator
John, Thank you very much for the offer of mentoring - I've added you to the list. And I've renamed the proposal as CommonRDFProposal as that seems to be naming style on the wiki. Andy On 22/02/15 20:56, John D. Ament wrote: Lewis, It looks like there were a few things called out. - Identify a champion (looks like you did already) - Solicit support from mentors. It looks like those are the only two open issues. Benedikt cannot be listed as a mentor, as mentioned previously (unless I'm missing an email), but feel free to include him as a PPMC member/commons representative (would be more accurate than listing under mentor from my POV.. unless he's interested in helping out the incubator and shows off his skills quick enough [PS - looking for shepherds for next month's report]). If you need a hand, I'd be happy to throw my hat in with you and Rob (I'm jumping at Marvin's note about low maintenance). John On Sun Feb 22 2015 at 2:53:26 PM Lewis John Mcgibbney lewis.mcgibb...@gmail.com wrote: Hi Folks, I've read through the commentary on the recent [DISCUSS] thread for Commons RDF [0]. It is not clear to me what the outcome was really... can anyone else provide a fresh insight as to where this proposal is going and what is required to progress it from status draft to status proposal? Thanks in advance Lewis [0] *http://s.apache.org/Vtk http://s.apache.org/Vtk* -- *Lewis* - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [STATUS] WAS [DISCUSS] Commons RDF to join the Apache Incubator
On 23/02/15 10:32, Benedikt Ritter wrote: Hello, 2015-02-22 21:56 GMT+01:00 John D. Ament johndam...@apache.org: Lewis, It looks like there were a few things called out. - Identify a champion (looks like you did already) - Solicit support from mentors. It looks like those are the only two open issues. Benedikt cannot be listed as a mentor, as mentioned previously (unless I'm missing an email), but feel free to include him as a PPMC member/commons representative (would be more accurate than listing under mentor from my POV.. unless he's interested in helping out the incubator and shows off his skills quick enough [PS - looking for shepherds for next month's report]). I think at the moment commons representative would be the best to describe my role. I'm interested in helping out here at the incubator, but I'll need time to learn how this project works. Benedikt - I've updated the proposal with a Apache Commons Representative section. Andy Regards, Benedikt If you need a hand, I'd be happy to throw my hat in with you and Rob (I'm jumping at Marvin's note about low maintenance). John On Sun Feb 22 2015 at 2:53:26 PM Lewis John Mcgibbney lewis.mcgibb...@gmail.com wrote: Hi Folks, I've read through the commentary on the recent [DISCUSS] thread for Commons RDF [0]. It is not clear to me what the outcome was really... can anyone else provide a fresh insight as to where this proposal is going and what is required to progress it from status draft to status proposal? Thanks in advance Lewis [0] *http://s.apache.org/Vtk http://s.apache.org/Vtk* -- *Lewis* - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...
Podling commons-rdf fits that description. It started at GitHub in the knowledge that ASF was a possible route; ALv2 from the start. (We started at GH because there are people who would join discussions more freely on GH.) It so happens, the contributors are all ASF committers. With advice from our champion, we settled on one SG, naming the contributors and signed by the original creator of the project (Sergio, who created the project) on behalf of the Commons RDF Community. We've just done that and ingested the code (today!) - if there is a better way, now is the time to say so because we can adjust easily. Andy (The SG leaves open things like an updated AL, not that is likely.) On 26/03/15 16:42, P. Taylor Goetz wrote: This seems like an appropriate thread to raise a question that’s been in the back of my head for a while… If a new project is created on github (or elsewhere — i.e. outside of the ASF), but with the intention that it would be contributed to an existing ASF project (ALv2 license from day 1), would a Software Grant and/or IP clearance be required? Put another way, what are the best practices to follow when creating a new project, outside the ASF, with the goal of eventually contributing that work to an existing ASF project? The documentation for the IP clearance template [1] states: Any code that was developed outside of the ASF SVN repository must be processed like this, even if the external developer is an ASF committer.” To me that sounds like any new module, or even a sufficiently large pull request, requires IP clearance. If that’s the case, I would expect the clearance document list [2] to be much longer than it is, and have more ASF projects represented there, especially some of the faster growing ones. -Taylor [1] http://incubator.apache.org/ip-clearance/ip-clearance-template.html [2] http://incubator.apache.org/ip-clearance/index.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [GROOVY] mailing lists are ready, see you there!
Signing up to Apache list means the user is making an explicit act of joining a place where code (or pointers to code) sent is granted to Apache. Implicit subscription muddies the waters for contributions. Andy On 26/03/15 21:55, Ted Dunning wrote: your loop is a fine solution. Just test it carefully ahead of time. On Thu, Mar 26, 2015 at 2:44 PM, Konstantin Boudnik c...@apache.org wrote: I think you can write a script to do a call to echo subscribe | mailx -s subscribe dev-subscribe-john= host.dom...@groovy.incubator.apache.org via the list of current list subscribers. Or perhaps open a INFRA ticket and provide them with the list of emails addresses to be subscribed. There might be another way that I am unaware about though. Anyone? Cos On Thu, Mar 26, 2015 at 09:54PM, Guillaume Laforge wrote: And how to add in batch the current subscribers of the old list. 2015-03-26 21:29 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com: BTW should we already update the links [1] on the website? How should we proceed to migrate/deprecate the Codehaus lists? [1] http://groovy-lang.org/mailing-lists.html 2015-03-26 20:34 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com : I got them too. Le 26 mars 2015 19:10, Guillaume Laforge glafo...@gmail.com a écrit : I also got moderation messages 2015-03-26 18:51 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org: I don't. On Thu, Mar 26, 2015 at 10:47 AM, Andrew Bayer andrew.ba...@gmail.com wrote: Just making sure - others besides me are getting the subscribe moderation emails? A. On Thu, Mar 26, 2015 at 10:22 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Mar 26, 2015 at 6:21 PM, Jochen Theodorou blackd...@gmx.org wrote: ...listname-subscribe@groovy.incubator.a.o ? of course yes, sorry - the names on INFRA-9339 are correct. -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 -- Guillaume Laforge Groovy Project Manager Blog: http://glaforge.appspot.com/ Social: @glaforge http://twitter.com/glaforge / Google+ https://plus.google.com/u/0/114130972232398734985/posts -- Guillaume Laforge Groovy Project Manager Blog: http://glaforge.appspot.com/ Social: @glaforge http://twitter.com/glaforge / Google+ https://plus.google.com/u/0/114130972232398734985/posts - 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: apache package naming convention
Hi, Jena graduated 2012 with old namespaces under com.hp.hpl.jena, and some under org.openjena, with an intention to change at the first major release update. As new packages came along, they went into org.apache.jena but the user facing packages remained where they were. We released Jena 3.0.0 last month, so 3 years. That major release was coupled to another incompatible change (RDF 1.1 semantics) so 3.x wasn't just to do the packages, package renaming waited until a convenient point. Our users have data with (RDF) namespaces under old names - we are not planning on changing that at all. (A general issue for all linked data.) I don't see it as an issue for graduation if the project has considered the matter. Andy On 07/08/15 23:16, Matthew Hayes wrote: Hi all, Roman Shaposhnik suggested I open a discussion on the following topic: For Apache DataFu, all of the Java classes are declared in a datafu.* namespace. This has been the naming convention since the DataFu project started in 2010. Since DataFu became part of the Apache incubation process, the topic has come up of moving all of the classes into a org.apache.datafu.* namespace. This was first discussed in January 2014 (see DATAFU-7) and most recently again in the past couple weeks. The consensus at the time last year was that it would be a huge pain for users and not worth the cost. It would break any script out there currently using DataFu. Also Jakob Homan and Russell Journey pointed out that this is just a convention and not all Apache projects follow it. Since we would like DataFu to graduate sometime soon it would be good to clarify what the requirements are on package naming conventions before we do a release. Thoughts? Thanks, Matt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Taverna Parent 1-incubating-RC4 Apache Taverna Language 0.15.0-incubating RC4
There are 2 mentors votes for this release. Could we get a third please, or the assistence to produce a better release? Andy On 05/08/15 12:11, Ian Dunlop wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, The Apache Taverna Incubator PPMC has voted +5 to release Apache Taverna Parent 1-incubating (RC4) Apache Taverna Language 0.15.0-incubating (RC4) Incubator PMC members please review and vote on this incubator release. Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2) and workflow inputs/outputs/run (DataBundle), as consumed and produced by the Apache Taverna workflow system. The API includes support for working with Research Object Bundles, and loading/saving Taverna workflows in different formats. Please see original [VOTE] thread http://mail-archives.apache.org/mod_mbox/incubator-taverna-dev/201507.mb ox/%3C55B8DBC7.2040806%40manchester.ac.uk%3E and [DISCUSS] thread http://mail-archives.apache.org/mod_mbox/incubator-taverna-dev/201507.mb ox/%3C55B8DC3F.2070602%40manchester.ac.uk%3E Please note that the git commit ids were incorrect in the original [VOTE] email but were corrected during the vote process. Also, during the release checks some NOTICE files were found to contain information that was already in the top level LICENSE and a bug was raised against it, see https://issues.apache.org/jira/browse/TAVERNA-864 The release candidates to be voted over are available at: https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna- parent-1-incubating-RC4/ https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna- language-0.15.0-incubating-RC4/ SHA-1 checksums: 3eb09278b914b96fb5c6059523b1bb3e69a09334 taverna-parent-1-incubating-source-release.zip 4eeb37d141fea284cc8de17635d97a47b279ea91 taverna-language-0.15.0-incubating-source-release.zip MD5 checksums: bccfe1116189f5ccc640fcbed4a4f96f taverna-parent-1-incubating-source-release.zip 685b3aed3833a0b921d129995944dfc3 taverna-language-0.15.0-incubating-source-release.zip Build the release candidates in the above order, using: Java 7: mvn clean install -Dmaven.javadoc.skip=true (see https://issues.apache.org/jira/browse/TAVERNA-867 for the reasons the maven command line params are required) Java 8: mvn clean install The release candidates correspond to the following git commits: https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent .git;a=commit;h=b12a1cc0ed2540507ab43107124e8ee911da4ddf https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git ;a=commit;h=e2a9954e796d886d137eed3091b21637e9c8d1fd Release candidates are signed with a GPG key available at: https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachetaverna-1006 / The changelog for this release is available from JIRA: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231832 2version=12332247 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231832 2version=12332246 Please vote on releasing these packages as: Apache Taverna Maven Parent 1-incubating Apache Taverna Language 0.15.0-incubating The vote will be open for a minimum of 72 hours. [ ] +1 Release this package [ ] 0 I don't feel strongly about it, but don't object [ ] -1 Do not release this package because... Cheers, Ian -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVwe91AAoJEPK45GBX+Cy5lMsH/jiDvvduoZ43y9SVMQcbIvdn GZDXOviSco5NAWnekqVzR5juXXHGVCZD56NFDfDkzlS1EinQP11HWEZjx1Tgz5TL 0ghvwRtymc5s6Vu2SMlWeiZszja/lD2430zc28jwtBhesd3xckUIa2VHg9viDiaT w5iCQQB95TiCnShJaUDbFg0TiLB2BH/xZrb07967MsyH1YeSOI72aOhVkxbFthlE ELJhRmKBtmfl/RJoPydzrs4IOvvml57hcJQT6DjONGEuaIzSvOJVcV8l+oZgmM1a QqK6bjS0I+rmcK6udAFrgZmtNKsI/n+qufnaTxg1j1ghZRhDWo/ZAawpzGBo/+I= =K8dX -END PGP SIGNATURE- - 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: Mentor disengagement - a suggestion
On 14/10/15 16:21, Ross Gardler wrote: Further to Sam's suggestion and observations below see Suggestion 0.1.8 at http://wiki.apache.org/incubator/IncubatorIssues2013#Suggestions (Summary: Champion => PPMC chair) I agree with the comments that champion-as-chair is a negative to the community self-goverance. Some kind of phased transition seems better, running down the process commitments of mentors as the community ramps up. "Champion" => "lead mentor" and the incoming community nominates one of their own as "community point of contact" or "community lead". "Community lead" picks up responsibilities like reporting (usually in the 3 months phase??) and is there to make sure sufficient mentors are active enough. Andy -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Wednesday, October 14, 2015 7:26 AM To: general@incubator.apache.org Subject: Re: Mentor disengagement - a suggestion On Wed, Oct 14, 2015 at 10:07 AM, Ted Dunningwrote: On Wed, Oct 14, 2015 at 6:46 AM, Jim Jagielski wrote: My point is that with 1 mentor, everyone knows where the buck stops. With >1 nobody knows. A flat hierarchy for mentors does not seem workable or, at least, optimal. That's a fine point. But it is counter to my experience. For instance, on Kylin, I was extremely active early on. Lately, Julian Hyde has taken much more of the questions. It has worked very well. We have a third mentor (whose name I won't mention) who has been nearly completely missing, but that hasn't been a problem since everybody knows that they are totally MiA. If we wish to address this, and not "force" mentors to leave, we could simply add the idea of "lead mentor" and have the PPMC vote on which mentor they want to be the lead mentor (pseudo PPMC chair); the remaining mentors would remain as co-mentors but the intent is that the lead mentor would be the primary person responsible. I think that this is largely process without clear need. But others may have different experience. The following is from the definition of "champion" on the incubator roles and responsibility page[1]: --- During incubation, the Champion: * Coordinates the creation and timely delivery of the podling's board reports. * Keeps an eye on the mentors' activity and takes action (ask for new mentors, talk to the Incubator PMC) if they don't seem to provide enough oversight or mentorship to the podling, --- First question: does this description match current practice. Second question: is there something in that description that needs to get done, but isn't getting done? There also is a separate thread about the number of podlings that the Incubator can handle. That number would tend to increase if some of the work were decentralized more. My take is that (at least for this month) Marvin is effectively doing the first bullet for all podlings. Now I don't see any signs of burnout in Marvin, so that's not the immediate concern, but scalability and sustainability would benefit from decentralizing this more. As to the second bullet, it isn't clear to me that that is being done. Even if it were only a one time thing, reverifying (or in many cases, naming) the champion for every podling, and then asking each to reverify the active status for every mentor for podlings that they champion might go a long way toward easing some of the concerns that people have raised. Ultimately the definition of champion, as posted, should match reality. - Sam Ruby [1] https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fincubator.apache.org%2fincubation%2fRoles_and_Responsibilities.html%23Champion=01%7c01%7cRoss.Gardler%40microsoft.com%7c02e20d0e08f54f9c81f408d2d4a356cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=q10OQ8l3N4%2bAPk%2bXJYxZVF1mEREPIOYNpQcD9Frr0rI%3d - 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] Accept Rya into the Apache Incubator
+1 (binding) On 14/09/15 16:17, Adam Fuchs wrote: Thanks again for the healthy discussion on Rya. With that, I would like to call a VOTE for accepting Rya as a new incubator project. The proposal text is included below, and is posted on the wiki here: https://wiki.apache.org/incubator/RyaProposal The discussion thread on Rya starts here: http://mail-archives.apache.org/mod_mbox/incubator-general/201509.mbox/%3CCALt5_xJKtRcUr3WGjfrY77DYWF0-8DWi%3DzyS7hrMFTg%2BYAORjQ%40mail.gmail.com%3E The vote will be open until Thu Sep 17 15:15:00 UTC 2015. [ ] +1 accept Rya in the Incubator [ ] ±0 [ ] -1 because... Thanks, Adam = Rya Proposal = == Abstract == Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that supports SPARQL queries. == Proposal == Rya is a scalable RDF data management system built on top of Accumulo. Rya uses novel storage methods, indexing schemes, and query processing techniques that scale to billions of triples across multiple nodes. Rya provides fast and easy access to the data through SPARQL, a conventional query mechanism for RDF data. == Background == RDF is a World Wide Web Consortium (W3C) standard used in describing resources on the Web. The smallest data unit is a triple consisting of subject, predicate, and object. Using this framework, it is very easy to describe any resource, not just Web related. For example, if you want to say that Alice is a professor, you can represent this as an RDF triple like (Alice, rdf:type, Professor). In general, RDF is an open world framework that allows anyone to make any statement about any resource, which makes it a popular choice for expressing a large variety of data. RDF is used in conjunction with the Web Ontology Language (OWL). OWL is a framework for describing models or ontologies for RDF. It defines concepts, relationships, and/or structure of RDF documents. These models can be used to 'reason/infer' information about entities within a given domain. For example, you can express that a Professor is a sub class of Faculty, (Professor, rdfs:subClassOf, Faculty) and knowing that (Alice, rdf:type, Professor), it can be inferred that (Alice, rdf:type, Faculty). SPARQL is an RDF query language. Similar with SQL, SPARQL has SELECT and WHERE clauses; however, it is based on querying and retrieving RDF triples. Work on Rya, a large scale distributed system for storing and querying RDF data, started in 2010. == Rationale == With the increase in data size, there is a need for scalable systems for storing and retrieving RDF data in a cluster of nodes. We believe that Rya can fulfill that role. We expect that communities within government, health care, finance, and others who generate large amounts of RDF data will be most interested in this project. From its inception, the project operated with an Apache-style license, but it was open to mostly US government-related projects only. We believe that having the project and the development open for all will benefit both the project and the interested communities. == Current Status == The project source code and documentation are currently hosted in a private repository on Github. New users are added to the repository upon request. === Meritocracy === Meritocracy is the model that we currently follow, and we want to build a larger and more diverse developer community by becoming an Apache project. === Community === Rya has being building a community of users and developers for the past 3 years. There is currently an active workgroup with monthly meetings and the number of participants in the meeting is increasing. === Core Developers === The core developers are a diverse group of people who are either government employees or former / current government contractors from different companies. === Alignment === Rya is built on top of Accumulo, an Apache project. == Known Risks == === Orphaned Products === There is a very small risk of becoming orphaned. The current contributors are strongly committed to the project, there is a large enough number of developers interested in contributing to the project, and we believe that the support for the project will continue to grow from the interested communities. === Inexperience with Open Source === The initial committers have various degrees of experience with open source projects - from very new to experienced. This project was open source within government from the beginning. We are aware that it will be different and more difficult functioning in a real open source environment. We are enthusiastic and committed to learning the Apache way and being successful in operating under Apache's development process. === Homogenous Developers === The current list of developers form a heterogeneous group, with people for academia, government, and industry, collaborating from distributed geographic locations. We aim to expand the list of contributors with the help of the Apache incubation process. === Reliance on Salaried Developers ===
Re: Should Apache VOTEs be in a first-come, first-serve queue?
On 14/09/15 17:26, Marko Rodriguez wrote: Hello, It appears that VOTEing in general@ is inefficient and biased. An Apache member will see a VOTE on the list and can choose whether to participate in that VOTE or not. I believe there are problems with this algorithm. The first has to do with efficiency. For instance, Groovy received (out of my foggy memory) some 20+ VOTEs when only 3 were were needed and other project VOTEs were sitting around hoping for an Apache member to spend time on their project. Second, if no Apache member really cares about the project's VOTE, then the project committee is left "hoping" that someone will care --- pinging around to their mentors (no reply), to the list ("please")… like beggars in the street. Should general@ have a VOTE queue where if an Apache member has time to VOTE they can only VOTE on a project at the top of the queue. They can not pick which projects to VOTE on. This solves the two aforementioned problems: 1. Apache member attention is not wasted on low-entropy states (why are 20 +1 VOTEs needed -- no new information is contributed). - increased efficiency 2. Apache member attention is not biased by human whim (why are VOTE requests left idle while later VOTE requests are satiated). - remove human bias With a VOTE queue, each project's VOTE requirements are met in the order in which the VOTE was added to the queue and no project is left pinging mentors and the list saying -- "can someone please VOTE on our artifacts?" Thoughts?, Marko. http://markorodriguez.com There is an implicit assumption of uniformity of voters in that description. For me, I vote when I know something about what I'm voting on. So if I came along with some spare time [*], and the queue head was for something I don't feel I had the background to be useful, I wouldn't vote, and that time will go elsewhere. The effects you describe exist to some extent but I think they reflect underlying matters, and are not problems per se. Andy [*] This is hypothetical. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New mentors for Taverna?
Hi all, I'm one of the "semi-active mentors" of Taverna. In my case, I have a new $job, which is related to some Apache communities but not Taverna. A new job is a busy time so I'm really not able to properly support the podling at the moment. I wish I could but I also have to be realistic. Taverna is (I believe) in good shape. Having done an incubator release of part of the codebase, they understand and take the IP issues seriously. They have added a person to the PPMC. All-in-all, good progress towards graduation and getting more of the codebase out is the next step. So - please could Taverna have some additional mentors? Andy On 01/02/16 14:36, Stian Soiland-Reyes wrote: The majority of the mentors of the Taverna podling have raised concerns that they no longer have sufficient time available to help Taverna in the incubator. In effect we will then have 2 semi-active mentors remaining for continuity. This has become a concern because Taverna is picking up speed and moving towards releases of the main code base (our first release was for a more self-contained library), and this means some effort is needed to review and guide us through those releases. We in the Taverna PPMC have already learnt a lot about the Apache Way, we have done our first release, we had 3 very successful GSOC students, and we have voted in our first new PPMC member. However knowing the effort needed to review a "new" code base for a release, we think it would not be fair on the remaining 2 mentors to take the full burden of responsibility. Therefore we would like to ask the Incubator PMC if anyone would be interested in becoming an active mentor of Taverna as we enter this exciting phase? About Taverna: http://taverna.incubator.apache.org/ Taverna is a domain-independent suite of tools used to design and execute data-driven workflows, which invoke a mixture of local and remote (REST, WSDL) services. Taverna is used by scientists and researchers in domains like bioinformatics, chemistry, musicology, biodiversity and virtual physiology to combine and process data from multiple sources using a wide variety of analytical tools. Taverna workflows can be designed in a graphical workbench, programmatically through the Taverna Language API, or using an RDF/JSON-based workflow format. They can be executed locally (command line, within workbench or through OSGi-based APIs), or on a Taverna server (REST/WSDL), which has been integrated by portals and frontends, including an Android mobile app. Taverna results include full provenance trace of the execution as we strive to support reproducible computational research. This is an exciting time for us, as we are not just releasing version 3 of Taverna, but also working on a Common Workflow Language integration (YaML), including support for coordinating Docker-based command line tools. We rely on a large selection of Apache tools, like Woden, Felix, Jena, Derby, Tika, Velocity, Commons, HTTP Client and Maven. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] $podling.apache.org is the same as $podling.incubator.apache.org
+1 (binding) Andy On 28/06/16 15:28, John D. Ament wrote: All, Its been discussed a few times, and I'd like to provide clear feedback to the infra team on how to implement going forward. Typically, the addresses $podling.apache.org and $ podling.incubator.apache.org work, and have worked for a while. This is a call to vote on whether the IPMC agrees to this or not. If they do, I will ask infra to further clean this up, as DNS seems to be an issue at times for podlings. The benefit is that for SEO, the website URL does not change. I'm going to leave this open for 72 hours, at least and hope for some binding votes on this subject. [+1] I want the two URLs to both work the same. [+/- 0] Don't care [-1] I want the $podling.incubator.apache.org URL to be the one that works, including emails. John - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Is the incubator full?
On 25/08/16 07:34, Sergio Fernández wrote: > I think you may be seeing signs of self-throttling. Basically if the > new proposal > comes in and there's nobody interested in mentoring it -- well the project > won't > go in. Well, that just 1% of the work. Every body could easily volunteer for mentoring; most os the work at that phase is done by the champion. But what really requires time is actually mentoring the podling. My feeling is (I have no figures) that is most of our current podling we have just 1-2 active mentors. That would be another way to look to that detail. That agrees with my experience. A commitment to mentoring for 2 or more years is substantial. My experience has been that mentors fade away for all the obvious reasons of volunteers+(lack of)time. Signing up to mentor is the easy part and everyone is well-intentioned. So is the incubator full? No, but it needs to be careful about the nature of the set of mentors. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
On 03/08/17 05:13, Roman Shaposhnik wrote: On Wed, Aug 2, 2017 at 6:13 PM, John D. Amentwrote: On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik wrote: On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari wrote: Hi all, In regards to the recently incubated project - Gobblin, we were wondering about the policy around renaming Java package names to org.apache.* Is it a mandatory requirement or good to have? The reason to ask this is that while we see many projects have migrated to use org.apache.* package name for their Java source files, the Kafka project uses kafka.* for Scala sources and org.apache.kafka.* for Java sources. Please let us know as soon as possible, because we are in process of renaming the packages but if not mandatory we would want to keep gobblin.* package name and avoid the cost of downstream migrations and backwards incompatibility. You don't have to do it right away, but it is a requirement unless you have a really, really, really good reason of why you can't do that. I'm not aware of any requirement around Java package naming. IN fact, last time it came up it was clear that its a best practice only, and doesn't have any actual naming requirements. I'm not a policy wonk, but for every single podling I've witnessed this has been a very strong bias to be in o.a namespace. Speaking as an IPMC member I would like to see new projects migrate into o.a namespace unless there's a really good reason not to. Or to put it another way, if you want to avoid threads like this one: http://markmail.org/message/2bsrtgckuuihhnv4 during your graduation VOTE -- it is better to think about rename now. Jena was in a similar position with the main APIs under non o.a package spaces. We waited until a major version came along and that was several years after graduation. While it had always been the intent to change, we could see that there was going to be major version hop due to othe factors and we didn't want to do it twice. We did move non-API code under o.a much earlier on an piecemeal basis. Jena users also have data with URI naming based on host names from our origins in HP. We have not moved those to a.o names but encourage migration though outputting some warnings when it is encountered and can easily changed. I think it sends a positive signal to new contributors to make the package change but it isn't always practical to do so by graduation. The user community is already impacted by moving the mailing lists and web sites etc. For JVM-related projects, the maven coordinates change on entering incubation. That is a strong enough signal. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
On 03/08/17 15:51, Julian Hyde wrote: It rarely comes down to the IPMC or the Board dictating how a project names its java classes (does anyone recall an instance?), so it’s mainly the project’s discretion. In my opinion, where the project is on its adoption curve is an important consideration. +1 Most projects that enter the incubator are early on the adoption curve. Their future users outnumber their current users. The earlier these projects make the change to org.apache, the fewer people they will ultimately impact. It seems that gobblin is in this category. A few projects, such as Flex, are already near the top of their adoption curve. The cost/benefit of renaming is not as compelling. Jena was not early on the adoption curve. Long term compatibility has been, and is, a major element of the project culture. Importantly, there are active users who answer questions (here, elsewhere), external web tutorials, books etc referring to the pre-ASF API. We have a responsibility to them as well. "add an API" is more stuff that a small set of volunteer contributors (Jena has had no paid contributors working on) could not have coped with. If a project has the capacity, sure. Not all project will. Set the expectations too high and it is implicitly a filter for a certain kind of project in size and structure. Andy Julian On Aug 3, 2017, at 7:37 AM, Alex Haruiwrote: From the peanut gallery: Does the PPMC get to decide what constitutes a "very good reason" or does the IPMC and after graduation, the board? Flex has not changed its packages in the 5 years at Apache. We felt backward compatibility was and is a "very good reason". It was way more important to not require folks to alter their code in order to move to the Apache versions of Flex. Also, we are not using Java/Maven so there isn't really a shading option. On the other hand, it seems like it could be confusing for Apache projects to have packages starting with "com.". Flex's packages start with "mx" or "spark" (the component set names). Seems like a more refined guidance would be that: 1) packages starting with "com" (and maybe org.somethingOtherThanApache) should be changed as soon as possible/practical 2) there is no recommendation for other package prefixes My 2 cents, -Alex On 8/3/17, 5:42 AM, "Shane Curcuru" > wrote: John D. Ament wrote on 8/2/17 9:13 PM: On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik wrote: On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari wrote: Hi all, In regards to the recently incubated project - Gobblin, we were wondering about the policy around renaming Java package names to org.apache.* Is it a mandatory requirement or good to have? The reason to ask this is that while we see many projects have migrated to use org.apache.* package name for their Java source files, the Kafka project uses kafka.* for Scala sources and org.apache.kafka.* for Java sources. Please let us know as soon as possible, because we are in process of renaming the packages but if not mandatory we would want to keep gobblin.* package name and avoid the cost of downstream migrations and backwards incompatibility. You don't have to do it right away, but it is a requirement unless you have a really, really, really good reason of why you can't do that. I'm not aware of any requirement around Java package naming. IN fact, last time it came up it was clear that its a best practice only, and doesn't have any actual naming requirements. John: Do you have a link to that discussion? I'm of the mind that it's an expected best practice, unless you have a really, really good reason otherwise. Abhishek: Can you describe in more detail what these packages do in the context of your software product? In general, yes, I'd echo Roman's point strongly for the primary external API that most users would call: Or to put it a different way: during your eventual graduation this question will be asked and you better have a really, really good explanation if you're still using something other than o.a. That is, supporting packages, or things that are standards, or things that are specific plugins that integrate with external code - those I could understand staying with a non-a.o package name for compatibility or other reasons. But the main program that users run in the JVM, or the primary Gobblin classes that users integrating the code into their application? That should be in an org.apache.gobblin.* package. Simple "backwards compatibility for users" as an argument is only suitable if you're deprecating and have a plan to switch in the reasonably-near future after graduation. Not for the long term. Thanks for raising the question early! Thanks, Roman. -- - Shane https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach
Re: Urgent: Regarding Java package name change to org.apache.*
On 03/08/17 23:20, John D. Ament wrote: Which must's do you see greg? On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tras...@stratuscom.com> wrote: Does this actually need to be policy? What’s the harm to the foundation if a project continues to use a non-Apache package name, assuming that the code was donated appropriately? >>> 1) package names with reverse domains MUST be renamed >>> before graduation or have an IPMC approved plan for renaming SHOULD (i.e. it needs a justification but isn't absolutely prohibited) >>> 2) Projects who expect that their future users outnumber >>> current users are highly encouraged to rename packages +1 >>> 3) Other projects are not required to rename packages and >>> backward compatibility is sufficient reason to not rename packages. So there seem to be several cases: Donated names should be fine. (What about Maven coordinates here?) .com really ought to migrate at the first convenient moment. Non-donated, non-".com", less pressure but ought to migrate. (Maven coordinates MUST change on entering the incubator.) Andy Certainly, it should be a goal for all projects to use o.a.* package names, but if you look around the Foundation’s projects, you’re probably going to find lots of non-o.a.* packages. So it seems like this is another case of “Incubator has one (sort-of) policy, while the rest of the Foundation does its own thing” cases. And that being the case, it seems like an unreasonable imposition on podlings. I’d suggest taking out the MUSTs wherever possible, and having mentors make “should”, or maybe even “oughta” recommendations. Apache is already seen as unfriendly enough to podlings. Cheers, Greg. On Aug 3, 2017, at 12:34 PM, John D. Ament <johndam...@apache.org> wrote: One caveat - if your packages are "com.theoldcompany.someproject" they should be renamed to "org.apache.someproject" before graduation. If you have "org.someproject" already or just "someproject" as your package names, that's not a naming issue so I don't see that ever blocking graduation. John On Thu, Aug 3, 2017 at 12:25 PM Alex Harui <aha...@adobe.com.invalid> wrote: OK, so to summarize a more refined recommendation: 1) package names with reverse domains MUST be renamed before graduation or have an IPMC approved plan for renaming 2) Projects who expect that their future users outnumber current users are highly encouraged to rename packages 3) Other projects are not required to rename packages and backward compatibility is sufficient reason to not rename packages. Or should #2 also be a MUST? -Alex On 8/3/17, 8:34 AM, "Andy Seaborne" <a...@apache.org> wrote: On 03/08/17 15:51, Julian Hyde wrote: It rarely comes down to the IPMC or the Board dictating how a project names its java classes (does anyone recall an instance?), so it’s mainly the project’s discretion. In my opinion, where the project is on its adoption curve is an important consideration. +1 Most projects that enter the incubator are early on the adoption curve. Their future users outnumber their current users. The earlier these projects make the change to org.apache, the fewer people they will ultimately impact. It seems that gobblin is in this category. A few projects, such as Flex, are already near the top of their adoption curve. The cost/benefit of renaming is not as compelling. Jena was not early on the adoption curve. Long term compatibility has been, and is, a major element of the project culture. Importantly, there are active users who answer questions (here, elsewhere), external web tutorials, books etc referring to the pre-ASF API. We have a responsibility to them as well. "add an API" is more stuff that a small set of volunteer contributors (Jena has had no paid contributors working on) could not have coped with. If a project has the capacity, sure. Not all project will. Set the expectations too high and it is implicitly a filter for a certain kind of project in size and structure. Andy Julian On Aug 3, 2017, at 7:37 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: From the peanut gallery: Does the PPMC get to decide what constitutes a "very good reason" or does the IPMC and after graduation, the board? Flex has not changed its packages in the 5 years at Apache. We felt backward compatibility was and is a "very good reason". It was way more important to not require folks to alter their code in order to move to the Apache versions of Flex. Also, we are not using Java/Maven so there isn't really a shading option. On the other hand, it seems like it could be confusing for Apache projects to have packages starting with "com.". Flex's packages start with "mx" or "spark" (the component set names). Seems like a more refined guidance would
Re: Granting access to Jenkins
Done On 28/06/17 10:26, Henri Yandell wrote: Could a PMC Chair type person grant access to Jenkins for Ly please (login lxn2)? https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount I gave it a shot, but I don't believe I have the correct permissions. Thank you, Hen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
On 04/08/17 13:09, Shane Curcuru wrote: John D. Ament wrote on 8/4/17 7:59 AM: On Fri, Aug 4, 2017 at 7:17 AM Shane Curcuruwrote: ...snip... - Other reverse domain names *really* should change to org.apache; otherwise it's just confusing. Agreed. The one caveat to all this is the implementation of javax. namespace which is typically required and managed by the Geronimo TLP (typically). ...snip... Good point - any package names where there's a well-known technical standard that specifies package names takes precedence for naming. That's what a normal user would expect, and they also (typically) understand there's a difference between the standard API names and the actual implementation of the API they've downloaded. We seem to have lost the community impact. Projects with a existing pre-ASF history can have a halo of support in tutorials, books, etc (not from the donating corp) that all contribute to the success of a project. The principle that the project outputs come from Apache can be achieved in various ways. State the principle not the mechanism. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Taverna Language 0.16.0-incubating RC1
bcc: dev@taverna +1 (binding) Source downloaded,built (java8 - fails on java10; the podling is aware of this) and tests pass. Checksum and sigs verified DISCLIAMER, LICENSE and NOTICE present. --- The POM parent (separate release) includes other maven repos https://dl.bintray.com/ https://repo.spring.io/ https://jcenter.bintray.com/ but I'm told everything is in maven central. Raised TAVERNA-1051. Andy On 21/05/18 10:57, Stian Soiland-Reyes wrote: The Taverna PPMC has voted to release: Apache Taverna Language 0.16.0-incubating with +4 PPMC-binding votes. This email is the IPMC vote. Vote thread: https://lists.apache.org/thread.html/29405e13efcd3282e978982c2c4c02b1d1bf683460ce618c7248617a@%3Cdev.taverna.apache.org%3E Result: https://lists.apache.org/thread.html/6c30d76520c2e933c4b93db7dc87cef42f2d34871f0b6f334020d451@%3Cdev.taverna.apache.org%3E This carries forward one +1 IPMC binding vote from myself. Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2), Research Object Bundles and workflow inputs/outputs/run (DataBundle), as consumed and produced by the Apache Taverna workflow system. The API includes support for the legacy formats from Taverna 2 and Taverna 1, and can be also used independently of Apache Taverna 3. The command line tool tavlang can be used for conversion and inspection of research objects and workflow bundles. The release candidate to be voted over is available at: https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.16.0-incubating-RC1/ Checksums: $ sha1sum *zip 1f6050994b4bd2661f343119cdcb18b83dc362cf apache-taverna-language-0.16.0-incubating-source-release.zip $ sha256sum *zip bcdba80fbea54b1532cb81b6846e5711f1efe98ad289ecd4a2c6dd2833767115 apache-taverna-language-0.16.0-incubating-source-release.zip $ sha512sum *zip 008672c7f7cb1e6e461a2d5113aa111208970cfe9e0b3507fb3a34bc95957db094f0d8e8829beca9496cfa6a6d023943409335839bacd0bdedc82db87d14b9aa apache-taverna-language-0.16.0-incubating-source-release.zip s Build the release candidate using: mvn clean install The release candidates correspond to the following git commit: https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=c48ef9d339d7d68791691617ef2ddc56d195131e The release candidate is signed with an (updated) GPG key: https://www.apache.org/dist/incubator/taverna/KEYS A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachetaverna-1019 The changelog for this release is available from JIRA: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334881=12318322 Please vote on releasing these packages as: Apache Taverna Language 0.16.0-incubating The vote is open for at least 72 hours and passes if a majority of at least three +1 Apache Incubator PMC votes are cast. [ ] +1 Release this package [ ] 0 I don't feel strongly about it, but don't object [ ] -1 Do not release this package because... Anyone can participate in testing and voting, not just IPMC members, please feel free to try out the release candidate and provide your votes! How to review a release? https://s.apache.org/review-release - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Poddlings length of time in the incubator
On 26/08/18 00:43, Justin Mclean wrote: Hi, Below is a list of podlings that have been in the incubator for more than 2 years. What can be done to encourage these projects along? Do they have missing mentors or need some other assistance? While not all podlings graduate in 2 years and may move towards graduation at different rates, I’m not sure that the being in the incubator for longer than 2 years achieves much. Looking like they are soon to graduate: Airflow Singa Unomi Reasonably active: Gearpump S2Graph Tamaya Taverna Tephra Toree Little or low activity: BatchEE Edgent Joshua Milagro Myriad ODF Toolkit Pony Mail Quickstep Rya Samoa SensSoft Possibly retirement? ODF toolkit (7 years in the incubator!) Retiring: Gossip There was some talk of BatchEE graduation ion their list but seems little activity. Could the mentors of that project follow up on that? Edgent has had little activity since IBM staff have left and I'm not sure what can be done there. Is there any reason that S2Graph, Taverna and Tephra are not closer to graduation? Taverna has had a decent uptick on the technical side driven by a successful GSoC. Energy from the PPMC is needed to make sure all code has been released, or at least passed licensing, (including moving other stuff out for now), then graduate. Andy Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Shut down unused/inactive incubator lists
+1 On 21/01/2019 00:11, sebb wrote: The following lists are all but inactive: announce@ Last post Jan 2008 android-interest@ Last post Mar 2011 dev@ - only general circulars jaxws-tck@ (private) Last post 2012 projects@ Last post Jul 2011 user@ - only general circulars I think they should be shut down. Please vote so an Infra Jira can be raised to shut them down. They can have a bounce message added to direct posters to general@/private@ as appropriate [ ] +1 [ ] -1 - give a reason please Please vote by end January 2019 Sebb. - 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: Font size on incubator site too small?
Or default to the user's choice of font family in the browser. On 28/11/2019 06:01, Dave Fisher wrote: Reading glasses will enlarge things for many of us. I’m certainly in favor a larger font, but please keep it serifed. Sent from my iPhone On Nov 27, 2019, at 11:48 PM, Ted Dunning wrote: The problem might just be that pixels are getting smaller. On Thu, Nov 28, 2019 at 12:15 AM Justin Mclean wrote: Hi, Is it just my old eyes or do other people also find the font size too small on the incubator site? While it does scale well and easy for a user to increase the size, have we set the default too small? This may of course depend on platform and browser use and I’ve not done any exhaustive checking, as the measurement is in px that may be the issue. The body text seem to be set to 14px, (which is 10.5pt and that should be in pt or ems not px) and 12pt (16px) is generally recommended as a minimum size. Thanks, Justin - 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