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 <[email protected]> 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 <[email protected]> 
> 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 <[email protected]> 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
>>> <[email protected]> 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
>>>> <[email protected]> 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 <[email protected]>
>>>>> 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 <[email protected]> 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 <[email protected]> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2020/11/05 17:34:25, Clebert Suconic <[email protected]>
>>>>>> 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

Reply via email to