activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arthur Naseef <...@amlinv.com>
Subject Re: Webconsole deprecation
Date Thu, 26 Apr 2018 17:30:37 GMT
Hey Chris - I looked for you in the IRC channel but didn't see you (sorry
if I missed you).

I'd like to understand the concerns and talk to you about addressing them.

Can you either enumerate the big concerns here, or give me a shout?  IRC or
email work.

Art


On Thu, Apr 26, 2018 at 10:28 AM, Christopher Shannon <
christopher.l.shannon@gmail.com> wrote:

> Paul,
>
> Yes it is mostly a people problem but that doesn't make it any less of
> a problem.  It's still a big problem. Apache is a volunteer
> organization.  You can't make anyone support something they don't want
> to.  The reality is that no one wants to maintain it, there's been
> several years of evidence to prove that.
>
> I would rather deprecate something and make it known it's not
> maintained so at least people are aware of the risks involved with
> using unmaintained software versus leaving things status quo and
> pretending everything is fine when it isn't.
>
> On Thu, Apr 26, 2018 at 1:19 PM, Paul Gale <paul.n.gale@gmail.com> wrote:
> > If the definition of 'the problem' is that no committers are willing to
> > maintain the web console then that's an internal leadership problem of
> the
> > group. Please don't try to 'fix' that by making it a problem for end
> users
> > by deprecating/removing it. Why not address the problem of lack of
> interest
> > from a leadership perspective?
> >
> > So, if at any time in the future some popular feature/component of
> ActiveMQ
> > stops being maintained owing to lack of interest by committers, should
> that
> > necessarily qualify it to become deprecated/removed? I don't think so. As
> > an end user with hundreds of deployed instances of ActiveMQ in Production
> > it would be very annoying if the web console were to be deprecated. Let's
> > face it when someone wants it to be 'deprecated' they just want to move
> it
> > one step closer to be being 'removed.' As an end user we've been screwed
> > over a few times in the past with such decisions were made on a whim
> > because something was convenient for committers; changing the use of
> > activemq-all.jar springs to mind - that was big for us. Each time these
> > incidents happen it only illustrates further that some committers are out
> > of touch with the user base, or perhaps they're not but have a different
> > agenda.
> >
> > AFAIK there doesn't appear to be a technical impediment for supporting
> the
> > web console, rather it seems to be a political one. It's a people
> problem.
> >
> >
> > Thanks,
> > Paul
> >
> > On Thu, Apr 26, 2018 at 12:52 PM, Justin Bertram <jbertram@apache.org>
> > wrote:
> >
> >> > What changed since last opening this question?
> >>
> >> My understanding (based on Chris' email) is that nothing has changed
> since
> >> the last discussion, and that is precisely the problem.
> >>
> >> > What problems are being solved by removing it?
> >>
> >> I believe Chris is proposing that it be deprecated and disabled by
> default
> >> rather than removed. The problem solved by this is ostensibly that users
> >> would understand it is no longer maintained (i.e. de facto truth) and
> that
> >> there are risks associated with enabling it.
> >>
> >> > How will the important functions provided by the WebConsole be
> provided
> >> to end-users?
> >>
> >> Wouldn't users who want the functions provided by the web console could
> >> still have them by enabling it (assuming they're willing to take the
> >> associated risks)?
> >>
> >>
> >> Justin
> >>
> >> On Thu, Apr 26, 2018 at 11:40 AM, Arthur Naseef <art@amlinv.com> wrote:
> >>
> >> > The ActiveMQ WebConsole fills a very important role in the solution.
> >> >
> >> > So here are the questions coming to mind when reading the request for
> >> > deprecation:
> >> >
> >> >    1. What changed since last opening this question?
> >> >    2. What problems are being solved by removing it?
> >> >    3. How will the important functions provided by the WebConsole be
> >> >    provided to end-users?
> >> >
> >> > Here are some of the important functions:
> >> >
> >> >    - Quick view of broker status after initial installation of broker,
> >> >    helpful for new installations and for those learning to use the
> broker
> >> > for
> >> >    the first time.
> >> >       - Greatly reduces time to get started using the broker
> effectively
> >> >    - Zero configuration, out-of-the-box Management Console
> >> >    - Access to critical broker details, including:
> >> >       - memory and store usage
> >> >       - listing of queues and topics
> >> >       - viewing connections to the broker
> >> >       - viewing NOB connections
> >> >    - Handy test utilities
> >> >       - Browse queue contents
> >> >       - Send messages
> >> >    - Easy to instruct users on it's use to obtain important details
> when
> >> >    providing remote support
> >> >
> >> > It would be great to have a meaningful discussion that moves us
> forward.
> >> > Right now, this feels to me like a simple re-hash of the old
> discussion.
> >> >
> >> > Art
> >> >
> >> >
> >> > On Thu, Apr 26, 2018 at 7:33 AM, Christopher Shannon <
> >> > christopher.l.shannon@gmail.com> wrote:
> >> >
> >> > > I think it's time to have the yearly web console deprecation or
> >> > > removal conversation.
> >> > >
> >> > > I realize this conversation has been had multiple times in the past
> >> > > already.  However, since those conversations have taken place there
> >> > > has still been no effort by anyone to maintain the webconsole for
> >> > > several years.  There continues to be reported bugs against the web
> >> > > console in jira and they are ignored.  People also submit PRs to
> >> > > improve the webconsole and they are ignored.
> >> > >
> >> > > In the past there has been a lot of pushback against outright
> removal
> >> > > of the webconsole because there are people who find it useful.  I
> >> > > think that is fair so maybe a better approach would be to go the
> >> > > LevelDB route.
> >> > >
> >> > > Perhaps we could just make a note on the website that it is not
> >> > > maintained anymore and is deprecated (and also disable it by
> default)
> >> > > but still include it so users have the option to turn it on if they
> >> > > want?
> >> > >
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message