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

Reply via email to