Re: [VOTE] Release Apache Marmotta 3.1.0-incubating
Hi, while the release artifacts look good to me, I had no luck with compiling the sources. I first tried with Java 1.6 and was informed that I would need Java 1.7. So I tried with 1.7 but now I am getting failures in some tests, namely in the Kiwi triplestore reasoner. I made a few trials, cleaned the Maven repo etc. but still no luck. I am building on a Linux Ubuntu based machine using the JDKs from Sun/Oracle. What are the system requirements for Marmotta to build fine? Best, - Fabian 2013/10/2 Olivier Lamy ol...@apache.org: +1 sources build fine. -- Olivier On Sep 30, 2013 8:17 PM, Sebastian Schaffert sschaff...@apache.org wrote: Dear all, After several months of work since the last incubating release (3.0.0-incubating) in April, we are now ready to release version 3.1.0-incubating. We fixed all the remaining issues that have been discussed in April (see thread [1]) plus many more technical issues. We have already held a vote that was open for more than 72 hours on the Apache Marmotta developer mailinglist [2]. The vote concluded [3] with 7 positive votes, of which 2 have been binding from IPMC members (Andy and Nandana) and the remaining 5 from the Apache Marmotta developers. I'd therefore like to ask the general incubator to check our release candidate. The release notes are available at the Jira Issue Tracker [4]. The vote form is included at the bottom of this mail. Greetings, Sebastian [1] http://apache.markmail.org/message/5tieelmeevi2j6xb [2] http://apache.markmail.org/message/lk3hc3jutoaxp6dr [3] http://apache.markmail.org/message/fvytzho2pnhasw2c [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314321version=12324026 === A candidate for the Marmotta 3.1.0-incubating release is available at: https://dist.apache.org/repos/dist/dev/incubator/marmotta/3.1.0-incubating/ The release candidate is based on the sources tagged with 3.1.0-incubating in: https://git-wip-us.apache.org/repos/asf/incubator-marmotta.git The release candidate consists of the following source distribution archives: - apache-marmotta-3.1.0- incubating-src.[zip|tar.gz] SHA1 of ZIP: 763c39dc9d7eb1c7d8fad83742b08f44b6fa5527 SHA1 of TGZ: 0f7f3395f22aeeaa4a402f1b08048c84899d9729 In addition, the following supplementary binary distributions are provided: - apache-marmotta-3.1.0-incubating-installer.[zip|tar.gz] SHA1 of ZIP: d7417a711a7f80eb29eb93ec75744a314fcf2edd SHA1 of TGZ: 4606fe743f607215dd4f3f39d8506852f529b617 - apache-marmotta-3.1.0-incubating-ldpath.[zip|tar.gz] SHA1 of ZIP: 4f4db937e0064a4393039b6fb8277be166a971ab SHA1 of TGZ: 5d63f972df2306afec96aa1a8931c4d0dabb2f75 - apache-marmotta-3.1.0-incubating-webapp.[zip|tar.gz] SHA1 of ZIP: e8e168a29e398cda9220a793958b825a906a3142 SHA1 of TGZ: 80d022d316e727b5f011069eec6dc9793b174838 A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachemarmotta-092/ Please vote on releasing this package as Apache Marmotta 3.1.0-incubating. The vote is open for the next 72 hours and passes if a majority of at least three +1 Marmotta PMC votes are cast. [ ] +1 Release this package as Apache Marmotta 3.1.0-incubating [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... === Release Notes - Marmotta - Version 3.1-incubating ** Sub-task * [MARMOTTA-216] - Implement JOIN improvements * [MARMOTTA-217] - Implement FILTER improvements * [MARMOTTA-218] - Integrate in marmotta-sparql ** Bug * [MARMOTTA-28] - Implement tests for core that take into account triple store changes * [MARMOTTA-63] - Triplestore: garbage collector for nodes currently not working properly * [MARMOTTA-66] - Rework sesame-commons ResourceUtils * [MARMOTTA-143] - unable to import big files * [MARMOTTA-150] - BNodes are a dead end in the Linked Data Explorer * [MARMOTTA-154] - Youtube video provider doesn't fetch the keywords * [MARMOTTA-155] - 3-char lang-tags are not accepted * [MARMOTTA-156] - Add Logback configuration to all tests to enable/disable debug logging * [MARMOTTA-170] - file-store (meta) for ldcache-backend-file contains wrong comments * [MARMOTTA-171] - remove legacy subdirs from src/main/webapp in marmotta-webapp * [MARMOTTA-186] - LDPath parser fails on local names that contain '.' * [MARMOTTA-187] - ldpath extension for CM does not recognize local names with '.' or '-' * [MARMOTTA-191] - SPARQL graph results fails under some circunstances * [MARMOTTA-197] - ldpath is loosing brackets on re-serialisation * [MARMOTTA-204] - Update to Sesame 2.7.1 * [MARMOTTA-205] - Turtle-Exports do not contain any language tags * [MARMOTTA-206] - Strictly follow the standard formatting on
Re: [DISCUSS] [PROPOSAL] Apache Monitoring
+1, sounds good On Wed, Oct 2, 2013 at 4:31 AM, Olivier Lamy ol...@apache.org wrote: So Apache Merlin sounds good to me. Any objections? On 25 September 2013 23:47, Christian Grobmeier grobme...@gmail.com wrote: Nechtan sounds cool also. Please note, in the german wikipedia its translated with The tremendousness. This is not noted on the english wikipedia. After reading wikipedia I am still not sure what Nechtan stands for. But I like its sound. I just found Sirona, goddess of healing. Because monitoring is identifying the sickness before its getting worse. However, Sirona is used by companies related to healing (aka dental works). What I found interesting is this page claims Merlin being a god: http://wicca.com/celtic/wicca/celtic.htm of protecting, counseling, crystal reading and so. A few projects use Merlin, but all are very small ant not related to monitoring. There is a project management software called marlin: http://www.projectwizards.net/de/merlin/ I believe we currently have: Apache Leitstand Apache Nechtan Apache Merlin Apache Sirona Apache Heimdall Apache Dagr Cheers On 25 Sep 2013, at 15:03, Stephen Connolly wrote: Why not try Celtic mythology I was thinking Apache Nechtan due to the association with access to knowledge and floods... but heck I am not good on my Irish mythology and the Norse ones always sounded way cooler On 25 September 2013 13:23, Christian Grobmeier grobme...@gmail.com wrote: I also see thor is being used by infra: status.apache.org (mentioning, because it has been proposed as name too). However, it's not so bad. I actually mixed up Baldur with Heimdall, who is the actual protector of Bifröst. Baldur was more known because he was able to return from Hel (sounds like a good name for a server ;-) A quick crosscheck told me Heimdall is not used that often. For those who were concerned about using nordic godnames: Heimdall was named as the father of all humans. He was also known for his horn Gjallarhorn which he blew when danger appeared. Most notable he blew that horn when Ragnarökr (the end of our time and the fall of the gods) starts. I imagine the sound of a horn when critical notification of the tool happens ;-) Another idea i just had was Dagr. It old norsk for Day. In old myths Dagr is the son of night and he rides his horse Skinfaxi through heaven. The crest of the horse lights the earth with golden shimmer. I imagine Apache Dagr to shed light on the dark corners of our applications. Heck, when I was young i read a lot about northern mythology. Its so poetic. I should spend some time to read again. On 25 Sep 2013, at 10:19, Daniel Gruno wrote: On 09/25/2013 09:21 AM, Tammo van Lessen wrote: Baldr is fine with me, my only concern is the similarity to Apache Buildr. Just a heads up from infra; baldr.apache.org is already very much a thing, and has been for more than five years. If it can be avoided, we'd really appreciate it if we can keep the name Baldr for our infrastructure. With regards, Daniel. Tammo Am 25.09.2013 01:18 schrieb Olivier Lamy ol...@apache.org: So what about Baldr? BTW we can start incubation using Monitoring then change the name for TLP? WDYT? On 21 September 2013 06:30, Christian Grobmeier grobme...@gmail.com wrote: I would like to throw in this document: http://www.apache.org/**foundation/marks/naming.html http://www.apache.org/foundation/marks/naming.html We should make a few tests already before we start the process officially. here is the current list, i felt so free to add a few comments already. - CoMon There is Common Software, a company. We might have a trademarks problem because of similarity. - Leitstand Not sure if I like the sound :-), but did not find any repositories at github. From the meaning, a Leitstand is usually something were you can adjust things (more power, less steam and so on). Monitoring would be only a part of it. But on the other hand, it expresses things well and it is a unused word so far. - Thor Great name, great god, but unfortunately a lot of people use that name for their code :-( - Balder / Baldur, also possible: Baldr I haven't see a lot with that name, but we need to check this more in detail. From that perspective, Leitstand would be the best catch from a unique point of view. I like Baldr very much from that meaning. Lets see if there are more names the next days. Romain Manni-Bucau schrieb: Why not CoMon? Remind commons monitoring, that's fun and closer to english so easier to propagate IMO. Le 20 sept. 2013 12:59, Jean-Baptiste Onofré j...@nanthrax.net a écrit : I like the Apache Leitstand name. Regards JB On 09/20/2013 09:51 AM, Tammo van Lessen
Re: [VOTE] Release Apache Marmotta 3.1.0-incubating
Hi On 04/10/13 16:06, Fabian Christ wrote: while the release artifacts look good to me, I had no luck with compiling the sources. I first tried with Java 1.6 and was informed that I would need Java 1.7. So I tried with 1.7 but now I am getting failures in some tests, namely in the Kiwi triplestore reasoner. I made a few trials, cleaned the Maven repo etc. but still no luck. I am building on a Linux Ubuntu based machine using the JDKs from Sun/Oracle. That's weird... What are the system requirements for Marmotta to build fine? Basically Maven 3 and JDK 7, that's it. Please, provide more details at dev@marmotta.i.a.o in other to find the source of your issues. Thanks. -- Sergio Fernández Salzburg Research +43 662 2288 318 Jakob-Haringer Strasse 5/II A-5020 Salzburg (Austria) http://www.salzburgresearch.at - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
OK, here is my next offering. The patch form is at [1] Some notes: -This offering has 3 new entries to glossary.html as well. -I was very tempted to move the Veto sections from Voting.html to Glossary and merge the Consensus Gauging through Silence section from Voting into Glossary. -I am also tempted to remove the empty section about Procedural Votes or Opinion Polls but I know you folks are looking for the minimum set of changes. -There are some sentences in Voting I'm not sure are accurate such as: 1) and all others are either discouraged from voting 2) procedural votes from developers and committers are sometimes considered binding... 3) Only votes by PMC members are considered binding on code-modification issues For #3, Can committers who are not PMC members have veto a code change? Thanks, -Alex [1] https://paste.apache.org/9uhY voting.mdtext Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Because one of the fundamental aspects of accomplishing things within the Apache framework is doing so by consensus, there obviously needs to be a way to tell whether it has been reached. This is done by voting. There are essentially five types of vote: 1. Code modifications (including voting to accept new code donations) 1. Package releases 1. Approving people (as Committer, PMC Member, PMC Chair) 1. Removing people (as Committer or PMC Member) 1. Procedural (including approval of project bylaws) Votes on procedural issues follow the common format of [majority approval](glossary.html#MajorityApproval) unless otherwise stated. That is, if there are more favourable votes than unfavourable ones, the issue is considered to have passed -- regardless of the number of votes in each category. (If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. However, see the description of [lazy consensus](#LazyConsensus) for a modifying factor.) Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a [veto](#Veto) , which cannot be overridden. Again, this model may be modified by a [lazy consensus](#LazyConsensus) declaration when the request for a vote is raised, but the full-stop nature of a negative vote is unchanged. Under normal (non-lazy consensus) conditions, the proposal requires three positive votes and no negative ones in order to pass; if it fails to garner the requisite amount of support, it doesn't -- and typically is either withdrawn, modified, or simply allowed to languish as an open issue until someone gets around to removing it. Votes on whether a package is ready to be released or not use yet a different mechanism: are there are least three binding votes in favour of the release? See more about this [below](#ReleaseVotes). Votes on approving people require [consensus approval](glossary.html#ConsensusApproval) approval. Votes on removing people require [consensus-but-one](glossary.html#ConsensusButOne). The voting process for adding people, removing people and procedural voting may be modified and further refined by project bylaws. If a project's bylaws do not specify an alternative voting process then the above process is assumed to apply. # Binding Votes # Who is permitted to vote is, to some extent, a community-specific thing. However, the basic rule is that only PMC members have binding votes, and all others are either discouraged from voting (to keep the noise down) or else have their votes considered of an indicative or advisory nature only. Unless otherwise specified by a project's bylaws, only [active members)(glossary.html#ActiveMembers) who have been active in the last 6 months may cast binding votes. A different definition of active member may also be set in a project's bylaws. That's the general rule. In actual fact, things tend to be a little looser, and procedural votes from developers and committers are sometimes considered binding if the voter has acquired enough merit and respect in the community. Only votes by PMC members are considered
Re: Apache project bylaws
IMO none of the new glossary entries are worth doing. Procedural votes are votes about bylaws and other rules which you will apply to self-govern, so they deserve an appropriate treatment. Discouraged from voting is perhaps too harsh a sentiment, what we want those people to know is their opinion carries no *formal* weight. Procedural votes are really reserved for PMC members, and it really doesn't make sense to comment that other voters sometimes hold binding votes here- that's something bylaws need to address if that sort of thing is desired. Code vetoes, or in fact vetoes of any kind, by default are reserved for PMC members, but again bylaws can change that. HTH On Oct 4, 2013, at 12:55 PM, Alex Harui aha...@adobe.com wrote: OK, here is my next offering. The patch form is at [1] Some notes: -This offering has 3 new entries to glossary.html as well. -I was very tempted to move the Veto sections from Voting.html to Glossary and merge the Consensus Gauging through Silence section from Voting into Glossary. -I am also tempted to remove the empty section about Procedural Votes or Opinion Polls but I know you folks are looking for the minimum set of changes. -There are some sentences in Voting I'm not sure are accurate such as: 1) and all others are either discouraged from voting 2) procedural votes from developers and committers are sometimes considered binding... 3) Only votes by PMC members are considered binding on code-modification issues For #3, Can committers who are not PMC members have veto a code change? Thanks, -Alex [1] https://paste.apache.org/9uhY voting.mdtext Title: Apache Voting Process Notice:Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at . http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. Because one of the fundamental aspects of accomplishing things within the Apache framework is doing so by consensus, there obviously needs to be a way to tell whether it has been reached. This is done by voting. There are essentially five types of vote: 1. Code modifications (including voting to accept new code donations) 1. Package releases 1. Approving people (as Committer, PMC Member, PMC Chair) 1. Removing people (as Committer or PMC Member) 1. Procedural (including approval of project bylaws) Votes on procedural issues follow the common format of [majority approval](glossary.html#MajorityApproval) unless otherwise stated. That is, if there are more favourable votes than unfavourable ones, the issue is considered to have passed -- regardless of the number of votes in each category. (If the number of votes seems too small to be representative of a community consensus, the issue is typically not pursued. However, see the description of [lazy consensus](#LazyConsensus) for a modifying factor.) Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a [veto](#Veto) , which cannot be overridden. Again, this model may be modified by a [lazy consensus](#LazyConsensus) declaration when the request for a vote is raised, but the full-stop nature of a negative vote is unchanged. Under normal (non-lazy consensus) conditions, the proposal requires three positive votes and no negative ones in order to pass; if it fails to garner the requisite amount of support, it doesn't -- and typically is either withdrawn, modified, or simply allowed to languish as an open issue until someone gets around to removing it. Votes on whether a package is ready to be released or not use yet a different mechanism: are there are least three binding votes in favour of the release? See more about this [below](#ReleaseVotes). Votes on approving people require [consensus approval](glossary.html#ConsensusApproval) approval. Votes on removing people require [consensus-but-one](glossary.html#ConsensusButOne). The voting process for adding people, removing people and procedural voting may be modified and further refined by project bylaws. If a project's bylaws do not specify an alternative voting process then the above process is assumed to apply. # Binding Votes #
request edit rights for incubator wiki
Hi all I need edit right on the incubator wiki for shepherding. Or should I send my notice to the ML? Thanks and greetings Raphael - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: request edit rights for incubator wiki
On Fri, Oct 4, 2013 at 12:18 PM, Raphael Bircher r.birc...@gmx.ch wrote: I need edit right on the incubator wiki for shepherding. Please let us know your login for the Incubator wiki. (Not your apache id.) Or should I send my notice to the ML? On Monday, I plan to extract all the shepherd comments from this month's report and send them to general@incubator in one bunch -- so filing your report on the wiki is best as it will go both to the board and to the mailing list without further ado. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: request edit rights for incubator wiki
Am 04.10.13 21:30, schrieb Marvin Humphrey: On Fri, Oct 4, 2013 at 12:18 PM, Raphael Bircher r.birc...@gmx.ch wrote: I need edit right on the incubator wiki for shepherding. Please let us know your login for the Incubator wiki. (Not your apache id.) It's the same: rbircher Or should I send my notice to the ML? On Monday, I plan to extract all the shepherd comments from this month's report and send them to general@incubator in one bunch -- so filing your report on the wiki is best as it will go both to the board and to the mailing list without further ado. 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
Re: Apache project bylaws
On Oct 3, 2013 12:52 PM, Joseph Schaefer joe_schae...@yahoo.com wrote: ... e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, Really, Joe? Why did you throw that in? I know what consensus voting is. I also know some PMCs allow vetoes when adding new members. That was the point of my prior email: you are right that committership is done by consensus across the ASF, but that doesn't strictly hold for PMC membership. I think Roy phrased it once as I am allowed to veto/refuse to work with that person. They are free to copy the codebase and establish a community of people willing to work with that person. Cheers, -g
Re: request edit rights for incubator wiki
On Fri, Oct 4, 2013 at 12:32 PM, Raphael Bircher r.birc...@gmx.ch wrote: Am 04.10.13 21:30, schrieb Marvin Humphrey: On Fri, Oct 4, 2013 at 12:18 PM, Raphael Bircher r.birc...@gmx.ch wrote: I need edit right on the incubator wiki for shepherding. Please let us know your login for the Incubator wiki. (Not your apache id.) It's the same: rbircher Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
Really, Greg? Can't you tell you're not using the same language I am, but I'm using the actual documentation? Please see http://www.apache.org/foundation/glossary#ConsensusApproval and see how it jives with what you are saying. Personnel votes are always subject to veto, even committership, when we're talking about the httpd project. On Oct 4, 2013, at 3:47 PM, Greg Stein gst...@gmail.com wrote: On Oct 3, 2013 12:52 PM, Joseph Schaefer joe_schae...@yahoo.com wrote: ... e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, Really, Joe? Why did you throw that in? I know what consensus voting is. I also know some PMCs allow vetoes when adding new members. That was the point of my prior email: you are right that committership is done by consensus across the ASF, but that doesn't strictly hold for PMC membership. I think Roy phrased it once as I am allowed to veto/refuse to work with that person. They are free to copy the codebase and establish a community of people willing to work with that person. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
Adjusting the email Subject to [RESULT][VOTE] ... to enable the voting status monitor: http://incubator.apache.org/facilities.html#voting-status -David Dave wrote: I am officially closing the vote. We have 11 binding +1 votes, 4 non-binding votes and no -1 notes. Usergrid is now officially part of the Apache Incubator. Thanks to everybody who helped put together the proposal, those who joined the discussion, those who voted and the Usergrid community. +1 binding votes Afkham Azeez Alan D. Cabrera Alex Karasulu Ate Douma Bertrand Delacretaz Chip Childers David Nalley Henry Saputra Jim Jagielski Luciano Resende Marvin Humphrey +1 non-binding Larry McCay Lewis John Mcgibbney Lieven Govaerts Raminder Singh Totals 11 binding +1 votes 4 non-binding +1 votes 0 -1 votes Thanks, Dave PS. this also happens to be the 2nd anniversary of the day that Usergrid was released on Github. Happy Birthday Usergrid! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal)
Hi David, Just an FYI I also VOTEd +1 on this. Congrats and good luck! Cheers, Chris -Original Message- From: David Crossley cross...@apache.org Reply-To: general@incubator.apache.org general@incubator.apache.org Date: Friday, October 4, 2013 5:08 PM To: general@incubator.apache.org general@incubator.apache.org Subject: [RESULT][VOTE] Usergrid BaaS Stack for Apache Incubator (revised proposal) Adjusting the email Subject to [RESULT][VOTE] ... to enable the voting status monitor: http://incubator.apache.org/facilities.html#voting-status -David Dave wrote: I am officially closing the vote. We have 11 binding +1 votes, 4 non-binding votes and no -1 notes. Usergrid is now officially part of the Apache Incubator. Thanks to everybody who helped put together the proposal, those who joined the discussion, those who voted and the Usergrid community. +1 binding votes Afkham Azeez Alan D. Cabrera Alex Karasulu Ate Douma Bertrand Delacretaz Chip Childers David Nalley Henry Saputra Jim Jagielski Luciano Resende Marvin Humphrey +1 non-binding Larry McCay Lewis John Mcgibbney Lieven Govaerts Raminder Singh Totals 11 binding +1 votes 4 non-binding +1 votes 0 -1 votes Thanks, Dave PS. this also happens to be the 2nd anniversary of the day that Usergrid was released on Github. Happy Birthday Usergrid! - 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
