Re: apache binary distributions

Am 06.08.2015 02:43, schrieb Roman Shaposhnik: [...] As you probably remember we've discussed this issue not that long time ago: http://thread.gmane.org/gmane.comp.apache.incubator.general/49852 The consensus there is that as long as you're communicating intent clearly you can let downstream dev

Re: apache binary distributions

Am 06.08.2015 08:22, schrieb Niclas Hedhman: On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik wrote: I honestly see no problem with that, again provided that the artifact can NOT be confused with the one coming from Apache project. I think the "problem" lies in Trademarks. Debian's Tomcat7

Re: apache binary distributions

Am 07.08.2015 02:50, schrieb Roman Shaposhnik: On Thu, Aug 6, 2015 at 1:15 AM, Jochen Theodorou wrote: [...] The assumption that you're making is a reasonable one: only PMC is authorized to make work available (which will mean that everything else is derived work). That said, I'd

Re: apache binary distributions

Am 17.08.2015 10:45, schrieb Branko Čibej: [...] So wait ... If the Subversion PMC releases source, and, say, Debian creates a binary package called 'subversion-x.y.z' ... you're saying that's trademark infringement and we should be telling all the people who produce binary packages to stop using

Re: apache binary distributions

Am 18.08.2015 18:46, schrieb Marvin Humphrey: On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen So what if a project (members) does not vote but unofficially releases binary executable packages, perhaps along with source to some other location than /dist/? Clearly, it's not an official release by

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

Am 06.09.2015 04:22, schrieb Dave Fisher: [...] Also Apache needs a release policy for binaries that would allow the best UX/UI API for the platform to be used even if it is GPL. If you have subscribed to legal-discuss the last few months you know why that discussion was impossible. If that ca

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

Am 06.09.2015 19:43, schrieb Peter Kelly: On 6 Sep 2015, at 11:22 pm, Jochen Theodorou wrote: Am 06.09.2015 04:22, schrieb Dave Fisher: [...] Also Apache needs a release policy for binaries that would allow the best UX/UI API for the platform to be used even if it is GPL. If you have

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

Am 07.09.2015 03:11, schrieb Dennis E. Hamilton: I can speak to the specific case. The desire is to adopt Qt as the best-choice, most-cross-platform GUI framework for Corinthia on the desktop. The non-commercial, open-source license for Qt is LGPL/GPL. See

Re: Permissive UI Libraries

Tk is a bit difficult to make not look like motif. It can be made look modern, no question, but it takes effort. And the lack of interest in the recent years made it a bit outdated with regards to accessibility and i18n. No question, you can fix all those. But is that a good base for an apache

Re: [VOTE] Release Apache Groovy 2.4.5-incubating

Am 21.09.2015 01:17, schrieb Justin Mclean: [...] Some other things you may want to consider: - The convenience binaries are missing incubating from their name. so far we have not done this, because our pre-apache binaries did not have the incubating. It produces a problem for things, that au

Re: [VOTE] Release Apache Groovy 2.4.5-incubating

Am 21.09.2015 13:29, schrieb Paul King: On Mon, Sep 21, 2015 at 3:37 PM, Jochen Theodorou wrote: Am 21.09.2015 01:17, schrieb Justin Mclean: [...] - The file LineColumnCheck.txt looks like it's source code and is missing an header. Is it Apache licensed or generated? The file pro

Re: Namespacing of subproject Docker images vs. Incubator policy

Only partially related to the namespacing problem... But does somebody here know who to contact if I wanted to have a docker image on https://hub.docker.com/u/apache/ ? bye Jochen On 29.08.2016 01:21, Mike Jumper wrote: Hello all, We, Apache Guacamole (incubating), would like to migrate our

Re: Namespacing of subproject Docker images vs. Incubator policy

thx On 01.09.2016 21:04, John D. Ament wrote: Reach out to infra. You can create a JIRA ticket. John On Thu, Sep 1, 2016 at 2:52 PM Jochen Theodorou wrote: Only partially related to the namespacing problem... But does somebody here know who to contact if I wanted to have a docker image

Re: [DISCUSS] Apache NetBeans Incubator Proposal

On 16.09.2016 00:36, Geertjan Wielenga wrote: [...] Public servers: - www.netbeans.org: ... - hg.netbeans.org: ... - deadlock.netbeans.org: ... - bits.netbeans.org: ... - updates.netbeans.org: ... - statistics.netbeans.org: ... - plugins.netbeans.org: ... - forums.netbenas.org: ... - services.net

Re: [DISCUSS] Apache NetBeans Incubator Proposal

On 17.09.2016 10:23, Geertjan Wielenga wrote: Nightly builds is all that's needed, indeed, no one needs to announce them, they should simply be available. Agreed it's important to distinguish between nightly builds and official releases, that's exactly how NetBeans works currently. The #1 require

Re: [DISCUSS] Apache NetBeans Incubator Proposal

Hi, I actually have a question regarding the plugins. Maybe I missed it in the discussion so far, but what will happen with all of those? I mean some are part of the binary download by default. Will they all move to apache license and then be hosted at apache if possible too, or will this bec

Re: [DISCUSS] Apache NetBeans Incubator Proposal

On 24.09.2016 05:34, Wade Chandler wrote: [...] I ask these obvious rhetorical questions to get to this point: Would it be feasible for NetBeans to succeed among competing projects with such a stipulation that all hosted or distributed plugins be contributed to Apache or licensed the same? Withou

Re: [DISCUSS] Apache NetBeans Incubator Proposal

On 24.09.2016 15:10, Geertjan Wielenga wrote: On Sat, Sep 24, 2016 at 2:59 PM, Jochen Theodorou For me the problem is that without plugins you have only the bare plattform and no IDE. No, that's not true at all. The NetBeans plugins are of various kinds. There are plugins that are list

Re: [DISCUSS] Apache NetBeans Incubator Proposal

On 25.09.2016 08:59, John McDonnell wrote: [...] I have contributed defect fixes for JClouds in the past, and from what I see on this project is that there's an GitHub repo that allows people to contribute PR's, but theres also a ASF repo, which the contributors actually merge in the PRs from Git

Re: Preliminary NetBeans cost findings

Hi Wade, first of all, don't worry too much at this point, having discussions and trying to grasp the scope and what we get into is very normal at this point. more comments inline... On 25.09.2016 05:03, Wade Chandler wrote: [...] Do no other Apache projects have plugins or distribution nee

Re: Preliminary NetBeans cost findings

On 26.09.2016 17:04, Bertrand Delacretaz wrote: [...] b) We vote on the NetBeans proposal without waiting, and the podling assumes the risk of having to wait for budget or technical solutions to run plugins.netbeans.org at or via the ASF. won't plugins.netbeans.org run for another few months wi

Re: [DISCUSS] Proposing Griffin for Apache incubator

just a remark on the name. Griffin is used in a lot of company names and is a family name. That may induce trademark problems, but I did not do any research on that. Well and I am not happy about Griffin and Griffon being so near together, even though the later project most likely has no trade

Re: JSON License and Apache Projects

is that library able to deal with the jdk9 module system? On 24.11.2016 02:16, James Bognar wrote: Shameless plug for Apache Juneau that has a cleanroom implementation of a JSON serializer and parser in context of a common serialization API that includes a variety of serialization languages for

Re: [VOTE] Drop incubating requirement of Maven artifacts

On 04.01.2017 07:28, Mark Struberg wrote: [...] I'm a bit surprised that groovy still uses the org.codehaus groupId, but I guess they have a deal with Ben (the former owner and thus (former?) copyright holder of 'Codehaus'). So while this will work for now I guess that even groovy will move to

Re: [VOTE] Drop incubating requirement of Maven artifacts

On 06.01.2017 17:32, Wade Chandler wrote: [] It's not a big deal YET, but http://codehaus.org is not reachable anymore. yes, Ben told me he does not want to give the domain away right now. When the time comes, he will think about donating it to the ASF. when this will be I do not know [

Re: Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]

On 09.01.2017 00:54, Niclas Hedhman wrote: [...] Probably after our next release, we will publish reusable Gradle components for the Apache release process for other Gradle based projects to benefit from. We'll see exactly how we do this. In Groovy we are working on something gradle based too,

Re: GitHub workflows?

On 06.03.2017 04:56, Niclas Hedhman wrote: Everyone, I need to get an understanding of the use of GitHub workflows on Apache projects. In GH, it is possible to comment on commits and pull requests. Are those captured by infra@ and replicated somewhere, or is this "lost data" (I suspect) in cas

Re: [PROPOSAL] Pulsar - proposal for Apache Incubation

On 26.04.2017 23:19, Joe Francis wrote: Dear Apache Incubator Community, We would like to submit the Pulsar proposal to the incubator. Our draft is available at: https://wiki.apache.org/incubator/PulsarProposal A quick overview of Pulsar: Pulsar is a highly scalable, low latency messa

Re: Project informal discussion

On 18.07.2017 02:53, Harrison & Wells wrote: # I'm just a beginner here, please ignore any stupidities So guys, you told me to discuss my project here first. Well, I have an idea of making a source code generator. There really isn't a source code generation library.And it can be done. It is reall

Re: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc2

Am 22.01.2018 um 11:01 schrieb Geertjan Wielenga: I am not sure what the point is of spending time on putting rat exclusions together if they’re simply going to be ignored when it comes to IPMC members evaluating a release. Yes, we can of course discuss those rat exclusions. No, they cannot sim

apache at bintray

Hi all, I was pointed at https://bintray.com/apache. Is that an "official" bintray account for apache? Are projects publishing convenience artifacts on bintray supposed to use that? bye Jochen - To unsubscribe, e-mail: gener

Re: [DISCUSS] Groovy Incubation proposal

Am 11.03.2015 20:08, schrieb jan i: 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. It is only 5 because we did work mostly with github pull requests. Many people just spe

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 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

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 o

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 wrote: * several writers of documentation (without committer privileges) * one or two creators of graphics (icons, or whatever, without committer privileges) * one or more organizations providin

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 reachin

Re: [DISCUSS] Groovy Incubation proposal

Am 13.03.2015 13:28, schrieb Benson Margulies: [...] This has nothing to do with the start of incubation in my view. +1 I really think this point has been made clear by every one. Is really the only discussion point about something that is supposed to happen once we are incubation? Shouldn't

Re: [DISCUSS] Groovy Incubation proposal

Am 13.03.2015 17:49, schrieb Stian Soiland-Reyes: [...] Is the wider Groovy community aware that transitioning to Apache is not done overnight? There is no guarantee this will be complete by mid-April, which to me sounds optimistic. well, once we are accepted we will communicate that. There is

Re: [DISCUSS] Groovy Incubation proposal

Am 13.03.2015 22:37, schrieb Stephen Connolly: We @ Maven will have a full dump of the Codehaus JIRA and we have a VM set up to test migration... you mean more than a JSON export lacking comments and attachements? bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: htt

Re: [DISCUSS] Groovy Incubation proposal

Am 13.03.2015 22:38, schrieb Stephen Connolly: (Disclosure Ben works for my employers, so I have slightly more ability to bend his ear. As a result I got him to agree to do two full exports from JIRA, one to let us test the process and a second when we are ready to migrate) ah ok, that explains

Re: [DISCUSS] Groovy Incubation proposal

Am 16.03.2015 09:25, schrieb Upayavira: When Stephen Connolly says ”We @ Maven will have a full dump of the Codehaus JIRA and we have a VM set up to test migration…” isn’t he implying that the Groovy issues are *included* in that? I.e. there’s not so much for you to worry about here? Even if St

Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3

Am 21.03.2015 10:47, schrieb Branko Čibej: [...] Do you happen to know exactly which versions of those files were imported? I looked at the ConcurrentHashMap implementation and compared the current version on that site: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/Concur

Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3

Am 22.03.2015 00:09, schrieb Marvin Humphrey: [...] Because "release candidate" and "RC" are specialized terms with precise meaning at Apache and because we make a strong legal distinction between "released" and "unreleased" code, this is extremely confusing. Having something named "RC" which is

Re: [GROOVY] mailing lists are ready, see you there!

Am 26.03.2015 18:16, schrieb Bertrand Delacretaz: Hi, See https://issues.apache.org/jira/browse/INFRA-9339 - to subscribe use -subscribe@groovy.a.o, and let's continue the groovy podling discussions on that dev list. not -subscribe@groovy.incubator.a.o ? bye blackdrag -

Re: You know what... Apache is just too complicated.

Am 18.05.2015 20:35, schrieb Stefan Reich: Lots of rules, Americans in the background... I don't see that it works. Why don't we spend our time just PRODUCING SOMETHING? All you'd have to do is connect programmers to projects. Simple. Why all the rules? I can give you my take: Contributors wi

Re: Groovy release and LEGAL-171

Am 08.06.2015 09:07, schrieb Sergio Fernández: Hi, my two cents without knowing in detail the issue: Could I make a clean build from a source release without that file? Without looking to the source code, I'm pretty sure it could be replaced by the right flags of the maven-javadoc-plugin...

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

Am 23.06.2015 07:16, schrieb Marvin Humphrey: [...] How am I supposed to invite all the downstream developers of the world to start integrating with my awesome feature FOO before it gets formally released when our policy makes statement like: "If the general public is being instructed to download

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

Am 24.06.2015 14:04, schrieb Marvin Humphrey: [...] What differentiates the "general public" from "developers" is whether they are aware of the conditions placed on the artifacts and thus exercising informed consent. What I don't understand is, why I am "exercising informed consent" if I read

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

Am 24.06.2015 23:32, schrieb Ross Gardler (MS OPEN TECH): For HTTPd I was referring to the assertion from Justin earlier in this thread " FWIW, httpd always had nightly tarballs available for consumption and testing." (though reading that now I wonder if he meant source tarballs - which is an e

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

Am 24.06.2015 22:32, schrieb Emmanuel Lécharny: Le 24/06/15 22:28, David Nalley a écrit : [...] More generally to the underlying issue that prompted this discussion: With the concrete example of Geode's DockerHub presence, I don't think it's acceptable: https://registry.hub.docker.com/u/apacheg

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

Am 25.06.2015 15:13, schrieb Sean Busbey: [...] If the Docker Hub page wasn't under the control of the Geode PMC, then I'd say it was a marks violation and they'd have to seek out control of it or removal. can you explain me how that is a marks violation? bye blackdrag -- Jochen "blackdrag" T

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

Am 26.06.2015 09:19, schrieb Branko Čibej: On 25.06.2015 09:17, Jochen Theodorou wrote: [...] nightly source tarballs? Is that really a thing? Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and yet it can actually run on computers! :) I was asking because whoev

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

Am 26.06.2015 11:39, schrieb Jochen Theodorou: Am 26.06.2015 09:19, schrieb Branko Čibej: On 25.06.2015 09:17, Jochen Theodorou wrote: [...] nightly source tarballs? Is that really a thing? Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and yet it can actua

Re: I still don't see your priorities

Am 04.07.2015 18:53, schrieb Stefan Reich: You wait for something to exist, and THEN you support it? How about taking something good that WANTS TO EXIST, and supporting that? Stefan, you sill don't understand that the ASF is basically a bunch of people supporting open source in their free tim

Re: I still don't see your priorities

healthy community. And if you understand all that perfectly fine, then what keeps you from gathering a few people and make a proposal? Am 04.07.2015 21:32, schrieb Stefan Reich: Basic work for TinyBrain has been done. It's been at least 3 years. Am 04.07.2015 19:26 schrieb "Jochen

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Am 13.07.2015 16:25, schrieb Paul King: [...] For binary releases: - All are missing DISCLAIMER, LICENSE and NOTICE These are all in the meta-inf directory within all the produced jars but agreed should be in the root of the zips (already true for src zip) as well. I thought having hose in ME

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Am 13.07.2015 23:00, schrieb Justin Mclean: Hi, We don't bundle the source from any of those libraries true, but we do generate sources as part of our build using ANTLR and we do bundle the class files from the ANLTR and ASM projects in some of our jars and we do bundle the jars from some of

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

Am 14.07.2015 07:26, schrieb Alex Harui: On 7/13/15, 10:05 PM, "Jochen Theodorou" wrote: then source and binary distribution have to have different NOTICE/LICENSE files? Yep, I think of it as the list of allergens in the package. If you use peanut oil to cook the raw ingredie

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Am 16.07.2015 18:49, schrieb Roman Shaposhnik: On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny wrote: Le 16/07/15 10:41, Justin Mclean a écrit : Hi, This vote passes with 4 binding "+1" votes, no "0" notes, and 2 "-1" binding votes. If you read carefully I think you find there were 3 -1

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

Am 17.07.2015 09:31, schrieb Emmanuel Lécharny: [...] Now, I'm a bit scared : why the hell can't we make it easier to cut a release at Apache for this project ? I mean, the infrastructure should not be a limitation here : we do have a CI, we most certainly can tune it to fit Groovy. that would

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

Am 23.07.2015 05:13, schrieb Ted Dunning: On Wed, Jul 22, 2015 at 6:54 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: Concerns have been raised about the people behind the actual commits, that seems to be left open ? The identity of the committers is never lost (at least t

apache binary distributions

Hi all, some of the general discussion recently made me wonder about one point with regards to binary distributions. It was pointed out, that a binary distribution of a source code release has to be handled like a release itself, and that there should be no download source of it outside of ap

Re: apache binary distributions

, "Jochen Theodorou" wrote: Hi all, some of the general discussion recently made me wonder about one point with regards to binary distributions. It was pointed out, that a binary distribution of a source code release has to be handled like a release itself, and that there should be n

Re: apache binary distributions

Am 03.08.2015 21:46, schrieb David Nalley: On Mon, Aug 3, 2015 at 5:55 AM, Jochen Theodorou wrote: Hi all, some of the general discussion recently made me wonder about one point with regards to binary distributions. It was pointed out, that a binary distribution of a source code release has

Aw: Re: Tying Dockerhub into development and release management

> Gesendet: Freitag, 08. Februar 2019 um 04:58 Uhr > Von: "Dave Fisher" > An: general@incubator.apache.org > Betreff: Re: Tying Dockerhub into development and release management [...] > > On Feb 7, 2019, at 7:51 PM, Chris Lambertus wrote: [...] > >> On Feb 7, 2019, at 6:47 PM, Justin Mclean w

Re: podling security issues

Maybe one more thing we should think about. What if there is a security issue, the response of the podling is good and the issue gets fixed very fast. And can only be fixed by a new release. But then the incubator finds issues with the release and the release issues cannot be fixed right away. I d

Re: podling security issues

for Zero Day exploits are only a small proportion of the security related fixes that get made. This is somewhat tangential to what this discussion is about. On Fri, 24 Jan 2025 at 22:34, Jochen Theodorou wrote: Maybe one more thing we should think about. What if there is a security issue, the