[VOTE] TinkerPop 3.1.0-incubating Release
Hello, We are happy to announce that TinkerPop 3.1.0-incubating is ready for release. The release artifacts can be found at this location: https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/3.1.0-incubating/ The source distribution is provided by: apache-tinkerpop-3.1.0-incubating-src.zip Two binary distributions are provided for user convenience: apache-gremlin-console-3.1.0-incubating-bin.zip apache-gremlin-server-3.1.0-incubating-bin.zip The GPG key used to sign the release artifacts is available at: https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/KEYS The online docs can be found here: http://tinkerpop.incubator.apache.org/docs/3.1.0-incubating/ (user docs) http://tinkerpop.incubator.apache.org/docs/3.1.0-incubating/upgrade.html#_tinkerpop_3_1_0 (upgrade docs) http://tinkerpop.incubator.apache.org/javadocs/3.1.0-incubating/core/ (core javadoc) http://tinkerpop.incubator.apache.org/javadocs/3.1.0-incubating/full/ (full javadoc) The tag in Apache Git can be found here: https://git-wip-us.apache.org/repos/asf?p=incubator-tinkerpop.git;a=tag;h=310d0cda0c5ac83f47d173aaa4cf2ec51a47e636 The release notes are available here: https://github.com/apache/incubator-tinkerpop/blob/3.1.0-incubating/CHANGELOG.asciidoc#tinkerpop-310-release-date-november-16-2015 Finally, the dev@tinkerpop [VOTE] thread can be found at this location: https://pony-poc.apache.org/thread.html/Zea70rxds8l66xj Result summary: +14 (4 binding, 10 non-binding), 0 (0), -1 (0) The [VOTE] will be open for the next 72 hours --- closing Monday (November 23, 2015) at 5:00am EST. Thanks, Stephen
Re: Project Website Template
Generally pretty nice. This is clearly based on a Jekyll example from somewhere. That does raise the question Julian had about license. On Fri, Nov 20, 2015 at 9:49 AM, Julian Hyde wrote: > > > On Nov 19, 2015, at 5:42 PM, Luciano Resende > wrote: > > > > The strawman of the template is available in the newly created git > > repository > > https://git-wip-us.apache.org/repos/asf/apache-website-template.git > > > And mirrored at https://github.com/apache/apache-website-template < > https://github.com/apache/apache-website-template>, I see. It could use > LICENSE and NOTICE files (including appropriate remarks about the included > non-ASL files), a README, and headers on all files. I’ll start creating PRs > at github. > > Julian > >
Re: RTC vs CTR (was: Concerning Sentry...)
Lets recall that 'review' is not just about trust (or whether or not it exists), it's also about this little thing called *oversight*. It's to ensure that at least 3 people are engaged enough to be able to not only vet the code/patch/whatever, but to make sure that should the original patch provider drop out of sight, that there are enough people around to keep that code up-to-date. As Joe sez, this whole discussion seems weird to me. httpd (for example) uses RTC, CTR and Lazy Consensus simultaneously and works like a dream. And considering that httpd is pretty much the "standard" or "basis" for the Apache Way (or, at least one of the main ones), any suggestion that one of these methods is broken, or whatever, seems wonky. > On Nov 17, 2015, at 9:05 AM, Ted Dunning wrote: > > On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski wrote: > >> Certainly we need both a >> Review and a Commit and one must be done before the other, >> right? >> > > Well, not necessarily. We need a commit. The review is, strictly > speaking, optional. That means that the three choices are C, RTC, CTR. The > empty string is plausible, but implies a dead community. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
A combination approach seems like it would be the best to me. Is the process you guys use documented? As I said, the part that bothers me with the way RTC is done in the project I am involved in is that I can’t commit my own stuff. Ralph > On Nov 20, 2015, at 6:09 AM, Jim Jagielski wrote: > > Lets recall that 'review' is not just about trust (or whether > or not it exists), it's also about this little thing called > *oversight*. It's to ensure that at least 3 people are > engaged enough to be able to not only vet the code/patch/whatever, > but to make sure that should the original patch provider > drop out of sight, that there are enough people around to > keep that code up-to-date. > > As Joe sez, this whole discussion seems weird to me. httpd > (for example) uses RTC, CTR and Lazy Consensus simultaneously > and works like a dream. And considering that httpd is pretty > much the "standard" or "basis" for the Apache Way (or, at least > one of the main ones), any suggestion that one of these methods > is broken, or whatever, seems wonky. > >> On Nov 17, 2015, at 9:05 AM, Ted Dunning wrote: >> >> On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski wrote: >> >>> Certainly we need both a >>> Review and a Commit and one must be done before the other, >>> right? >>> >> >> Well, not necessarily. We need a commit. The review is, strictly >> speaking, optional. That means that the three choices are C, RTC, CTR. The >> empty string is plausible, but implies a dead community. > > > - > 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: RTC vs CTR (was: Concerning Sentry...)
> On Nov 20, 2015, at 9:02 AM, Ralph Goers wrote: > > A combination approach seems like it would be the best to me. Is the process > you guys use documented? > > As I said, the part that bothers me with the way RTC is done in the project I > am involved in is that I can’t commit my own stuff. > With many projects, the commit is actually a merge from a branch/tree which was under CTR, so history is maintained. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [graduation] Maturity model-based assessment of Groovy for its graduation
I’ll get right on creating one for Unomi, I’ve been wanting to use this since you first told me about it Bertrand :) cheers, Serge… > On 19 nov. 2015, at 20:33, Bertrand Delacretaz wrote: > > Hi, > > On Thu, Oct 15, 2015 at 5:46 AM, Bertrand Delacretaz > wrote: >> FYI I have started an experiment at >> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc , >> using our maturity model to evaluate Groovy... > > Groovy graduated now and doesn't have a good place to keep that > document, so I'm pasting it below in case other podlings want to use > it as an example. > > It will also stay at > > https://github.com/apache/incubator-groovy/blob/576b3c5d6a7022ac4a8df1ef118666456ce627fb/MATURITY.adoc > > -Bertrand > > GROOVY MATURITY * > > = Groovy Podling Maturity Assessment > > == Overview > > This is an assessment of the Groovy podling's maturity, meant to help inform > the decision (of the mentors, community, Incubator PMC and ASF Board of > Directors) to graduate it as a top-level Apache project. > > It is based on the ASF project maturity model at > https://community.apache.org/apache-way/apache-project-maturity-model.html > > Maintaining such a file is a new, experimental idea as part of the continuous > improvement of the ASF incubation process. Groovy is the first podling where > that happens. > > == Status of this document > All open items resolved, ready for PPMC approval voting. > > == Overall assessment > All the below items are marked OK, Groovy looks ready to graduate, > discussions and votes > are ongoing on the project's dev list as I write this (October 2015). > > == Maturity model assessment > Mentors and community members are encouraged to contribute to this > and comment on it. > > === Code > > CD10 > _The project produces Open Source software, for distribution to the > public at no charge._ > > OK: of course. > > CD20 > _The project's code is easily discoverable and publicly accessible._ > > OK: http://groovy-lang.org/ (see CO10) includes a "fork me on Github" banner. > > CD30 > _The code can be built in a reproducible way using widely available > standard tools._ > > OK: the build uses Gradle and continuous integration is used. > > CD40 > _The full history of the project's code is available via a source code > control system, in a way that allows any released version to be > recreated._ > > OK: Using Git, main repository at > https://git-wip-us.apache.org/repos/asf/incubator-groovy.git, releases > are cut > from that repository. > > CD50 > _The provenance of each line of code is established via the source > code control system, in a reliable way based on strong authentication > of the committer. > When third-party contributions are committed, commit messages provide > reliable information about the code provenance._ > > OK, see CD40 > > === Licenses and Copyright > > LC10 > _The code is released under the Apache License, version 2._0._ > > OK, LICENSE file has been accepted in release votes. > > LC20 > _Libraries that are mandatory dependencies of the project's code do > not create more restrictions than the Apache License does._ > > OK: The list of dependencies at > https://wiki.apache.org/incubator/GroovyProposal has been verified > when entering incubation. > > The current dependency licenses (including build, runtime and optional > dependencies) are found at > https://github.com/apache/incubator-groovy/tree/master/licenses > > Assembling the licenses depending on the artifacts is done here: > https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle > so that the various artifacts get their correct sets of licenses. > > Release reviews have not shown any incompatible licenses. > > LC30 > _The libraries mentioned in LC20 are available as Open Source software._ > > OK, see LC20 > > LC40 > _Committers are bound by an Individual Contributor Agreement (the > "Apache iCLA") that defines which code they are allowed to commit and > how they need to identify code that is not their own._ > > OK, all committers have iCLAs on file. > > LC50 > _The copyright ownership of everything that the project produces is > clearly defined and documented._ > > OK, obvious for an ASF project. > > === Releases > > RE10 > _Releases consist of source code, distributed using standard and open > archive formats that are expected to stay readable in the long term._ > > OK, verified in release votes. > > RE20 > _Releases are approved by the project's PMC (see CS10), in order to > make them an act of the Foundation._ > > OK, releases have been voted by the Incubator PMC. > > RE30 > _Releases are signed and/or distributed along with digests that can be > reliably used to validate the downloaded archives._ > > OK, verified in release votes. > > RE40 > _Convenience binaries can be distributed alongside source code but > they are not Apache Releases -- they
Re: RTC vs CTR (was: Concerning Sentry...)
On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski wrote: > ...httpd for example) uses RTC, CTR and Lazy Consensus > simultaneously and works like a dream Indeed - those are different tools that each have their own purpose. They just need to be applied in the right places and at the right time. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Project Website Template
On Friday, November 20, 2015, Ted Dunning wrote: > Generally pretty nice. > > This is clearly based on a Jekyll example from somewhere. That does raise > the question Julian had about license. > > Jekyll has the option to generate a basic site, and the style is mostly based on how Zepplin did their website I am in the process of adding license and notices and other ASF requirements > > On Fri, Nov 20, 2015 at 9:49 AM, Julian Hyde > wrote: > > > > > > On Nov 19, 2015, at 5:42 PM, Luciano Resende > > > wrote: > > > > > > The strawman of the template is available in the newly created git > > > repository > > > https://git-wip-us.apache.org/repos/asf/apache-website-template.git > > > > > > And mirrored at https://github.com/apache/apache-website-template < > > https://github.com/apache/apache-website-template>, I see. It could use > > LICENSE and NOTICE files (including appropriate remarks about the > included > > non-ASL files), a README, and headers on all files. I’ll start creating > PRs > > at github. > > > > Julian > > > > > -- Sent from my Mobile device
Re: [RESULT][VOTE] Accept Unomi into the Apache Incubator
Hi, On Mon, Oct 5, 2015 at 4:47 AM, Jean-Baptiste Onofré wrote: > ...I will continue with the bootstrap process to bring Unomi into Apache > incubator Unless I missed something I haven't seen more news about this here, but it looks like the Unomi lists have been created and discussions are now starting there: http://mail-archives.apache.org/mod_mbox/incubator-unomi-dev/ -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
++1 > On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz > wrote: > > On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski wrote: >> ...httpd for example) uses RTC, CTR and Lazy Consensus >> simultaneously and works like a dream > > Indeed - those are different tools that each have their own purpose. > They just need to be applied in the right places and at the right > time. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Accept Unomi into the Apache Incubator
Yes the resources have been created. We’ve been hard at work on creating the web site and working on the codebase to get it imported asap. Regards, Serge… > On 20 nov. 2015, at 15:42, Bertrand Delacretaz wrote: > > Hi, > > On Mon, Oct 5, 2015 at 4:47 AM, Jean-Baptiste Onofré > wrote: >> ...I will continue with the bootstrap process to bring Unomi into Apache >> incubator > > Unless I missed something I haven't seen more news about this here, > but it looks like the Unomi lists have been created and discussions > are now starting there: > > http://mail-archives.apache.org/mod_mbox/incubator-unomi-dev/ > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
+1 here too. Most projects here fall somewhere in a spectrum between "do whatever you want in a branch" and "don't release without having others approve your work". Different projects put the point where CTR crosses over to RTC at different points. *shrug* - Sam Ruby P.S. Personally a fan of CTR, but I'm starting to appreciate our infrastructure team's puppet workflow where everything (even one line changes) are done in a branch and everybody asks other person to merge the changes. https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski wrote: > ++1 >> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz >> wrote: >> >> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski wrote: >>> ...httpd for example) uses RTC, CTR and Lazy Consensus >>> simultaneously and works like a dream >> >> Indeed - those are different tools that each have their own purpose. >> They just need to be applied in the right places and at the right >> time. >> >> -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
[QUESTION] Rewriting history
Probably a bad subject in the context of other things going on :). Apache Brooklyn is faced with the tasks of migrating it's repo(s) post graduation and there are some very large *pre-incubation* artifacts in the git repo that we would like removed. The question was asked on general@ [1] many moons ago, but received no answer (the original thread [1] indicates the offenders). We'd like to use this occasion to split the git repo into multiple smaller once (more naturally tailored to the project), so one idea would be, I think, to leave incubator-brooklyn.git as is and just extract what we need (everything except the large binaries) in new repos. Note: afaiui, those artifacts we're never part of an ASF release. I am not sure what would be acceptable per ASF (intensely debated) policies. Thoughts? Hadrain [1] https://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201506.mbox/%3c556f0973.7030...@cloudsoftcorp.com%3E - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)
It looks like we have some copyright and licensing issue to resolved before completing our first release. So I am officially withdrawing our request for our first Apache Trafodion release. We will take a look at all the issues reported and submit a new package later. Again, thanks for all your valuable information. This is obviously an area we should have spent more time on before submitting. It has been, and will continue to be, and educational exercise for us. Regards, Roberta *From:* Alex Harui [mailto:aha...@adobe.com] *Sent:* Thursday, November 19, 2015 10:31 PM *To:* general@incubator.apache.org *Subject:* Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)
RE: RTC vs CTR (was: Concerning Sentry...)
Good point. I should add to my comments that even a CTR project uses RTC for non-committers. And that a release vote means that at least three people have reviewed the code from (at least) an IP standpoint, if not from a code quality standpoint. In other words, +1 However, RTC projects do not use a mix and that's the point of contention here, some people feel it is suboptimal (I'm one, but others disagree). The discussion is not whether CTR also uses RTC at points, I believe that is a given. Ross -Original Message- From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby Sent: Friday, November 20, 2015 7:43 AM To: general@incubator.apache.org Subject: Re: RTC vs CTR (was: Concerning Sentry...) +1 here too. Most projects here fall somewhere in a spectrum between "do whatever you want in a branch" and "don't release without having others approve your work". Different projects put the point where CTR crosses over to RTC at different points. *shrug* - Sam Ruby P.S. Personally a fan of CTR, but I'm starting to appreciate our infrastructure team's puppet workflow where everything (even one line changes) are done in a branch and everybody asks other person to merge the changes. https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fINFRA%2fGit%2bworkflow%2bfor%2binfrastructure-puppet%2brepo&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski wrote: > ++1 >> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz >> wrote: >> >> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski wrote: >>> ...httpd for example) uses RTC, CTR and Lazy Consensus >>> simultaneously and works like a dream >> >> Indeed - those are different tools that each have their own purpose. >> They just need to be applied in the right places and at the right >> time. >> >> -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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler wrote: > Good point. I should add to my comments that even a CTR project uses RTC for > non-committers. And that a release vote means that at least three people have > reviewed the code from (at least) an IP standpoint, if not from a code > quality standpoint. > > In other words, +1 > > However, RTC projects do not use a mix and that's the point of contention > here, some people feel it is suboptimal (I'm one, but others disagree). The > discussion is not whether CTR also uses RTC at points, I believe that is a > given. Let me be pedantic for a moment. While RTC projects that use Subversion may disallow work in branches, even by committers; such a restriction isn't even possible in Git -- even for non committers. > Ross - Sam Ruby > -Original Message- > From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby > Sent: Friday, November 20, 2015 7:43 AM > To: general@incubator.apache.org > Subject: Re: RTC vs CTR (was: Concerning Sentry...) > > +1 here too. > > Most projects here fall somewhere in a spectrum between "do whatever you want > in a branch" and "don't release without having others approve your work". > Different projects put the point where CTR crosses over to RTC at different > points. > > *shrug* > > - Sam Ruby > > P.S. Personally a fan of CTR, but I'm starting to appreciate our > infrastructure team's puppet workflow where everything (even one line > changes) are done in a branch and everybody asks other person to merge the > changes. > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fINFRA%2fGit%2bworkflow%2bfor%2binfrastructure-puppet%2brepo&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d > > On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski wrote: >> ++1 >>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz >>> wrote: >>> >>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski wrote: ...httpd for example) uses RTC, CTR and Lazy Consensus simultaneously and works like a dream >>> >>> Indeed - those are different tools that each have their own purpose. >>> They just need to be applied in the right places and at the right >>> time. >>> >>> -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 > > > - > 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: [QUESTION] Rewriting history
On Sat, Nov 21, 2015 at 12:02 AM, Hadrian Zbarcea wrote: > The question was asked on general@ [1] many moons ago, but received no > answer (the original thread [1] indicates the offenders). We'd like to use > this occasion to split the git repo into multiple smaller once (more > naturally tailored to the project), so one idea would be, I think, to leave > incubator-brooklyn.git as is and just extract what we need (everything > except the large binaries) in new repos. Note: afaiui, those artifacts > we're never part of an ASF release. > > I am not sure what would be acceptable per ASF (intensely debated) > policies. > Surely copying and leaving some stuff behind is a fine thing to do.
Re: RTC vs CTR (was: Concerning Sentry...)
On Sat, Nov 21, 2015 at 12:40 AM, Sam Ruby wrote: > On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler > wrote: > > Good point. I should add to my comments that even a CTR project uses RTC > for non-committers. And that a release vote means that at least three > people have reviewed the code from (at least) an IP standpoint, if not from > a code quality standpoint. > > > > In other words, +1 > > > > However, RTC projects do not use a mix and that's the point of > contention here, some people feel it is suboptimal (I'm one, but others > disagree). The discussion is not whether CTR also uses RTC at points, I > believe that is a given. > > Let me be pedantic for a moment. While RTC projects that use > Subversion may disallow work in branches, even by committers; such a > restriction isn't even possible in Git -- even for non committers. > Not only isn't something you can forbid, it isn't even something that I could understand without reading your sentence three times. Git is all about branching. Forbidding branches is a non sequitur.
Re: [QUESTION] Rewriting history
Hi, To give some context on the objects in question.. There are 14 files in Brooklyn's history larger than 1Mb. Four of these are larger than 20Mb. The largest is 57Mb(!). These files make for a significant penalty when cloning the repository. Of the fourteen large files, five were present in the Brooklyn repo when the project joined the incubator (1 May 2015). All of them were deleted before its first incubator release (0.7.0-M2 (incubating)) on 23 December 2014. The files are also not to be found in Brooklyn's last pre-ASF release (they are all either examples or in a 'sandbox' module). The other nine files were all deleted before Brooklyn even had its first public GA release (0.4.0) on January 16 2013. The worst offending file is part of this group. Regards, Sam On 20 November 2015 at 16:42, Ted Dunning wrote: > On Sat, Nov 21, 2015 at 12:02 AM, Hadrian Zbarcea > wrote: > > > The question was asked on general@ [1] many moons ago, but received no > > answer (the original thread [1] indicates the offenders). We'd like to > use > > this occasion to split the git repo into multiple smaller once (more > > naturally tailored to the project), so one idea would be, I think, to > leave > > incubator-brooklyn.git as is and just extract what we need (everything > > except the large binaries) in new repos. Note: afaiui, those artifacts > > we're never part of an ASF release. > > > > I am not sure what would be acceptable per ASF (intensely debated) > > policies. > > > > Surely copying and leaving some stuff behind is a fine thing to do. >
Re: [QUESTION] Rewriting history
To me, binaries not released by the ASF should not be necessary to keep in multiple repos so this is a project PMC decision. On 11/20/2015 11:02 AM, Hadrian Zbarcea wrote: Probably a bad subject in the context of other things going on :). Apache Brooklyn is faced with the tasks of migrating it's repo(s) post graduation and there are some very large *pre-incubation* artifacts in the git repo that we would like removed. The question was asked on general@ [1] many moons ago, but received no answer (the original thread [1] indicates the offenders). We'd like to use this occasion to split the git repo into multiple smaller once (more naturally tailored to the project), so one idea would be, I think, to leave incubator-brooklyn.git as is and just extract what we need (everything except the large binaries) in new repos. Note: afaiui, those artifacts we're never part of an ASF release. I am not sure what would be acceptable per ASF (intensely debated) policies. Thoughts? Hadrain [1] https://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201506.mbox/%3c556f0973.7030...@cloudsoftcorp.com%3E - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Fri, Nov 20, 2015 at 11:47 AM, Ted Dunning wrote: > On Sat, Nov 21, 2015 at 12:40 AM, Sam Ruby wrote: > >> On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler >> wrote: >> > Good point. I should add to my comments that even a CTR project uses RTC >> for non-committers. And that a release vote means that at least three >> people have reviewed the code from (at least) an IP standpoint, if not from >> a code quality standpoint. >> > >> > In other words, +1 >> > >> > However, RTC projects do not use a mix and that's the point of >> contention here, some people feel it is suboptimal (I'm one, but others >> disagree). The discussion is not whether CTR also uses RTC at points, I >> believe that is a given. >> >> Let me be pedantic for a moment. While RTC projects that use >> Subversion may disallow work in branches, even by committers; such a >> restriction isn't even possible in Git -- even for non committers. > > Not only isn't something you can forbid, it isn't even something that I > could understand without reading your sentence three times. > > Git is all about branching. Forbidding branches is a non sequitur. The most you can do in Git is to say that you can't do it in THIS location or give it THAT name. In which case, the inevitable response will be, OK, I'll do it elsewhere and/or give it a different name. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On 11/20/15, 8:23 AM, "Ross Gardler" wrote: >However, RTC projects do not use a mix and that's the point of contention >here, some people feel it is suboptimal (I'm one, but others disagree). >The discussion is not whether CTR also uses RTC at points, I believe that >is a given. That's the key for me. A project can say it is: 1) CTR 2) RTC 3) Some combination. Saying a project is CTR doesn't prevent someone from asking for a review before committing something. Saying a project is RTC does prevent someone from committing before review, so unless there is further documentation about exceptions which puts you in bucket 3, simply saying RTC prevents CTR, whereas the opposite is not true. -Alex
Re: RTC vs CTR (was: Concerning Sentry...)
On Thu, Nov 19, 2015 at 6:49 PM, Greg Stein wrote: > Todd: as Ross notes, your three points about code reviews in a CTR project > are quite valid, and match accepted engineering practices. > > What I haven't seen is an explanation why a committer must be treated the > same as a drive-by. Both are subject to requiring "permission"[1] to make > even the simplest of changes under RTC. Even worse, from else-thread, it > sounds like under your control scheme, you don't even allow the committer > to apply their own change [after review]. They can apply their own change once someone else has +1ed it. On Hadoop, for example, the usual workflow when I review another committer's patch is that I give them a +1 and they commit it themselves. On gerrit or github, because the actual "commit" process is just clicking a button on a web UI, it's more normal for the reviewer to be the one to commit it after giving the +1 review, but both happen and either one's fine. > A committer can give a binding +1 > to somebody else's work. But they aren't trusted to give that to their own > work. Just like a drive-by contributor can't be trusted. > Right, they can't give it to their own work because it defeats the purpose of the code review (discussed earlier). Of course it's not hard and fast -- eg fixing a broken build due to a missing 'import' statement or something would be totally fine to commit without review, or fixing a grammar mistake in a comment, or anything else that's obviously trivial. But once actual code is changing, it's expected to get two pairs of eyes. -Todd
Re: Incubator mail archives lagging badly
Is the ASF mail archive webapp OSS? I wonder how hard it would be to make a couple minor usability improvements. Mike On Wed, Nov 18, 2015 at 12:13 PM, Gregory Chase wrote: > Sorry all. It's user error. I was expecting most recent first :) > > On Wed, Nov 18, 2015 at 11:54 AM, Bertrand Delacretaz < > bdelacre...@apache.org> wrote: > > > On Wed, Nov 18, 2015 at 2:02 PM, Gregory Chase > wrote: > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201511.mbox/browser > > ... > > > > That looks up to date for me. > > That page uses javascript to load the content, maybe it's failing on > > your browser? > > > > -Bertrand > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > -- > Greg Chase > > Director of Big Data Communities > http://www.pivotal.io/big-data > > Pivotal Software > http://www.pivotal.io/ > > 650-215-0477 > @GregChase > Blog: http://geekmarketing.biz/ >
Re: Incubator mail archives lagging badly
On Fri, Nov 20, 2015 at 1:55 PM, Mike Percy wrote: > Is the ASF mail archive webapp OSS?... I don't know about the current one but AFAIK https://github.com/Humbedooh/ponymail is an (experimental so far) potential replacement for it. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator mail archives lagging badly
On 11/20/2015 08:04 PM, Bertrand Delacretaz wrote: > On Fri, Nov 20, 2015 at 1:55 PM, Mike Percy wrote: >> Is the ASF mail archive webapp OSS?... > > I don't know about the current one but AFAIK > https://github.com/Humbedooh/ponymail is an (experimental so far) > potential replacement for it. Also see https://pony-poc.apache.org/ for our Proof of Concept site. With regards, Daniel. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)
Thanks, could you send reply with modified subject prefixed with: [CANCEL] [VOTE] to indicate the voting has been cancelled? Thanks, Henry On Fri, Nov 20, 2015 at 8:18 AM, Roberta Marton wrote: > It looks like we have some copyright and licensing issue to resolved before > completing our first release. So I am officially withdrawing our request > for our first Apache Trafodion release. We will take a look at all the > issues reported and submit a new package later. > > > > Again, thanks for all your valuable information. This is obviously an area > we should have spent more time on before submitting. It has been, and will > continue to be, and educational exercise for us. > > > > Regards, > > Roberta > > > > *From:* Alex Harui [mailto:aha...@adobe.com] > *Sent:* Thursday, November 19, 2015 10:31 PM > *To:* general@incubator.apache.org > *Subject:* Re: [VOTE] Release Apache Trafodion (incubating) > 1.3.0-incubating (RC4) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[CANCEL] [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)
Vote has been cancelled. Regards, Roberta *From:* Roberta Marton [mailto:roberta.mar...@esgyn.com] *Sent:* Friday, November 20, 2015 8:19 AM *To:* 'general@incubator.apache.org' *Subject:* RE: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4) It looks like we have some copyright and licensing issue to resolved before completing our first release. So I am officially withdrawing our request for our first Apache Trafodion release. We will take a look at all the issues reported and submit a new package later. Again, thanks for all your valuable information. This is obviously an area we should have spent more time on before submitting. It has been, and will continue to be, and educational exercise for us. Regards, Roberta *From:* Alex Harui [mailto:aha...@adobe.com ] *Sent:* Thursday, November 19, 2015 10:31 PM *To:* general@incubator.apache.org *Subject:* Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)
Re: Incubator mail archives lagging badly
Thanks for the links guys. Seems like the full rewrite is pretty ambitious still needs quite a bit of work relative to making some small fixes to the existing thing (whatever it is). Mike On Fri, Nov 20, 2015 at 11:05 AM, Daniel Gruno wrote: > On 11/20/2015 08:04 PM, Bertrand Delacretaz wrote: > > On Fri, Nov 20, 2015 at 1:55 PM, Mike Percy wrote: > >> Is the ASF mail archive webapp OSS?... > > > > I don't know about the current one but AFAIK > > https://github.com/Humbedooh/ponymail is an (experimental so far) > > potential replacement for it. > > Also see https://pony-poc.apache.org/ for our Proof of Concept site. > > With regards, > Daniel. > > > > > -Bertrand > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Incubator mail archives lagging badly
Mike Percy wrote on 11/20/15 1:55 PM: > Is the ASF mail archive webapp OSS? I wonder how hard it would be to make a > couple minor usability improvements. Of course it is! It's just an httpd module, actually, which (in theory) makes install/maintenance really simple, basically pointing it at a directory of MBOXes. http://httpd.apache.org/mod_mbox/ It is, er, a touch crufty, so I imagine that medium term the Ponymail interface will eventually be used for our official archives (i.e. permanent and stable URLs) going forward, once there's a plan to get it installed/maintained. MarkMail is a good alternative search engine (third party): http://apache.markmail.org/ - Shane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating (RC4)
On 11/20/15, 8:18 AM, "Roberta Marton" wrote: >It looks like we have some copyright and licensing issue to resolved >before >completing our first release. So I am officially withdrawing our request >for our first Apache Trafodion release. We will take a look at all the >issues reported and submit a new package later. > Good luck. FWIW, at my company, the legal staff was highly interested in helping us get this right, had tools to help us get it right, and their response time was often quicker than this list and would be true legal advice instead of anecdotes from engineers who've survived the process. If you have such resources available to you it might speed up the process. They may not be able to advise on how to write the LICENSE and NOTICE files, but they could help you be more certain about which files need to be mentioned in LICENSE and NOTICE. The reason the company legal staff was interested was because the Software Grant had to be signed by a VP and needed to be as accurate as possible since the company didn't want to grant IP to the ASF and expose to the world in the ASF repos that it wasn't supposed to. Once you know who owns the various pieces and which ones have been granted vs are 3rd party, you can then make more sense of the ASF documents on how to document everything. The ASF has further rules on what 3rd party dependencies are allowed in various configurations. A company can grant software that the ASF cannot use "as-is" because it depends on 3rd party code with certain licenses. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
