Re: Problematic language in our repositories
Fully agree, and I have to same concern in other projects (Karaf, ActiveMQ, …). 1. These are technical terms without any "allusion" 2. I don’t like with "company" policy are pushed to open source project. Of course, it can be openly discussed. Regards JB > Le 27 nov. 2020 à 19:03, Onder SEZGIN a écrit : > > +1 to Guillaume. > > I would not like to act like Camus or Sartre on these kinds of matters, to > me, it is simple, if you think there is barrier, then there is. Overall > meritocracy is covering all these kinds matters and embraceful enough for > anything. > And these are technical terms. > Changing language or phylosophical meta or whatever we call them would > never ever solve such kind of problem. Of course it is an act. History will > live forever with all its problem bringing to today unless erased from > everybody's minds. > Keeping short and sweet hopefully, > > I personally see no reason. > > My 2 cents.. > > Cheers > > On Tue, 10 Nov 2020, 13:16 Maria Arias de Reyna Dominguez, < > maria...@redhat.com> wrote: > >> On Mon, Nov 9, 2020 at 10:14 PM Rich Bowen wrote: >>> >>> >>> >>> On 2020/11/09 12:49:43, Guillaume Nodet wrote: Not really. Those are technical terms, and I don't really see any >> benefits in changing them. >>> >>> I would encourage you to read the various documents at >> https://github.com/conscious-lang/conscious-lang-docs regarding the >> benefits in changing them. >>> >>> In short, the benefit is 1) removing barriers to new contributors who >> feel marginalized by the terms and 2) objectively clearer language to >> explain those technical terms. >>> >> >> If I may... I know I'm fairly new in Camel, but it's true that >> language creates conscious and subconscious barriers. >> >> As white-ish I can't relate with the issues with white/black lists and >> master/slave. But I can understand them because when the language used >> is "too macho" I tend to be repelled to interact further. This is >> usually not a conscious thing I do, but there's some kind of alarm >> that starts somewhere in my head telling me it is not a safe space for >> me, that people using that language usually are people that hate and >> denigrate women and I am not going to be accepted as an equal. >> >> So, even if I don't feel bad reading those words, I can understand why >> other people may feel bad and don't feel comfortable mingling with the >> rest of us. >> >> Changing those words is an easy step for us, there's no real change in >> the technology behind, there's nothing that will fundamentally change >> for us. We just use a synonym and that's it. >> >> But this change may attract other developers we are repelling right now. >> >> +1 for me >> >> Cheers! >> María. >> >>
Re: [VOTE] Release Apache Camel-kafka-connector 0.6.1
+1 (binding) Regards JB > Le 27 nov. 2020 à 23:24, Andrea a écrit : > > Hello all, > > This is a vote to release Apache Camel-kafka-connector 0.6.1 > Staging repository: > https://repository.apache.org/content/repositories/orgapachecamel-1262 > > Tag: > https://gitbox.apache.org/repos/asf?p=camel-kafka-connector.git;a=tag;h=refs/tags/camel-kafka-connector-0.6.1 > > Bug fix release and backport of a fix to make the catalog work on windows > > Please test this release candidate and cast your vote. > [ ] +1 Release the binary as Apache Camel-kafka-connector 0.6.1 > [ ] -1 Veto the release (provide specific comments) > > The vote is open for at least 48 hours. > > Thanks, > Andrea.
Re: [VOTE] Release Apache Camel-kafka-connector 0.6.1
+1 (binding) Thanks Andrea Il ven 27 nov 2020, 23:25 Andrea ha scritto: > Hello all, > > This is a vote to release Apache Camel-kafka-connector 0.6.1 > Staging repository: > https://repository.apache.org/content/repositories/orgapachecamel-1262 > > Tag: > > https://gitbox.apache.org/repos/asf?p=camel-kafka-connector.git;a=tag;h=refs/tags/camel-kafka-connector-0.6.1 > > Bug fix release and backport of a fix to make the catalog work on windows > > Please test this release candidate and cast your vote. > [ ] +1 Release the binary as Apache Camel-kafka-connector 0.6.1 > [ ] -1 Veto the release (provide specific comments) > > The vote is open for at least 48 hours. > > Thanks, > Andrea. >
[VOTE] Release Apache Camel-kafka-connector 0.6.1
Hello all, This is a vote to release Apache Camel-kafka-connector 0.6.1 Staging repository: https://repository.apache.org/content/repositories/orgapachecamel-1262 Tag: https://gitbox.apache.org/repos/asf?p=camel-kafka-connector.git;a=tag;h=refs/tags/camel-kafka-connector-0.6.1 Bug fix release and backport of a fix to make the catalog work on windows Please test this release candidate and cast your vote. [ ] +1 Release the binary as Apache Camel-kafka-connector 0.6.1 [ ] -1 Veto the release (provide specific comments) The vote is open for at least 48 hours. Thanks, Andrea.
Re: Problematic language in our repositories
+1 to Guillaume. I would not like to act like Camus or Sartre on these kinds of matters, to me, it is simple, if you think there is barrier, then there is. Overall meritocracy is covering all these kinds matters and embraceful enough for anything. And these are technical terms. Changing language or phylosophical meta or whatever we call them would never ever solve such kind of problem. Of course it is an act. History will live forever with all its problem bringing to today unless erased from everybody's minds. Keeping short and sweet hopefully, I personally see no reason. My 2 cents.. Cheers On Tue, 10 Nov 2020, 13:16 Maria Arias de Reyna Dominguez, < maria...@redhat.com> wrote: > On Mon, Nov 9, 2020 at 10:14 PM Rich Bowen wrote: > > > > > > > > On 2020/11/09 12:49:43, Guillaume Nodet wrote: > > > Not really. Those are technical terms, and I don't really see any > benefits > > > in changing them. > > > > I would encourage you to read the various documents at > https://github.com/conscious-lang/conscious-lang-docs regarding the > benefits in changing them. > > > > In short, the benefit is 1) removing barriers to new contributors who > feel marginalized by the terms and 2) objectively clearer language to > explain those technical terms. > > > > If I may... I know I'm fairly new in Camel, but it's true that > language creates conscious and subconscious barriers. > > As white-ish I can't relate with the issues with white/black lists and > master/slave. But I can understand them because when the language used > is "too macho" I tend to be repelled to interact further. This is > usually not a conscious thing I do, but there's some kind of alarm > that starts somewhere in my head telling me it is not a safe space for > me, that people using that language usually are people that hate and > denigrate women and I am not going to be accepted as an equal. > > So, even if I don't feel bad reading those words, I can understand why > other people may feel bad and don't feel comfortable mingling with the > rest of us. > > Changing those words is an easy step for us, there's no real change in > the technology behind, there's nothing that will fundamentally change > for us. We just use a synonym and that's it. > > But this change may attract other developers we are repelling right now. > > +1 for me > > Cheers! > María. > >
[ANNOUNCEMENT] Apache Camel K 1.2.1 released
The Camel community announces the immediate availability of Apache Camel K 1.2.1. This release was needed to fix issues that arised after the release of 1.2.0. You can find more information in the release notes[1]. The artifacts are published and ready for you to download either from the Apache mirrors or from the Github repository [1]. Many thanks to all who made this release possible. On behalf of the Camel PMC, Nicola Ferraro [1] https://github.com/apache/camel-k/releases/tag/v1.2.1
Re: [VOTE] Release Apache Camel K 1.2.1
Hi, The vote passes with the following results: 7 +1 binding votes (Claus Ibsen, Andrea Cosentino, Alexandre Gallice, Luca Burgazzoli, Omar Al-Safi, Zoran Regvart, Nicola Ferraro) 1 +1 non-binding (Otavio Rodolfo Piske) I will publish the artifacts shortly and will follow up with an announcement email. Thanks to everyone who participated in this vote. Nicola Ferraro On Fri, Nov 27, 2020 at 6:02 AM Jean-Baptiste Onofre wrote: > +1 (binding) > > Regards > JB > > > Le 23 nov. 2020 à 17:27, Nicola Ferraro a écrit : > > > > Hello all: > > > > This is a vote to release Apache Camel K 1.2.1. > > > > This release contains mainly bug fixes on Kamelets usage. More details on > > the release notes: > > https://github.com/apache/camel-k/issues/1823#issuecomment-732243417 > > > > Camel K staging repository: > https://dist.apache.org/repos/dist/dev/camel/ > > camel-k/1.2.1/ > > Camel K Tag: https://gitbox.apache.org/repos/asf?p=camel-k > > .git;a=shortlog;h=refs/tags/v1.2.1 > > > > Staging container image repository: > https://hub.docker.com/r/camelk/camel-k > > /tags > > > > It's possible to install all staging artifacts with a single command: > > kamel install --operator-image=camelk/camel-k:1.2.1 --olm=false > > > > Please test this release candidate and cast your vote. > > > > [ ] +1 Release the binary as Apache Camel K 1.2.1 > > [ ] -1 Veto the release (provide specific comments) > > > > The vote is open for at least 72 hours. > > > > Thanks, > > Nicola Ferraro > >