Re: Problematic language in our repositories

2020-11-27 Thread Jean-Baptiste Onofre
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

2020-11-27 Thread Jean-Baptiste Onofre
+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

2020-11-27 Thread Andrea Cosentino
+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

2020-11-27 Thread Andrea
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

2020-11-27 Thread Onder SEZGIN
+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

2020-11-27 Thread Nicola Ferraro
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

2020-11-27 Thread Nicola Ferraro
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
>
>