You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Rich Bowen <rb...@apache.org> on 2020/11/05 16:14:58 UTC
ActiveMQ and problematic language
Hi, ActiveMQ friends,
As you may have heard, Red Hat recently embarked on a company-wide effort to remove problematic/unwelcoming language from code, documentation, and web presences, both upstream and downstream, related to projects that we care about, and which form critical parts of our technology stack. Camel is, of course, one of those projects.
We are joined in this effort by colleagues at a large and growing number of technology companies and organizations.
Our CTO Chris Wright blogged about this - https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language - back in June and we have been making steady - if slow - progress since then.
I'm in the process of reaching out to various projects to see what we can do to get this work done.
I was wondering if ActiveMQ is looking at this issue at all.
A lazy github search shows, of the words that we've been focusing on:
Slave
https://github.com/apache/activemq/search?q=slave
77
Master
https://github.com/apache/activemq/search?q=master
121
Whitelist
https://github.com/apache/activemq/search?q=whitelist
1
Blacklist
https://github.com/apache/activemq/search?q=blacklist
1
We've drafted a document about how one might approach this topic - https://github.com/conscious-lang/conscious-lang-docs/blob/main/recommendations.md and a faq at https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md if you'd like to read more about the "what", "why", and "how" of this project, and I'd be glad to discuss this more with any of you.
Re: ActiveMQ and problematic language
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Yes, that’s possible. I just mentioned that we need a create ticket to INFRA for that.
Regards
JB
> Le 12 nov. 2020 à 20:22, Clebert Suconic <cl...@gmail.com> a écrit :
>
> We should probably switch the dev from master to main on our repos.
>
> and have master mirroring main for some time allowing folks to update
> their scripts... (like I have a few private CI machines.. I bet other
> folks will have similar things).
>
>
>
> On Thu, Nov 12, 2020 at 11:51 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>>
>> It’s easy, but we have to ask to infra (we can’t delete the "old" master branch ourselves once "main" is there).
>>
>> Regards
>> JB
>>
>>> Le 12 nov. 2020 à 16:33, Clebert Suconic <cl...@gmail.com> a écrit :
>>>
>>> one easy change is the name of our main branch...
>>>
>>> github has switched to use main for any new repository created instead
>>> of master.
>>>
>>> Would we need Infra to make that change?
>>>
>>> On Tue, Nov 10, 2020 at 1:48 PM Clebert Suconic
>>> <cl...@gmail.com> wrote:
>>>>
>>>> I remember that thread..
>>>>
>>>>
>>>> but I think in most cases primary / backup makes more sense...
>>>>
>>>>
>>>> But I don't mind which term we choose TBH... IMO we should just stick
>>>> to primary / backup, but if somewhere specifically leader / follower
>>>> makes more sense. .why not?
>>>>
>>>>
>>>> I would leave it at the discression of the person implementing the
>>>> change. When you get your hands on it makes more sense.
>>>>
>>>>
>>>> @JB If you send a Pull Request and want an extra pair of eyes to make
>>>> sure on the changes.. let me know on this thread and i will help
>>>> reviewing it.
>>>>
>>>> On Tue, Nov 10, 2020 at 1:27 PM Christopher Shannon
>>>> <ch...@gmail.com> wrote:
>>>>>
>>>>> There was already another thread on this topic along with a Jira:
>>>>> http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html
>>>>> https://issues.apache.org/jira/browse/AMQ-7514
>>>>>
>>>>> New terms were already somewhat decided in that thread as primary/backup
>>>>> doesn't make sense in all cases. It depends on what the application is
>>>>> (leader/follower, etc)
>>>>>
>>>>> On Tue, Nov 10, 2020 at 12:05 PM Jean-Baptiste Onofre <jb...@nanthrax.net>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I agree with the terms (I think we have kind of consensus).
>>>>>>
>>>>>> I will start the change on ActiveMQ side (as I’m working on new releases
>>>>>> and updates).
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>> Le 10 nov. 2020 à 17:26, Clebert Suconic <cl...@gmail.com> a
>>>>>> écrit :
>>>>>>>
>>>>>>> What about this... lets propose the following changes:
>>>>>>>
>>>>>>> - master should become primary (we could refer to it as primary server
>>>>>> in docs)
>>>>>>> - slave should become backup (same way, we could refer to it as backup
>>>>>>> server in docs)
>>>>>>> - whitelist: allowlist
>>>>>>> - blacklist: denylist
>>>>>>>
>>>>>>> TBH: master and slave are the most used words among the list, on both
>>>>>>> activemq and artemis codebase.
>>>>>>>
>>>>>>>
>>>>>>> I'm working with my company (Red Hat) to allow time from someone on
>>>>>>> our team to work on this, and I believe we can set up someone
>>>>>>> dedicated to it early 2021 on the ActiveMQ Artemis codebase.
>>>>>>>
>>>>>>> We still need volunteers to do it on the ActiveMQ codebase....
>>>>>>>
>>>>>>>
>>>>>>> In regard to the list of names, I am not particularly strongly
>>>>>>> opinionated with the terms.. but if someone is, please suggest a
>>>>>>> different term to the list.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com>
>>>>>> wrote:
>>>>>>>>> *My* particular issue around this was not knowing what to do with
>>>>>>>>> configuration parameters and APIs.
>>>>>>>>>
>>>>>>>>> If we simply remove those, older clients, older configs would not
>>>>>> work any
>>>>>>>>> longer.
>>>>>>>>>
>>>>>>>>> Is deprecation here a valid approach? Is there consensus around it ?
>>>>>>>>
>>>>>>>> Yes, we definitely recommend that you have a published deprecation
>>>>>> plan, so that there's sufficient warning, and you don't break existing
>>>>>> installations. Exactly what that timing is, is going to vary a great deal
>>>>>> from one project to another, and only you and your users can figure that
>>>>>> out.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Clebert Suconic
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Clebert Suconic
>>>
>>>
>>>
>>> --
>>> Clebert Suconic
>>
>
>
> --
> Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Clebert Suconic <cl...@gmail.com>.
We should probably switch the dev from master to main on our repos.
and have master mirroring main for some time allowing folks to update
their scripts... (like I have a few private CI machines.. I bet other
folks will have similar things).
On Thu, Nov 12, 2020 at 11:51 AM Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> It’s easy, but we have to ask to infra (we can’t delete the "old" master branch ourselves once "main" is there).
>
> Regards
> JB
>
> > Le 12 nov. 2020 à 16:33, Clebert Suconic <cl...@gmail.com> a écrit :
> >
> > one easy change is the name of our main branch...
> >
> > github has switched to use main for any new repository created instead
> > of master.
> >
> > Would we need Infra to make that change?
> >
> > On Tue, Nov 10, 2020 at 1:48 PM Clebert Suconic
> > <cl...@gmail.com> wrote:
> >>
> >> I remember that thread..
> >>
> >>
> >> but I think in most cases primary / backup makes more sense...
> >>
> >>
> >> But I don't mind which term we choose TBH... IMO we should just stick
> >> to primary / backup, but if somewhere specifically leader / follower
> >> makes more sense. .why not?
> >>
> >>
> >> I would leave it at the discression of the person implementing the
> >> change. When you get your hands on it makes more sense.
> >>
> >>
> >> @JB If you send a Pull Request and want an extra pair of eyes to make
> >> sure on the changes.. let me know on this thread and i will help
> >> reviewing it.
> >>
> >> On Tue, Nov 10, 2020 at 1:27 PM Christopher Shannon
> >> <ch...@gmail.com> wrote:
> >>>
> >>> There was already another thread on this topic along with a Jira:
> >>> http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html
> >>> https://issues.apache.org/jira/browse/AMQ-7514
> >>>
> >>> New terms were already somewhat decided in that thread as primary/backup
> >>> doesn't make sense in all cases. It depends on what the application is
> >>> (leader/follower, etc)
> >>>
> >>> On Tue, Nov 10, 2020 at 12:05 PM Jean-Baptiste Onofre <jb...@nanthrax.net>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I agree with the terms (I think we have kind of consensus).
> >>>>
> >>>> I will start the change on ActiveMQ side (as I’m working on new releases
> >>>> and updates).
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>>> Le 10 nov. 2020 à 17:26, Clebert Suconic <cl...@gmail.com> a
> >>>> écrit :
> >>>>>
> >>>>> What about this... lets propose the following changes:
> >>>>>
> >>>>> - master should become primary (we could refer to it as primary server
> >>>> in docs)
> >>>>> - slave should become backup (same way, we could refer to it as backup
> >>>>> server in docs)
> >>>>> - whitelist: allowlist
> >>>>> - blacklist: denylist
> >>>>>
> >>>>> TBH: master and slave are the most used words among the list, on both
> >>>>> activemq and artemis codebase.
> >>>>>
> >>>>>
> >>>>> I'm working with my company (Red Hat) to allow time from someone on
> >>>>> our team to work on this, and I believe we can set up someone
> >>>>> dedicated to it early 2021 on the ActiveMQ Artemis codebase.
> >>>>>
> >>>>> We still need volunteers to do it on the ActiveMQ codebase....
> >>>>>
> >>>>>
> >>>>> In regard to the list of names, I am not particularly strongly
> >>>>> opinionated with the terms.. but if someone is, please suggest a
> >>>>> different term to the list.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com>
> >>>> wrote:
> >>>>>>> *My* particular issue around this was not knowing what to do with
> >>>>>>> configuration parameters and APIs.
> >>>>>>>
> >>>>>>> If we simply remove those, older clients, older configs would not
> >>>> work any
> >>>>>>> longer.
> >>>>>>>
> >>>>>>> Is deprecation here a valid approach? Is there consensus around it ?
> >>>>>>
> >>>>>> Yes, we definitely recommend that you have a published deprecation
> >>>> plan, so that there's sufficient warning, and you don't break existing
> >>>> installations. Exactly what that timing is, is going to vary a great deal
> >>>> from one project to another, and only you and your users can figure that
> >>>> out.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Clebert Suconic
> >>>>
> >>>>
> >>
> >>
> >>
> >> --
> >> Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
--
Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
It’s easy, but we have to ask to infra (we can’t delete the "old" master branch ourselves once "main" is there).
Regards
JB
> Le 12 nov. 2020 à 16:33, Clebert Suconic <cl...@gmail.com> a écrit :
>
> one easy change is the name of our main branch...
>
> github has switched to use main for any new repository created instead
> of master.
>
> Would we need Infra to make that change?
>
> On Tue, Nov 10, 2020 at 1:48 PM Clebert Suconic
> <cl...@gmail.com> wrote:
>>
>> I remember that thread..
>>
>>
>> but I think in most cases primary / backup makes more sense...
>>
>>
>> But I don't mind which term we choose TBH... IMO we should just stick
>> to primary / backup, but if somewhere specifically leader / follower
>> makes more sense. .why not?
>>
>>
>> I would leave it at the discression of the person implementing the
>> change. When you get your hands on it makes more sense.
>>
>>
>> @JB If you send a Pull Request and want an extra pair of eyes to make
>> sure on the changes.. let me know on this thread and i will help
>> reviewing it.
>>
>> On Tue, Nov 10, 2020 at 1:27 PM Christopher Shannon
>> <ch...@gmail.com> wrote:
>>>
>>> There was already another thread on this topic along with a Jira:
>>> http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html
>>> https://issues.apache.org/jira/browse/AMQ-7514
>>>
>>> New terms were already somewhat decided in that thread as primary/backup
>>> doesn't make sense in all cases. It depends on what the application is
>>> (leader/follower, etc)
>>>
>>> On Tue, Nov 10, 2020 at 12:05 PM Jean-Baptiste Onofre <jb...@nanthrax.net>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I agree with the terms (I think we have kind of consensus).
>>>>
>>>> I will start the change on ActiveMQ side (as I’m working on new releases
>>>> and updates).
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>> Le 10 nov. 2020 à 17:26, Clebert Suconic <cl...@gmail.com> a
>>>> écrit :
>>>>>
>>>>> What about this... lets propose the following changes:
>>>>>
>>>>> - master should become primary (we could refer to it as primary server
>>>> in docs)
>>>>> - slave should become backup (same way, we could refer to it as backup
>>>>> server in docs)
>>>>> - whitelist: allowlist
>>>>> - blacklist: denylist
>>>>>
>>>>> TBH: master and slave are the most used words among the list, on both
>>>>> activemq and artemis codebase.
>>>>>
>>>>>
>>>>> I'm working with my company (Red Hat) to allow time from someone on
>>>>> our team to work on this, and I believe we can set up someone
>>>>> dedicated to it early 2021 on the ActiveMQ Artemis codebase.
>>>>>
>>>>> We still need volunteers to do it on the ActiveMQ codebase....
>>>>>
>>>>>
>>>>> In regard to the list of names, I am not particularly strongly
>>>>> opinionated with the terms.. but if someone is, please suggest a
>>>>> different term to the list.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com>
>>>> wrote:
>>>>>>> *My* particular issue around this was not knowing what to do with
>>>>>>> configuration parameters and APIs.
>>>>>>>
>>>>>>> If we simply remove those, older clients, older configs would not
>>>> work any
>>>>>>> longer.
>>>>>>>
>>>>>>> Is deprecation here a valid approach? Is there consensus around it ?
>>>>>>
>>>>>> Yes, we definitely recommend that you have a published deprecation
>>>> plan, so that there's sufficient warning, and you don't break existing
>>>> installations. Exactly what that timing is, is going to vary a great deal
>>>> from one project to another, and only you and your users can figure that
>>>> out.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Clebert Suconic
>>>>
>>>>
>>
>>
>>
>> --
>> Clebert Suconic
>
>
>
> --
> Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Clebert Suconic <cl...@gmail.com>.
one easy change is the name of our main branch...
github has switched to use main for any new repository created instead
of master.
Would we need Infra to make that change?
On Tue, Nov 10, 2020 at 1:48 PM Clebert Suconic
<cl...@gmail.com> wrote:
>
> I remember that thread..
>
>
> but I think in most cases primary / backup makes more sense...
>
>
> But I don't mind which term we choose TBH... IMO we should just stick
> to primary / backup, but if somewhere specifically leader / follower
> makes more sense. .why not?
>
>
> I would leave it at the discression of the person implementing the
> change. When you get your hands on it makes more sense.
>
>
> @JB If you send a Pull Request and want an extra pair of eyes to make
> sure on the changes.. let me know on this thread and i will help
> reviewing it.
>
> On Tue, Nov 10, 2020 at 1:27 PM Christopher Shannon
> <ch...@gmail.com> wrote:
> >
> > There was already another thread on this topic along with a Jira:
> > http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html
> > https://issues.apache.org/jira/browse/AMQ-7514
> >
> > New terms were already somewhat decided in that thread as primary/backup
> > doesn't make sense in all cases. It depends on what the application is
> > (leader/follower, etc)
> >
> > On Tue, Nov 10, 2020 at 12:05 PM Jean-Baptiste Onofre <jb...@nanthrax.net>
> > wrote:
> >
> > > Hi,
> > >
> > > I agree with the terms (I think we have kind of consensus).
> > >
> > > I will start the change on ActiveMQ side (as I’m working on new releases
> > > and updates).
> > >
> > > Regards
> > > JB
> > >
> > > > Le 10 nov. 2020 à 17:26, Clebert Suconic <cl...@gmail.com> a
> > > écrit :
> > > >
> > > > What about this... lets propose the following changes:
> > > >
> > > > - master should become primary (we could refer to it as primary server
> > > in docs)
> > > > - slave should become backup (same way, we could refer to it as backup
> > > > server in docs)
> > > > - whitelist: allowlist
> > > > - blacklist: denylist
> > > >
> > > > TBH: master and slave are the most used words among the list, on both
> > > > activemq and artemis codebase.
> > > >
> > > >
> > > > I'm working with my company (Red Hat) to allow time from someone on
> > > > our team to work on this, and I believe we can set up someone
> > > > dedicated to it early 2021 on the ActiveMQ Artemis codebase.
> > > >
> > > > We still need volunteers to do it on the ActiveMQ codebase....
> > > >
> > > >
> > > > In regard to the list of names, I am not particularly strongly
> > > > opinionated with the terms.. but if someone is, please suggest a
> > > > different term to the list.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
> > > >>
> > > >>
> > > >>
> > > >> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com>
> > > wrote:
> > > >>> *My* particular issue around this was not knowing what to do with
> > > >>> configuration parameters and APIs.
> > > >>>
> > > >>> If we simply remove those, older clients, older configs would not
> > > work any
> > > >>> longer.
> > > >>>
> > > >>> Is deprecation here a valid approach? Is there consensus around it ?
> > > >>
> > > >> Yes, we definitely recommend that you have a published deprecation
> > > plan, so that there's sufficient warning, and you don't break existing
> > > installations. Exactly what that timing is, is going to vary a great deal
> > > from one project to another, and only you and your users can figure that
> > > out.
> > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> > >
> > >
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Clebert Suconic <cl...@gmail.com>.
I remember that thread..
but I think in most cases primary / backup makes more sense...
But I don't mind which term we choose TBH... IMO we should just stick
to primary / backup, but if somewhere specifically leader / follower
makes more sense. .why not?
I would leave it at the discression of the person implementing the
change. When you get your hands on it makes more sense.
@JB If you send a Pull Request and want an extra pair of eyes to make
sure on the changes.. let me know on this thread and i will help
reviewing it.
On Tue, Nov 10, 2020 at 1:27 PM Christopher Shannon
<ch...@gmail.com> wrote:
>
> There was already another thread on this topic along with a Jira:
> http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html
> https://issues.apache.org/jira/browse/AMQ-7514
>
> New terms were already somewhat decided in that thread as primary/backup
> doesn't make sense in all cases. It depends on what the application is
> (leader/follower, etc)
>
> On Tue, Nov 10, 2020 at 12:05 PM Jean-Baptiste Onofre <jb...@nanthrax.net>
> wrote:
>
> > Hi,
> >
> > I agree with the terms (I think we have kind of consensus).
> >
> > I will start the change on ActiveMQ side (as I’m working on new releases
> > and updates).
> >
> > Regards
> > JB
> >
> > > Le 10 nov. 2020 à 17:26, Clebert Suconic <cl...@gmail.com> a
> > écrit :
> > >
> > > What about this... lets propose the following changes:
> > >
> > > - master should become primary (we could refer to it as primary server
> > in docs)
> > > - slave should become backup (same way, we could refer to it as backup
> > > server in docs)
> > > - whitelist: allowlist
> > > - blacklist: denylist
> > >
> > > TBH: master and slave are the most used words among the list, on both
> > > activemq and artemis codebase.
> > >
> > >
> > > I'm working with my company (Red Hat) to allow time from someone on
> > > our team to work on this, and I believe we can set up someone
> > > dedicated to it early 2021 on the ActiveMQ Artemis codebase.
> > >
> > > We still need volunteers to do it on the ActiveMQ codebase....
> > >
> > >
> > > In regard to the list of names, I am not particularly strongly
> > > opinionated with the terms.. but if someone is, please suggest a
> > > different term to the list.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
> > >>
> > >>
> > >>
> > >> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com>
> > wrote:
> > >>> *My* particular issue around this was not knowing what to do with
> > >>> configuration parameters and APIs.
> > >>>
> > >>> If we simply remove those, older clients, older configs would not
> > work any
> > >>> longer.
> > >>>
> > >>> Is deprecation here a valid approach? Is there consensus around it ?
> > >>
> > >> Yes, we definitely recommend that you have a published deprecation
> > plan, so that there's sufficient warning, and you don't break existing
> > installations. Exactly what that timing is, is going to vary a great deal
> > from one project to another, and only you and your users can figure that
> > out.
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
> >
--
Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Christopher Shannon <ch...@gmail.com>.
There was already another thread on this topic along with a Jira:
http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html
https://issues.apache.org/jira/browse/AMQ-7514
New terms were already somewhat decided in that thread as primary/backup
doesn't make sense in all cases. It depends on what the application is
(leader/follower, etc)
On Tue, Nov 10, 2020 at 12:05 PM Jean-Baptiste Onofre <jb...@nanthrax.net>
wrote:
> Hi,
>
> I agree with the terms (I think we have kind of consensus).
>
> I will start the change on ActiveMQ side (as I’m working on new releases
> and updates).
>
> Regards
> JB
>
> > Le 10 nov. 2020 à 17:26, Clebert Suconic <cl...@gmail.com> a
> écrit :
> >
> > What about this... lets propose the following changes:
> >
> > - master should become primary (we could refer to it as primary server
> in docs)
> > - slave should become backup (same way, we could refer to it as backup
> > server in docs)
> > - whitelist: allowlist
> > - blacklist: denylist
> >
> > TBH: master and slave are the most used words among the list, on both
> > activemq and artemis codebase.
> >
> >
> > I'm working with my company (Red Hat) to allow time from someone on
> > our team to work on this, and I believe we can set up someone
> > dedicated to it early 2021 on the ActiveMQ Artemis codebase.
> >
> > We still need volunteers to do it on the ActiveMQ codebase....
> >
> >
> > In regard to the list of names, I am not particularly strongly
> > opinionated with the terms.. but if someone is, please suggest a
> > different term to the list.
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
> >>
> >>
> >>
> >> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com>
> wrote:
> >>> *My* particular issue around this was not knowing what to do with
> >>> configuration parameters and APIs.
> >>>
> >>> If we simply remove those, older clients, older configs would not
> work any
> >>> longer.
> >>>
> >>> Is deprecation here a valid approach? Is there consensus around it ?
> >>
> >> Yes, we definitely recommend that you have a published deprecation
> plan, so that there's sufficient warning, and you don't break existing
> installations. Exactly what that timing is, is going to vary a great deal
> from one project to another, and only you and your users can figure that
> out.
> >
> >
> >
> > --
> > Clebert Suconic
>
>
Re: ActiveMQ and problematic language
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi,
I agree with the terms (I think we have kind of consensus).
I will start the change on ActiveMQ side (as I’m working on new releases and updates).
Regards
JB
> Le 10 nov. 2020 à 17:26, Clebert Suconic <cl...@gmail.com> a écrit :
>
> What about this... lets propose the following changes:
>
> - master should become primary (we could refer to it as primary server in docs)
> - slave should become backup (same way, we could refer to it as backup
> server in docs)
> - whitelist: allowlist
> - blacklist: denylist
>
> TBH: master and slave are the most used words among the list, on both
> activemq and artemis codebase.
>
>
> I'm working with my company (Red Hat) to allow time from someone on
> our team to work on this, and I believe we can set up someone
> dedicated to it early 2021 on the ActiveMQ Artemis codebase.
>
> We still need volunteers to do it on the ActiveMQ codebase....
>
>
> In regard to the list of names, I am not particularly strongly
> opinionated with the terms.. but if someone is, please suggest a
> different term to the list.
>
>
>
>
>
>
>
> On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
>>
>>
>>
>> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com> wrote:
>>> *My* particular issue around this was not knowing what to do with
>>> configuration parameters and APIs.
>>>
>>> If we simply remove those, older clients, older configs would not work any
>>> longer.
>>>
>>> Is deprecation here a valid approach? Is there consensus around it ?
>>
>> Yes, we definitely recommend that you have a published deprecation plan, so that there's sufficient warning, and you don't break existing installations. Exactly what that timing is, is going to vary a great deal from one project to another, and only you and your users can figure that out.
>
>
>
> --
> Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Clebert Suconic <cl...@gmail.com>.
What about this... lets propose the following changes:
- master should become primary (we could refer to it as primary server in docs)
- slave should become backup (same way, we could refer to it as backup
server in docs)
- whitelist: allowlist
- blacklist: denylist
TBH: master and slave are the most used words among the list, on both
activemq and artemis codebase.
I'm working with my company (Red Hat) to allow time from someone on
our team to work on this, and I believe we can set up someone
dedicated to it early 2021 on the ActiveMQ Artemis codebase.
We still need volunteers to do it on the ActiveMQ codebase....
In regard to the list of names, I am not particularly strongly
opinionated with the terms.. but if someone is, please suggest a
different term to the list.
On Mon, Nov 9, 2020 at 3:38 PM Rich Bowen <rb...@apache.org> wrote:
>
>
>
> On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com> wrote:
> > *My* particular issue around this was not knowing what to do with
> > configuration parameters and APIs.
> >
> > If we simply remove those, older clients, older configs would not work any
> > longer.
> >
> > Is deprecation here a valid approach? Is there consensus around it ?
>
> Yes, we definitely recommend that you have a published deprecation plan, so that there's sufficient warning, and you don't break existing installations. Exactly what that timing is, is going to vary a great deal from one project to another, and only you and your users can figure that out.
--
Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Rich Bowen <rb...@apache.org>.
On 2020/11/05 17:34:25, Clebert Suconic <cl...@gmail.com> wrote:
> *My* particular issue around this was not knowing what to do with
> configuration parameters and APIs.
>
> If we simply remove those, older clients, older configs would not work any
> longer.
>
> Is deprecation here a valid approach? Is there consensus around it ?
Yes, we definitely recommend that you have a published deprecation plan, so that there's sufficient warning, and you don't break existing installations. Exactly what that timing is, is going to vary a great deal from one project to another, and only you and your users can figure that out.
Re: ActiveMQ and problematic language
Posted by "michael.andre.pearce" <mi...@me.com.INVALID>.
I think we will def need a period of transition. So we need a few releases with both new apis and configs alongside the old ones in deprecated state, before we can fully remove.Sent from my Galaxy
-------- Original message --------From: Clebert Suconic <cl...@gmail.com> Date: 05/11/2020 17:35 (GMT+00:00) To: dev@activemq.apache.org Subject: Re: ActiveMQ and problematic language *My* particular issue around this was not knowing what to do withconfiguration parameters and APIs.If we simply remove those, older clients, older configs would not work anylonger.Is deprecation here a valid approach? Is there consensus around it ?On Thu, Nov 5, 2020 at 11:15 AM Rich Bowen <rb...@apache.org> wrote:> Hi, ActiveMQ friends,>> As you may have heard, Red Hat recently embarked on a company-wide effort> to remove problematic/unwelcoming language from code, documentation, and> web presences, both upstream and downstream, related to projects that we> care about, and which form critical parts of our technology stack. Camel> is, of course, one of those projects.>> We are joined in this effort by colleagues at a large and growing number> of technology companies and organizations.>> Our CTO Chris Wright blogged about this -> https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language> - back in June and we have been making steady - if slow - progress since> then.>> I'm in the process of reaching out to various projects to see what we can> do to get this work done.>> I was wondering if ActiveMQ is looking at this issue at all.>> A lazy github search shows, of the words that we've been focusing on:>> Slave> https://github.com/apache/activemq/search?q=slave> 77>> Master> https://github.com/apache/activemq/search?q=master> 121>> Whitelist> https://github.com/apache/activemq/search?q=whitelist> 1>> Blacklist> https://github.com/apache/activemq/search?q=blacklist> 1>> We've drafted a document about how one might approach this topic -> https://github.com/conscious-lang/conscious-lang-docs/blob/main/recommendations.md> and a faq at> https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md if> you'd like to read more about the "what", "why", and "how" of this project,> and I'd be glad to discuss this more with any of you.>-- Clebert Suconic
Re: ActiveMQ and problematic language
Posted by Clebert Suconic <cl...@gmail.com>.
*My* particular issue around this was not knowing what to do with
configuration parameters and APIs.
If we simply remove those, older clients, older configs would not work any
longer.
Is deprecation here a valid approach? Is there consensus around it ?
On Thu, Nov 5, 2020 at 11:15 AM Rich Bowen <rb...@apache.org> wrote:
> Hi, ActiveMQ friends,
>
> As you may have heard, Red Hat recently embarked on a company-wide effort
> to remove problematic/unwelcoming language from code, documentation, and
> web presences, both upstream and downstream, related to projects that we
> care about, and which form critical parts of our technology stack. Camel
> is, of course, one of those projects.
>
> We are joined in this effort by colleagues at a large and growing number
> of technology companies and organizations.
>
> Our CTO Chris Wright blogged about this -
> https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language
> - back in June and we have been making steady - if slow - progress since
> then.
>
> I'm in the process of reaching out to various projects to see what we can
> do to get this work done.
>
> I was wondering if ActiveMQ is looking at this issue at all.
>
> A lazy github search shows, of the words that we've been focusing on:
>
> Slave
> https://github.com/apache/activemq/search?q=slave
> 77
>
> Master
> https://github.com/apache/activemq/search?q=master
> 121
>
> Whitelist
> https://github.com/apache/activemq/search?q=whitelist
> 1
>
> Blacklist
> https://github.com/apache/activemq/search?q=blacklist
> 1
>
> We've drafted a document about how one might approach this topic -
> https://github.com/conscious-lang/conscious-lang-docs/blob/main/recommendations.md
> and a faq at
> https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md if
> you'd like to read more about the "what", "why", and "how" of this project,
> and I'd be glad to discuss this more with any of you.
>
--
Clebert Suconic