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 < [email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 < > >> > [email protected]> 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? > >> > > > >> > > >> >
