Re: [DISCUSS] Groovy Incubation proposal
Le 11/03/15 21:20, Martijn Dashorst a écrit : Great initiative! Just one question: I don't see anything related to the groovy name and possible trademark in the proposal. Does Pivotal have any claims to the name groovy, and if so are those claims transferred to the ASF? I think we have raised the issue during the preliminary discussions. I don't think Pivotal has any rights on the Groovy name. I'm afraid that Marvin Gaye might has some, though ;-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Hi.
Having just skimmed the proposal, that in general look good, one thing
caught my eye.
The proposal talks several places about a vibrant community and the initial
commiters are only 5.
I am not raising it as a problem, just would like a little explanation.
I think the project would fit nicely in ASF.
rgds
jan I.
On 11 March 2015 at 19:58, Roman Shaposhnik r...@apache.org wrote:
Hi!
It is my pleasure and privilege to open up the following
proposal:
https://wiki.apache.org/incubator/GroovyProposal
for wide discussion before conducting and IPMC
vote on it. In order to engage as much potential stakeholders
as possible we will be soliciting input on {dev,users}@groovy.codehaus.org
The main discussion, however, is going to happen on this thread.
The copy of the proposal is included bellow, but please note
that any required changes would be reflected on the wiki.
Thanks,
Roman (Groovy proposal champion and a nominated mentor).
== Abstract ==
Groovy is an object-oriented programming language for the Java
platform. It is a primarily dynamic language with features similar to
those of Python, Ruby, Perl, and Smalltalk. Groovy, if accepted by
Incubator, will be a first major programming language developed under
the umbrella of Apache Software Foundation.
== Proposal ==
Groovy is a programming language for the Java platform. It is a
primarily dynamic language with features similar to those of Python,
Ruby, Perl, and Smalltalk. It also has optional static type checking
and static compilation facilities. It can be used as a scripting
language for the Java Platform or to write complete applications, is
compiled to Java Virtual Machine (JVM) bytecode, and interoperates
with other Java code and libraries. Groovy uses a Java-like
curly-bracket syntax. Most Java code is also syntactically valid
Groovy, although semantics may be different. Groovy has long been
developed under an Apache License v2.0 under an open governance
community management process. However, so far Groovy has been a
project mostly sponsored by a single company. This proposal aims at
bringing Groovy community under the umbrella of the Apache Software
Foundation.
It must be explicitly noted, that a few sister projects such as Groovy
Eclipse and others (some of them hosted under
https://github.com/groovy and listed at
http://groovy-lang.org/ecosystem.html) are not covered by this
proposal. It is possible that these other projects will be joining ASF
either independently or as sub-projects of Apache Groovy in the
future. For now, we are only proposing groovy-core.
== Background ==
Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is planned
for release in 2016, with support for a new Meta Object Protocol.
Since version 2, Groovy can also be compiled statically, offering type
inference and performance very close to that of Java. Groovy 2.4 will
be the last major release under Pivotal Software's sponsorship, which
is scheduled to end on March 31, 2015.
== Rationale ==
Groovy is a pretty mature language. After 12 years of development, it
has grown from being primarily a dynamic scripting language on the JVM
to an optionally statically compiled language allowing the same
performance level as Java applications. With the release of Groovy
2.4, the language targets the largest pool of mobile developers with
native Android support. Groovy has been integrated in a large number
of applications, including well known open-source projects like
Jenkins, Gradle, ElasticSearch, Spring and more.
There are multiple alternative languages on the JVM: Scala, Clojure,
Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
which has proved to be very easy to integrate with Java in both ways:
Groovy code using Java code, but also Java code using Groovy code.
Groovy even provides a joint compiler which allows interdependent Java
and Groovy classes to compile together. Groovy also supports dynamic
code generation, that is to say classes at runtime, making it a
perfect fit for scripting. With a very lightweight and malleable
syntax, it is also easy to build internal Domain Specific Languages
(DSLs) which integrate smoothly within applications.
Groovy provides a number of unique features, like builders (Java 8 has
lambdas but still has syntactic overhead and no notion of delegate),
AST transformations (compile-time metaprogramming) or type checking
extensions (which allows the developer to bring the compiler to levels
of type checking and type inference that go far beyond what other
languages do). Groovy also provides powerful integration options and
customizations which set it apart from other languages. Groovy is also
unique in the way it allows the developer to choose between various
paradigms without compromise: functional vs object-oriented,
statically compiled vs dynamic, scripting vs
Re: [DISCUSS] Groovy Incubation proposal
On Wed, Mar 11, 2015 at 12:08 PM, jan i j...@apache.org wrote: Hi. Having just skimmed the proposal, that in general look good, one thing caught my eye. The proposal talks several places about a vibrant community and the initial commiters are only 5. This, is a GREAT question! Thank you so much for raising it. While preparing a proposal I've struggled with the same issue, because looking at this: https://github.com/groovy/groovy-core/graphs/contributors makes me wonder exactly the same thing. In the end, we decided to go ahead with the proposal the way it is and position the initial list of committers more as a PMC for the project. That still doesn't answer your (or mine! ;-)) question of what's the best way to make sure than anybody who feels like they have a stake in the project and have contributed in the past get invited. There are a few alternatives I could see, but I would really appreciate Incubator's collective wisdom on what would be the best way to proceed here given that Groovy is a very mature project with a lot of contributors in the past. Some of whom may or may not wish to keep contributing. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Am 12.03.2015 10:57, schrieb Bertrand Delacretaz: Hi, On Wed, Mar 11, 2015 at 8:08 PM, jan i j...@apache.org wrote: ...The proposal talks several places about a vibrant community and the initial commiters are only 5... As others have said this was discussed while preparing the proposal. I also agree that it's fine to include only the core Groovy committers to enter incubation, as usual it will be their task to grow that community before graduating. community equals committers? Anyway... how many committers would you guys find appropriate to exit incubation - whenever that will be? 5 seems not to be enough. Not asking for an exact number here of course. bye Jochen -- Jochen blackdrag Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
My feeling is, that there this proposal has a positive feedback overall. How about we put together a list of things that have to be changed/resolved in the proposal before a vote can be started? I see: - trademark issues - Explanation of initial committers to community ratio what else? Benedikt 2015-03-12 13:06 GMT+01:00 Jochen Theodorou blackd...@gmx.org: Am 12.03.2015 12:04, schrieb Jochen Wiedmann: Hello, Jochen, On Thu, Mar 12, 2015 at 11:14 AM, Jochen Theodorou community equals committers? No. The community is more than the team of committers. I'm sure you understand. OTOH, the set of committers can be considered a representation of the community. I am quite certain, most Incubator members would accept a project to have a vibrant community, if the project could show, for example, * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like assuming them to be independent of each other. However, that would be most unusual for an Apache project: In most cases, the committers are the active project contributors. for example: https://github.com/groovy/groovy-website/graphs/contributors groovy-website is currently the stuff shown at groovy-lang.org That shows 23 contributors without commit rights in something that does not even exist for a year. bye Jochen -- Jochen blackdrag Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [DISCUSS] Groovy Incubation proposal
On Thu, Mar 12, 2015 at 3:14 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 12.03.2015 10:57, schrieb Bertrand Delacretaz: Hi, On Wed, Mar 11, 2015 at 8:08 PM, jan i j...@apache.org wrote: ...The proposal talks several places about a vibrant community and the initial commiters are only 5... As others have said this was discussed while preparing the proposal. I also agree that it's fine to include only the core Groovy committers to enter incubation, as usual it will be their task to grow that community before graduating. community equals committers? Anyway... how many committers would you guys find appropriate to exit incubation - whenever that will be? 5 seems not to be enough. Not asking for an exact number here of course. Easy: we reach out to all the folks who may have a legitimate claim to have contributed to the project in substantial ways and ivite extend an offer to them (explaining that being a committer is...well... a commitment). The # of those who would like to join is the number we need to consider. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
I would have thought that graduation would be all about showing that whatever list of committers we have (big or small) is working well? Having a large number of committers certainly makes sense with a subversion mindset but it's possibly an anti-pattern with a DVCS mindset (at least for a stable language in any case)? The Groovy community has always valued the actual code contribution more than who the person was who contributedthe code. I hope we can continue in that fashion. Obviously, there are logistics concerns, you need enough committers to handle the administrative tasks involved (and that will change with less full-time people contributing on that side perhaps), so we should expect changes. And, the voting is a bit different to what we have done in the past, so making that work well will be important too. I just hope we are targeting a working system rather than some magic number of committers. Cheers, Paul. On 12/03/2015 7:57 PM, Bertrand Delacretaz wrote: Hi, On Wed, Mar 11, 2015 at 8:08 PM, jan i j...@apache.org wrote: ...The proposal talks several places about a vibrant community and the initial commiters are only 5... As others have said this was discussed while preparing the proposal. I also agree that it's fine to include only the core Groovy committers to enter incubation, as usual it will be their task to grow that community before graduating. The alternative would be to start with a huge list of initial committers (everybody who contributed more than X to Groovy) and before graduating reduce it to the list of people who actually contributed during incubation, but that's much more work IMO. -Bertrand --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
question about GSoC
Dear Sir/Madam: Hope this e-mail finds you well. I am a student who is going to participate the 2015 GSoC. I am a student of Dr. Li Dingcheng who is a PMC member of ASF. I want him to be my mentor and we are going to develop the Coreference Resolution with java. It will be very kind of you if you accept my request. I am looking forward to your reply! Many thanks! -- - ?? David Lee Sichuan University
Re: question about GSoC
Hi, On Thu, Mar 12, 2015 at 12:57 PM, 李璋华 david_...@foxmail.com wrote: ...I am a student who is going to participate the 2015 GSoC. I am a student of Dr. Li Dingcheng who is a PMC member of ASF. I want him to be my mentor... You need to talk to the developers list of the project in question. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [CANCEL] [VOTE] Release Apache Slider 0.70.0-incubating
On Thu, Mar 12, 2015 at 7:17 PM, Gour Saha gs...@hortonworks.com wrote: Marvin, That totally makes sense. I am going to cancel this release and prepare a new RC with the fixes. I will call it 0.70.1-incubating and start the vote all over again. Thank you. And thank you, Gour, for your persistence and understanding. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[CANCEL] [VOTE] Release Apache Slider 0.70.0-incubating
Marvin, That totally makes sense. I am going to cancel this release and prepare a new RC with the fixes. I will call it 0.70.1-incubating and start the vote all over again. Thank you. -Gour On 3/12/15, 7:02 PM, Marvin Humphrey mar...@rectangular.com wrote: On Thu, Mar 12, 2015 at 6:36 PM, Gour Saha gs...@hortonworks.com wrote: Is it okay if we move them to a more appropriate location like src/test/resources directory? Or should we just delete them? Here's the rationale, redux: The Apache Software Foundation releases open source software. Binary files cannot be audited by a PMC. Even if they are derived from open source, they are not open source themselves. They are a potential security hole -- an attacker who gains control of the machine on which those binaries are introduced may be able to insert a trojan which then goes along for the ride with the distribution. Security-conscious consumers who compile from source distributions rather than use convenience binaries will find it tricky and laborious to detect and replace embedded mystery binaries. Does that make sense? Based on that rationale, I hope that you can find a workaround which allows the official source release to be entirely free of binaries. 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: [VOTE] Release Apache Slider 0.70.0-incubating
On Thu, Mar 12, 2015 at 6:36 PM, Gour Saha gs...@hortonworks.com wrote: Is it okay if we move them to a more appropriate location like src/test/resources directory? Or should we just delete them? Here's the rationale, redux: The Apache Software Foundation releases open source software. Binary files cannot be audited by a PMC. Even if they are derived from open source, they are not open source themselves. They are a potential security hole -- an attacker who gains control of the machine on which those binaries are introduced may be able to insert a trojan which then goes along for the ride with the distribution. Security-conscious consumers who compile from source distributions rather than use convenience binaries will find it tricky and laborious to detect and replace embedded mystery binaries. Does that make sense? Based on that rationale, I hope that you can find a workaround which allows the official source release to be entirely free of binaries. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Groovy Incubation proposal
I think the business about numbers of committers and how additions to the community are cultivated is a sniff test concerning sustainability. The idea is to have some sense that there is a sustainable community in place and that there is as much attention on nurturing that sustainability as there is in code wrangling. Being able to produce releases is also a related consideration that has a sustainability component. How is release manager rotation handled? Is there release-manager rotation? (Not graduation criteria, AFAIK, but a similar concern and perhaps not quite the right terms for Groovy.) What these mean in practice depends a lot on what the scope of the project is, of course. My very limited experience with two podlings suggests that this all gets worked out in incubation (at least in terms of the direction to continue as a TLP), not before incubation. Attention to these considerations most definitely does not end at graduation, either. -Original Message- From: Paul King [mailto:pa...@asert.com.au] Sent: Thursday, March 12, 2015 03:17 To: Bertrand Delacretaz; Incubator General Cc: Cédric Champeau; Jochen Theodorou; pascalschumacher; Guillaume Laforge Subject: Re: [DISCUSS] Groovy Incubation proposal I would have thought that graduation would be all about showing that whatever list of committers we have (big or small) is working well? Having a large number of committers certainly makes sense with a subversion mindset but it's possibly an anti-pattern with a DVCS mindset (at least for a stable language in any case)? The Groovy community has always valued the actual code contribution more than who the person was who contributedthe code. I hope we can continue in that fashion. Obviously, there are logistics concerns, you need enough committers to handle the administrative tasks involved (and that will change with less full-time people contributing on that side perhaps), so we should expect changes. And, the voting is a bit different to what we have done in the past, so making that work well will be important too. I just hope we are targeting a working system rather than some magic number of committers. Cheers, Paul. On 12/03/2015 7:57 PM, Bertrand Delacretaz wrote: Hi, On Wed, Mar 11, 2015 at 8:08 PM, jan i j...@apache.org wrote: ...The proposal talks several places about a vibrant community and the initial commiters are only 5... As others have said this was discussed while preparing the proposal. I also agree that it's fine to include only the core Groovy committers to enter incubation, as usual it will be their task to grow that community before graduating. The alternative would be to start with a huge list of initial committers (everybody who contributed more than X to Groovy) and before graduating reduce it to the list of people who actually contributed during incubation, but that's much more work IMO. -Bertrand --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com - 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: [DISCUSS] Groovy Incubation proposal
On Thu, Mar 12, 2015 at 3:35 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: ...Easy: we reach out to all the folks who may have a legitimate claim to have contributed to the project in substantial ways and ivite extend an offer to them (explaining that being a committer is...well... a commitment). The # of those who would like to join is the number we need to consider That sounds like a lot of work, you could also just do a great job as Apache Groovy (incubating) and see who shows up. With bonus points towards commitership for people who were previously active on Groovy. But anyway, the details of that are for the Groovy podling to decide, once it is accepted. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Singa as incubator project
+1 On Tue, Mar 10, 2015 at 7:33 AM, Thejas Nair thejas.n...@gmail.com wrote: The Singa Incubator Proposal document has been updated based on feedback in the proposal thread. This vote is proposing the inclusion of Apache Singa as incubator project. The vote will run for at least 72 hours. [ ] +1 Accept Apache Singa into the Incubator [ ] +0 Don’t care. [ ] -1 Don’t accept Apache Singa into the Incubator because.. Please vote ! Here is my +1 . Link to version of proposal being voted on : https://wiki.apache.org/incubator/SingaProposal?action=recallrev=10 The text is below -- = Singa Incubator Proposal = == Abstract == SINGA is a distributed deep learning platform. == Proposal == SINGA is an efficient, scalable and easy-to-use distributed platform for training deep learning models, e.g., Deep Convolutional Neural Network and Deep Belief Network. It parallelizes the computation (i.e., training) onto a cluster of nodes by distributing the training data and model automatically to speed up the training. Built-in training algorithms like Back-Propagation and Contrastive Divergence are implemented based on common abstractions of deep learning models. Users can train their own deep learning models by simply customizing these abstractions like implementing the Mapper and Reducer in Hadoop. == Background == Deep learning refers to a set of feature (or representation) learning models that consist of multiple (non-linear) layers, where different layers learn different levels of abstractions (representations) of the raw input data. Larger (in terms of model parameters) and deeper (in terms of number of layers) models have shown better performance, e.g., lower image classification error in Large Scale Visual Recognition Challenge. However, a larger model requires more memory and larger training data to reduce over-fitting. Complex numeric operations make the training computation intensive. In practice, training large deep learning models takes weeks or months on a single node (even with GPU). == Rational == Deep learning has gained a lot of attraction in both academia and industry due to its success in a wide range of areas such as computer vision and speech recognition. However, training of such models is computationally expensive, especially for large and deep models (e.g., with billions of parameters and more than 10 layers). Both Google and Microsoft have developed distributed deep learning systems to make the training more efficient by distributing the computations within a cluster of nodes. However, these systems are closed source softwares. Our goal is to leverage the community of open source developers to make SINGA efficient, scalable and easy to use. SINGA is a full fledged distributed platform, that could benefit the community and also benefit from the community in their involvement in contributing to the further work in this area. We believe the nature of SINGA and our visions for the system fit naturally to Apache's philosophy and development framework. == Initial Goals == We have developed a system for SINGA running on a commodity computer cluster. The initial goals include, * improving the system in terms of scalability and efficiency, e.g., using Infiniband for network communication and multi-threading for one node computation. We would consider extending SINGA to GPU clusters later. * benchmarking with larger datasets (hundreds of millions of training instances) and models (billions of parameters). * adding more built-in deep learning models. Users can train the built-in models on their datasets directly. == Current Status == === Meritocracy === We would like to follow ASF meritocratic principles to encourage more developers to contribute in this project. We know that only active and excellent developers can make SINGA a successful project. The committer list and PMC will be updated based on developers' performance and commitment. We are also improving the documentation and code to help new developers get started quickly. === Community === SINGA is currently being developed in the Database System Research Lab at the National University of Singapore (NUS) in collaboration with Zhejiang University in China. Our lab has extensive experience in building database related systems, including distributed systems. Six PhD students and research assistants (Jinyang Gao, Kaiping Zheng, Sheng Wang, Wei Wang, Zhaojing Luo and Zhongle Xie) , a research fellow (Anh Dinh) and three professors (Beng Chin Ooi, Gang Chen, Kian Lee Tan) have been working for a year on this project. We are open to recruiting more developers from diverse backgrounds. === Core Developers === Beng Chin Ooi, Gang Chen and Kian Lee Tan are professors who have worked on distributed systems for more than 20 years. They have collaborated with the industry and have built various
Re: [DISCUSS] Groovy Incubation proposal
On Mar 12, 2015, at 8:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Mar 12, 2015 at 12:04 PM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: ... I am quite certain, most Incubator members would accept a project to have a vibrant community, if the project could show, for example,... Note that we don't care about the state of the community when entering the incubator, that's an exit criteria. Not even vibrant for exit, just a community that is open to including new people and knows how to do that as an Apache project. Agreed. And personally, I prefer the smaller “enter” community compared to the piling on of bunches of people that may or may not contribute that I’ve seen on a bunch of projects. I’d greatly prefer seeing the community start small and “grow” during incubation. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On Thu, Mar 12, 2015 at 10:13 AM, Cédric Champeau cedric.champ...@gmail.com wrote: I made this remark to myself, which is that too many people still think that Groovy is only a dynamic language. I think it's a problem because it's not, and some people really dislike dynamic languages. When they read something like the Groovy dynamic object-oriented programming language (from the Apache blog post) may not realize that it's much more than that (it was only dynamic a few years ago, but it has evolved a lot, and now a static language as much as it is a dynamic one). So I would lean towards rephrasing the first paragraph of the proposal from It is a primarily dynamic language with features similar to those of Python, Ruby, Perl, and Smalltalk. to It is a programming language with features similar to those of Python, Ruby, Java, Perl, and Smalltalk. And if possible, everything we see dynamic programming language, remove the mention to dynamic to just programming language. What do you think? It's not that I don't like the dynamic programming aspects of Groovy of course, but I think we should not cut off part of our user base just by making erroneous statements. Sure. That looks good to me. That being said -- what's written on the proposal is only important to the IPMC so I don't think it'll be a huge change in outside perception one way or another. Thanks, Roman. P.S. That said, I never stop being amazed at what kind of 'karma' outside folks associate with mundane things like being mentioned on an IPMC proposal. To me, what happens *after* you get accepted and how you project your community to the outside world is way more important than. But then again, may be I've been at a sausage factory for too long ;-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Am 12.03.2015 17:21, schrieb Ted Dunning: On Thu, Mar 12, 2015 at 4:04 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like This is a good list. But I take strong issue with the without committer privileges part. If somebody is contributing, make them committers. Expect them to be responsible about what they commit and follow whatever process there is. If talk about say 10 commits within 3 months, sure. Just does not happen for 90% of the contributors. Many work on a project at their workplace and once the problem the have faced is solved they walk away again. bye Jochen -- Jochen blackdrag Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On 12/03/2015 17:53, Daniel Kulp wrote: On Mar 12, 2015, at 8:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Mar 12, 2015 at 12:04 PM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: ... I am quite certain, most Incubator members would accept a project to have a vibrant community, if the project could show, for example,... Note that we don't care about the state of the community when entering the incubator, that's an exit criteria. Not even vibrant for exit, just a community that is open to including new people and knows how to do that as an Apache project. Agreed. And personally, I prefer the smaller “enter” community compared to the piling on of bunches of people that may or may not contribute that I’ve seen on a bunch of projects. I’d greatly prefer seeing the community start small and “grow” during incubation. Agreed. Even though I think Groovy is IMHO special. It's a 12 years old project, which have seen lots of contributors. Some contributed a lot in the past, some contribute a lot now and even some always contributed.I have no doubt more committers will come, and more people will contribute. I understand why we need to go through the incubation phase, but there are things like this which bother me. I think Apache and Groovy worked more or less the same way in the way we accept new committers: contribute on a regular basis, with our quality standards and you're good to go. Not so many candidates but I can already see some, but in any case, I think meritocracy is very important. So I see no point in wanting to reach a target number of committers. Having a large number of quality contributions, more contributors is IMHO more important than people having write access to the repo. And as seeing a language like Groovy grow during incubation, it all depends how long we will stay in incubating phase. I just recently realized for example that we would have to version with -incubating. For our community, for our users (and for me), it is very strange to have a 12 yo project suddenly having version with -incubating. For example we're about to release 2.4.2, and then we would have 2.4.3-incubating. I don't like it at all because it sounds like not ready. So the shorter the incubation phase, the better. And if there are arbitrary objectives like let's reach X committers, I don't really see the point. Understanding the Apache Way is important, adapting the release process is important, making sure that we respect the community is very important. The number of committers is not. -- Cédric Champeau Groovy language developer http://twitter.com/CedricChampeau http://melix.github.io/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On 12/03/2015 18:19, Roman Shaposhnik wrote: On Thu, Mar 12, 2015 at 10:13 AM, Cédric Champeau cedric.champ...@gmail.com wrote: I made this remark to myself, which is that too many people still think that Groovy is only a dynamic language. I think it's a problem because it's not, and some people really dislike dynamic languages. When they read something like the Groovy dynamic object-oriented programming language (from the Apache blog post) may not realize that it's much more than that (it was only dynamic a few years ago, but it has evolved a lot, and now a static language as much as it is a dynamic one). So I would lean towards rephrasing the first paragraph of the proposal from It is a primarily dynamic language with features similar to those of Python, Ruby, Perl, and Smalltalk. to It is a programming language with features similar to those of Python, Ruby, Java, Perl, and Smalltalk. And if possible, everything we see dynamic programming language, remove the mention to dynamic to just programming language. What do you think? It's not that I don't like the dynamic programming aspects of Groovy of course, but I think we should not cut off part of our user base just by making erroneous statements. Sure. That looks good to me. That being said -- what's written on the proposal is only important to the IPMC so I don't think it'll be a huge change in outside perception one way or another. In fact, my reaction comes from the fact that I am reading many press articles where we read the Groovy dynamic language or variants. And since this is written in the Apache Blog itself[1] and the proposal [2] we cannot really blame them. Marketing-wise, looks like a bad move :) [1] https://blogs.apache.org/foundation/entry/groovy_submitted_to_become_a [2] https://wiki.apache.org/incubator/GroovyProposal -- Cédric Champeau Groovy language developer http://twitter.com/CedricChampeau http://melix.github.io/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Slider 0.70.0-incubating
On 11 Mar 2015, at 13:43, Gour Saha gs...@hortonworks.com wrote: Hello, This is a call for a vote for releasing Apache Slider 0.70.0-incubating. This is a source+binary release with one .tar file (appdef_1.tar), which is a text file used for -ve testing. Summary of fixes: http://s.apache.org/AnM Vote thread: http://s.apache.org/YQx Results: http://s.apache.org/fFH Staged artifacts: https://repository.apache.org/content/repositories/orgapacheslider-1004/org/apache/slider/ Git Source: https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=commit;h=a8919c847547f0f0db74d76f67f06e1d423a61d3 SHA1: a8919c847547f0f0db74d76f67f06e1d423a61d3 Tag: slider-0.70.0-incubating PGP key: http://pgp.mit.edu/pks/lookup?op=vindexsearch=gourks...@apache.org Basic build/test instructions: http://slider.incubator.apache.org/developing/building.html Please vote on releasing this package as Apache Slider 0.70.0-incubating. This vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thank You, The Apache Slider Team +1 (binding). D/L'd and tested the code -steve - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Am 12.03.2015 18:15, schrieb Roman Shaposhnik: […] In short: * blocking proposal on the # of initial committers -- no, or at least I don't think so. * killing ourselves over reaching every single contributor on GH -- no. * doing a reasonable due diligence *while incubating* on reaching out to past contributors and having a conversations with them (IF they are interested!) -- ABSOLUTELY! good, that means you don't see a problem for the acceptance of the proposal bye Jochen -- Jochen blackdrag Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On Thu, Mar 12, 2015 at 10:02 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 12.03.2015 17:21, schrieb Ted Dunning: On Thu, Mar 12, 2015 at 4:04 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like This is a good list. But I take strong issue with the without committer privileges part. If somebody is contributing, make them committers. Expect them to be responsible about what they commit and follow whatever process there is. If talk about say 10 commits within 3 months, sure. Just does not happen for 90% of the contributors. Many work on a project at their workplace and once the problem the have faced is solved they walk away again. That's why we have to be clear that we're inviting them to be active participants on the project, not simply recognizing their past merit. In fact, I would argue that a change (or at least a clarification) of Groovy governance model may in fact rekindle commitment in folks who in the past were simply drive-by contributors on github. This is exactly what fostering a vibrant community is all about. In short: * blocking proposal on the # of initial committers -- no, or at least I don't think so. * killing ourselves over reaching every single contributor on GH -- no. * doing a reasonable due diligence *while incubating* on reaching out to past contributors and having a conversations with them (IF they are interested!) -- ABSOLUTELY! Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [DISCUSS] Groovy Incubation proposal
+1 See C030 on our project maturity model http://community.apache.org/apache-way/apache-project-maturity-model.html And some commentary on committer = someone who is committed rather than someone who commits code https://community.apache.org/contributors/ Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation -Original Message- From: Ted Dunning [mailto:ted.dunn...@gmail.com] Sent: Thursday, March 12, 2015 9:22 AM To: general@incubator.apache.org Cc: Cédric Champeau; Paul King; pascalschumacher; Guillaume Laforge Subject: Re: [DISCUSS] Groovy Incubation proposal On Thu, Mar 12, 2015 at 4:04 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like This is a good list. But I take strong issue with the without committer privileges part. If somebody is contributing, make them committers. Expect them to be responsible about what they commit and follow whatever process there is. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
I made this remark to myself, which is that too many people still think
that Groovy is only a dynamic language. I think it's a problem because
it's not, and some people really dislike dynamic languages. When they
read something like the Groovy dynamic object-oriented programming
language (from the Apache blog post)
may not realize that it's much more than that (it was only dynamic a few
years ago, but it has evolved a lot, and now a static language as much as
it is a dynamic one). So I would lean towards rephrasing the first
paragraph of the proposal from It is a primarily dynamic language with
features similar to those of Python, Ruby, Perl, and Smalltalk.
to It is a programming language with features similar to those of
Python, Ruby, Java, Perl, and Smalltalk.
And if possible, everything we see dynamic programming language,
remove the mention to dynamic to just programming language. What do
you think? It's not that I don't like the dynamic
programming aspects of Groovy of course, but I think we should not cut
off part of our user base just by making erroneous statements.
On 11/03/2015 19:58, Roman Shaposhnik wrote:
Hi!
It is my pleasure and privilege to open up the following
proposal:
https://wiki.apache.org/incubator/GroovyProposal
for wide discussion before conducting and IPMC
vote on it. In order to engage as much potential stakeholders
as possible we will be soliciting input on {dev,users}@groovy.codehaus.org
The main discussion, however, is going to happen on this thread.
The copy of the proposal is included bellow, but please note
that any required changes would be reflected on the wiki.
Thanks,
Roman (Groovy proposal champion and a nominated mentor).
== Abstract ==
Groovy is an object-oriented programming language for the Java
platform. It is a primarily dynamic language with features similar to
those of Python, Ruby, Perl, and Smalltalk. Groovy, if accepted by
Incubator, will be a first major programming language developed under
the umbrella of Apache Software Foundation.
== Proposal ==
Groovy is a programming language for the Java platform. It is a
primarily dynamic language with features similar to those of Python,
Ruby, Perl, and Smalltalk. It also has optional static type checking
and static compilation facilities. It can be used as a scripting
language for the Java Platform or to write complete applications, is
compiled to Java Virtual Machine (JVM) bytecode, and interoperates
with other Java code and libraries. Groovy uses a Java-like
curly-bracket syntax. Most Java code is also syntactically valid
Groovy, although semantics may be different. Groovy has long been
developed under an Apache License v2.0 under an open governance
community management process. However, so far Groovy has been a
project mostly sponsored by a single company. This proposal aims at
bringing Groovy community under the umbrella of the Apache Software
Foundation.
It must be explicitly noted, that a few sister projects such as Groovy
Eclipse and others (some of them hosted under
https://github.com/groovy and listed at
http://groovy-lang.org/ecosystem.html) are not covered by this
proposal. It is possible that these other projects will be joining ASF
either independently or as sub-projects of Apache Groovy in the
future. For now, we are only proposing groovy-core.
== Background ==
Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is planned
for release in 2016, with support for a new Meta Object Protocol.
Since version 2, Groovy can also be compiled statically, offering type
inference and performance very close to that of Java. Groovy 2.4 will
be the last major release under Pivotal Software's sponsorship, which
is scheduled to end on March 31, 2015.
== Rationale ==
Groovy is a pretty mature language. After 12 years of development, it
has grown from being primarily a dynamic scripting language on the JVM
to an optionally statically compiled language allowing the same
performance level as Java applications. With the release of Groovy
2.4, the language targets the largest pool of mobile developers with
native Android support. Groovy has been integrated in a large number
of applications, including well known open-source projects like
Jenkins, Gradle, ElasticSearch, Spring and more.
There are multiple alternative languages on the JVM: Scala, Clojure,
Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
which has proved to be very easy to integrate with Java in both ways:
Groovy code using Java code, but also Java code using Groovy code.
Groovy even provides a joint compiler which allows interdependent Java
and Groovy classes to compile together. Groovy also supports dynamic
code generation, that is to say classes at runtime, making it a
perfect fit for scripting. With a very lightweight and malleable
syntax, it is also easy to build internal Domain Specific Languages
(DSLs) which integrate smoothly within
Re: [VOTE] Release Apache Slider 0.70.0-incubating
+1 binding On Wed, Mar 11, 2015 at 1:43 PM, Gour Saha gs...@hortonworks.com wrote: Hello, This is a call for a vote for releasing Apache Slider 0.70.0-incubating. This is a source+binary release with one .tar file (appdef_1.tar), which is a text file used for -ve testing. Summary of fixes: http://s.apache.org/AnM Vote thread: http://s.apache.org/YQx Results: http://s.apache.org/fFH Staged artifacts: https://repository.apache.org/content/repositories/orgapacheslider-1004/org/apache/slider/ Git Source: https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=commit;h=a8919c847547f0f0db74d76f67f06e1d423a61d3 SHA1: a8919c847547f0f0db74d76f67f06e1d423a61d3 Tag: slider-0.70.0-incubating PGP key: http://pgp.mit.edu/pks/lookup?op=vindexsearch=gourks...@apache.org Basic build/test instructions: http://slider.incubator.apache.org/developing/building.html Please vote on releasing this package as Apache Slider 0.70.0-incubating. This vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thank You, The Apache Slider Team -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [DISCUSS] Groovy Incubation proposal
2015-03-12 16:27 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org: On Thu, Mar 12, 2015 at 3:35 PM, Roman Shaposhnik ro...@shaposhnik.org wrote: ...Easy: we reach out to all the folks who may have a legitimate claim to have contributed to the project in substantial ways and ivite extend an offer to them (explaining that being a committer is...well... a commitment). The # of those who would like to join is the number we need to consider That sounds like a lot of work, you could also just do a great job as Apache Groovy (incubating) and see who shows up. With bonus points towards commitership for people who were previously active on Groovy. Sounds like the way to go to me. Simply inviting all previous contributors doesn't imply they new the ASF way. So let them join the party, if they really like and invite them to become committers after they have shown they understand how it works around here. B. But anyway, the details of that are for the Groovy podling to decide, once it is accepted. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [DISCUSS] Groovy Incubation proposal
On Thu, Mar 12, 2015 at 4:04 AM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like This is a good list. But I take strong issue with the without committer privileges part. If somebody is contributing, make them committers. Expect them to be responsible about what they commit and follow whatever process there is.
Re: [APPROVE] The March MRQL report
Crikey, this went into my junk mail folder. Signed off. Regards, Alan On Mar 7, 2015, at 6:04 AM, Leonidas Fegaras fega...@cse.uta.edu wrote: Dear MRQL mentors, This is a reminder to approve the MRQL report. Please edit it and approve it at: https://wiki.apache.org/incubator/March2015 Thanks Leonidas - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On Wed, Mar 11, 2015 at 11:58 AM, Roman Shaposhnik r...@apache.org wrote: It is my pleasure and privilege to open up the following proposal: https://wiki.apache.org/incubator/GroovyProposal I've read through the proposal (rev 17). It looks good to me. FWIW I winced a bit on Apache Pig's behalf when I read that Groovy, if accepted by Incubator, will be a first major programming language developed under the umbrella of Apache Software Foundation. The conversation around committer/PMC-member composition is healthy, but would be better held on the podling dev list so that the wider Groovy community gets to see it. I'm am persuaded that the core contributors understand the issues well enough, especially after reading this: https://wiki.apache.org/incubator/GroovyProposal#Known_Risks For Groovy to fully transition to an Apache Way governance model it needs to start embracing the meritocracy-centric way of growing the community of contributors while balancing it with the needs for extreme stability and coherency of the core language implementation. Great to see Groovy here! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On Wed, Mar 11, 2015 at 11:58 AM, Roman Shaposhnik r...@apache.org wrote: It is my pleasure and privilege to open up the following proposal: https://wiki.apache.org/incubator/GroovyProposal Thanks Roman, the proposal looks great and I am super happy to see Groovy in these lands! As the PMC chair for the Apache OFBiz project I would be particularly pleased to have Groovy in the ASF: we use Groovy a lot and we have also implemented a DSL based on it [*]. I remember that, when some time ago I contributed an enhancement for Groovy-core for some performance issues we discovered in OFBiz [**], the interaction with the Groovy committers has been pleasant and productive. I look forward at more future collaborations among our projects and I will definitely closely follow Groovy in the Incubation process. Jacopo [*] I also presented it at two ApacheCon in Denver and Budapest [**] https://github.com/groovy/groovy-core/pull/256 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
On Thu, Mar 12, 2015 at 12:04 PM, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: ... I am quite certain, most Incubator members would accept a project to have a vibrant community, if the project could show, for example,... Note that we don't care about the state of the community when entering the incubator, that's an exit criteria. Not even vibrant for exit, just a community that is open to including new people and knows how to do that as an Apache project. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Singa as incubator project
Thanks for the feedback Bertrand! Yes, I agree it makes sense to start with a single user and dev mailing list. I got this feedback during the proposal phase, but I forgot to update the proposal. On Wed, Mar 11, 2015 at 2:42 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Mar 10, 2015 at 11:52 PM, Olemis Lang ole...@gmail.com wrote: ...I do not know if this matters at all but JFYI , singa is considered as an obscene word by native Spanish speakers in quite a few regions It does matter in terms of marketing IMO. Also, dunno if that's been discussed already and it's just a detail but in general I recommend starting without a user mailing list, and creating only if dev list traffic becomes a problem. Apart from that +1 to incubation. -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 Slider 0.70.0-incubating
HI, It's -1 binding from me as there are binary files (dll's and exe's!) in the source release (in both the .zip and tar.gz). Was rat run over the release? It seems a little strange the release got this far without anyone noticing that. Here are the offending files: apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hadoop.dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hadoop.pdb apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hdfs.dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hdfs.pdb apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/winutils.exe apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/winutils.pdb apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0-SNAPSHOT/bin/hadoop.dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0-SNAPSHOT/bin/hdfs.dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0-SNAPSHOT/bin/winutils.exe I did check: - signatures and hashes correct - DISCLAIMER exists - LICENSE and NOTICE good - Source files have headers - Can compile from source - minor issues pointed out with the last release have been fixed So good news is everything else looks OK to me. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Am 12.03.2015 12:04, schrieb Jochen Wiedmann: Hello, Jochen, On Thu, Mar 12, 2015 at 11:14 AM, Jochen Theodorou community equals committers? No. The community is more than the team of committers. I'm sure you understand. OTOH, the set of committers can be considered a representation of the community. I am quite certain, most Incubator members would accept a project to have a vibrant community, if the project could show, for example, * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like assuming them to be independent of each other. However, that would be most unusual for an Apache project: In most cases, the committers are the active project contributors. for example: https://github.com/groovy/groovy-website/graphs/contributors groovy-website is currently the stuff shown at groovy-lang.org That shows 23 contributors without commit rights in something that does not even exist for a year. bye Jochen -- Jochen blackdrag Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Hi, On Thu, Mar 12, 2015 at 11:14 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 12.03.2015 10:57, schrieb Bertrand Delacretaz: it's fine to include only the core Groovy committers to enter incubation, as usual it will be their task to grow that community before graduating. community equals committers? No, committers are only part of that of course - but an Apache podling has to demonstrate that it knows how to select, vote in and onboard new committers and PMC members. Note that non-code committers and PMC members are also welcome in Apache projects. They're made committers because they are committed to the project (and we don't have a different role name) but they might not contribute much code - as happens for people who write docs and tutorials, act as evangelists etc. ...Anyway... how many committers would you guys find appropriate to exit incubation - whenever that will be? 5 seems not to be enough To be viable I'd say an Apache project needs at least 5 PMC members when graduating, as you need 3 to vote on things and people cannot be expected to be active all the time. But there's not set number of committers or PMC members that you need to add during incubation, it's just demonstrating the ability to grow the community which shouldn't be hard for Groovy. HTH, -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Hi, On Wed, Mar 11, 2015 at 8:08 PM, jan i j...@apache.org wrote: ...The proposal talks several places about a vibrant community and the initial commiters are only 5... As others have said this was discussed while preparing the proposal. I also agree that it's fine to include only the core Groovy committers to enter incubation, as usual it will be their task to grow that community before graduating. The alternative would be to start with a huge list of initial committers (everybody who contributed more than X to Groovy) and before graduating reduce it to the list of people who actually contributed during incubation, but that's much more work IMO. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Groovy Incubation proposal
Hello, Jochen, On Thu, Mar 12, 2015 at 11:14 AM, Jochen Theodorou community equals committers? No. The community is more than the team of committers. I'm sure you understand. OTOH, the set of committers can be considered a representation of the community. I am quite certain, most Incubator members would accept a project to have a vibrant community, if the project could show, for example, * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providing hosting services, and the like assuming them to be independent of each other. However, that would be most unusual for an Apache project: In most cases, the committers are the active project contributors. Groovy might very well be a case to set a precedent here, as it already has an impressive community. Don't bother thinking too much about that point. Anyway... how many committers would you guys find appropriate to exit incubation - whenever that will be? 5 seems not to be enough. Not asking for an exact number here of course. I'd bet that there are projects who left the Incubator without more than 5 committers, or at least, without 5 really active committers. Again, don't waste your time thinking about that. The Groovy community is already quite impressive - and very unusually so for an Incubator project. Jochen -- Any world that can produce the Taj Mahal, William Shakespeare, and Stripe toothpaste can't be all bad. (C.R. MacNamara, One Two Three) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Wave community may need our help
Hi! all throughout my tenure I was keeping an eye on Wave trying to figure out how we can help that community. The poddling has been incubating close to 5 years and for a long time they've struggled with the basics of producing the release and growing the community beyond its core. I was extremely excited to see that this reporting cycle they seem to be finally turning the corner. Unfortunately, next thing I saw was that the report wasn't signed off by mentors. I totally understand that we all get busy (hey -- I was supposed to submit the final report yesterday -- totally didn't happen). It is just that if the community is really on the verge of turning the corner I think it really behoves us to help them as much as we can. Thoughts on how we can revitalize mentoring around Wave? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Slider 0.70.0-incubating
Hi, I notice the binaries in question are in version control as well [1] which is highly unusual. This seem to be related to this [2], I also note it doest't look like vote for Hadoop 2.6 RC0 passed but RC1 did. [3]. Any else have concerns about this? Thanks, Justin 1. https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=tree;f=bin/windows/hadoop-2.6.0/bin;h=54bc10b5b49eeba5afdf80ce9234b683bcaef464;hb=refs/heads/develop 2. https://issues.apache.org/jira/browse/SLIDER-640 3. http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201411.mbox/%3c3a1ddd2d-b4bb-44fc-a8f3-5daef6d05...@hortonworks.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 Slider 0.70.0-incubating
Hi Justin, Thank you for your time. These files are test resources to make tests work on Jenkins on a windows machine - https://issues.apache.org/jira/browse/SLIDER-201 The readme.md located below also gives a little info but I just realized that it is incomplete - https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=blob;f=bin /windows/hadoop-2.6.0-SNAPSHOT/readme.md;h=9e4dd5259d1c6e892005b7fa5004aba2 c0a88400;hb=a8919c847547f0f0db74d76f67f06e1d423a61d3 Is it okay if we move them to a more appropriate location like src/test/resources directory? Or should we just delete them? Please let me know. -Gour On 3/12/15, 5:26 PM, Justin Mclean jus...@classsoftware.com wrote: HI, It's -1 binding from me as there are binary files (dll's and exe's!) in the source release (in both the .zip and tar.gz). Was rat run over the release? It seems a little strange the release got this far without anyone noticing that. Here are the offending files: apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hadoop.dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hadoop.pdb apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hdfs.dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/hdfs.pdb apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/winutils.exe apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0/bin/winutils.pdb apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0-SNAPSHOT/bin/hado op.dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0-SNAPSHOT/bin/hdfs .dll apache-slider-0.70.0-incubating/bin/windows/hadoop-2.6.0-SNAPSHOT/bin/winu tils.exe I did check: - signatures and hashes correct - DISCLAIMER exists - LICENSE and NOTICE good - Source files have headers - Can compile from source - minor issues pointed out with the last release have been fixed So good news is everything else looks OK to me. 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
