activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: [POLL] - Remove the old ActiveMQ Console
Date Tue, 21 Jan 2014 19:30:56 GMT

On Jan 21, 2014, at 1:15 PM, Jon Anstey <janstey@gmail.com> wrote:

> So even skinning hawtio to be ASF compliant is not enough now??? Telling
> the hawtio devs to give all activemq related code over is WAY overzeolous
> IMHO. There are no ASF rules that say this must be done.
> 
> I consider working with other open source communities to be a sign of a
> healthy community, not the other way around as you put it. Apache
> communities ARE NOT and SHOULD NOT be silos.

I COMPLETELY support working with other open source communities.  I’m also completely in
support for working with other closed source communities.   If other communities have needs
from ActiveMQ such as new API’s, new functionality, etc… I’m more than happy to work
with them to make sure what we provide can meet their needs.   Better yet, I’d be more than
happy to work with them to help them become committers and PMC members here so THEY can make
sure ActiveMQ will meet their needs.

I’m also quite willing to provide fair and impartial links from the “third party stuff”
page on our website to the other communities.   I’m willing to say “what we provide is
pretty basic to get you started, there is likely better stuff available elsewhere, see that
page”.   

I’m quite willing to use other open source projects to build solutions within Apache and
even push fixes and stuff back PROVIDING the functionality directly related to the Apache
project is part of the Apache project.  As an example:  CXF builds upon Spring.  It used to
heavily build upon Spring, it’s quite a bit more reduced now.  Spring was a good framework
to chose to build upon.   However, the “Web Services” stuff is all in CXF.  The Namespace
handlers to extend Spring are all in CXF.   The beans to configure are all in CXF.   

What I’m NOT OK with is handing over the development of the primary user experience of an
Apache project to a third party and then “endorsing” that as the official way to do things
by shipping it from Apache.  Note:  I’m OK with handing it over and then NOT shipping/endorsing
anything related to that kind of user experience in Apache providing the PMC reaches a consensus
that that is OK.  In other words, no console is better than giving that up.   However, PMC
would need to agree that completely dropping the console is the best option for the users.

As a USER, the current console, while basic, not HTML5, etc… is “adequate” for basic
usage.   Yes, hawt.io is faster, cleaner, sexier, etc… But the console works for many of
the basic needs.   I would personally prefer it over nothing.   The fact that you’ve had
a couple people ask “what can we do to help make it better?” means this community has
a means of attracting additional people.  It surprises me a bit that people aren’t jumping
on that.

Dan



> 
> I'm +1 on option [3] BTW (not a binding vote).
> 
> 
> On Tue, Jan 21, 2014 at 2:06 PM, Daniel Kulp <dkulp@apache.org> wrote:
> 
>> 
>> On Jan 21, 2014, at 12:07 PM, Gary Tully <gary.tully@gmail.com> wrote:
>> 
>>> On 21 January 2014 16:30, Daniel Kulp <dkulp@apache.org> wrote:
>>>> 
>>>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
>> project.   If someone is using ActiveMQ and wants to contribute changes to
>> how the console looks or displays items or such, they should be making
>> contributions to ActiveMQ, not some external community (open source, free,
>> or otherwise).   The hawt.io “framework” of libraries and such can remain
>> outside, but the ActiveMQ specific portions needs to be part of this
>> community.   If it’s going to be the visible frontend of this project, we
>> need to make sure it drives the developer willing to contribute
>> enhancements into ActiveMQ.
>>>> 
>>> This is putting the cart before the horse!
>>> If we need some changes and if we can't make contributions to hawtio
>>> (patches, issues etc) we can deal with that by building our own plugin
>>> or throwing it out or whatever. But why do that now?
>> 
>> You are basically asking THIS developer community to completely give up
>> control over how ActiveMQ is presented to the users to a different
>> community.   I personally cannot think of anything much worse for this
>> community than that.   That seems like a horrible idea from an Apache
>> community standpoint.
>> 
>> The goals of the Apache communities needs to be to make sure developers
>> are driven into the Apache communities, not another community.
>> 
>>> We don't have to own everything that makes activemq better and that
>>> makes our users experience better, we just have to ensure that it is
>>> better.
>> 
>> Making the user experience better is certainly an important aspect of the
>> Apache communities, but the primary focus should be on making sure the
>> developer community is healthy and we aren’t driving potential developers
>> elsewhere.   That NEEDS to be the most important thing at this point,
>> especially with the current active makeup of this community.
>> 
>> In particular, since Apache is a 503b charitable non-profit foundation, we
>> cannot be used to promote other communities, particularly those “owned” by
>> a for-profit entity.  (open source or otherwise, that’s somewhat irrelevant)
>> 
>> Anyway, as far as *I’m* concerned (but I’m not a member of this PMC, just
>> an interested party), if the hawt.io community is unwilling or unable to
>> support the ActiveMQ community to allow ActiveMQ to maintain control over
>> it’s user experience, then there is no-point engaging with them.  It is a
>> waste of time.
>> 
>> That said, if hawt.io community want to create a full distribution of
>> ActiveMQ + hawt.io to make life easier for users, they certainly are
>> welcome to do so as long as it’s not branded ActiveMQ.  (and again, not
>> something to be promoted here)
>> 
>> Dan
>> 
>> 
>>> If the hawt.io  community is unwilling (or unable) to do the second
>> part, then, IMO, #3 is a non-starter.  If they ARE willing to do that, then
>> great.   Lets start figuring out how to get that done.   But that’s
>> something that would  need to be discussed on their side first.
>>>> 
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> 
>>>> On Jan 21, 2014, at 10:55 AM, Gary Tully <gary.tully@gmail.com> wrote:
>>>> 
>>>>> There are a lot of 0s and +1s for option [3] and two -1s
>>>>> 
>>>>> Let me make a case for it to try and get consensus around it.
>>>>> 
>>>>> I want to 'replace' the existing web console with something better.
>>>>> For configuration activemq did not build a dependency injection
>>>>> framework, we shipped spring.
>>>>> Learning from that, it does not make sense to me that we build and
>>>>> maintain a html5 web console.
>>>>> 
>>>>> An admin/management web front end based over our extensive JMX api
>>>>> sounds perfect but it needs
>>>>> a community to evolve and improve it. We (activemq committers) have
>>>>> proven that we need help in that area.
>>>>> 
>>>>> Anyone what to change their vote or further expand on the technical
>>>>> reasons we should not be branding hatwio?
>>>>> 
>>>>> 
>>>>> On 17 January 2014 13:33, Robert Davies <rajdavies@gmail.com> wrote:
>>>>>> I want to take a straw poll to see where everyone stands, because
>> opinion has varied, mine included. Straw polls can be a useful tool to move
>> towards consensus. This isn’t a formal vote, but to reduce the noise, can
>> we keep it to binding votes only ?
>>>>>> 
>>>>>> 
>>>>>> 1. Have one distribution with no default console, but make it easy
to
>> deploy a console on demand (the original console - or 3rd party ones).
>>>>>> 2. Have two separate distributions, one with no console  - and have
a
>> second distribution with the original console
>>>>>> 3. One distribution, with hawtio as the console -  ActiveMQ branded.
>>>>>> 4. One distribution, but uses the original ActiveMQ console only.
>>>>>> 
>>>>>> Here’s my vote:
>>>>>> 
>>>>>> [1]. +1
>>>>>> [2]  0
>>>>>> [3] 0
>>>>>> [4] -1
>>>>>> 
>>>>>> thanks,
>>>>>> 
>>>>>> Rob
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> http://redhat.com
>>>>> http://blog.garytully.com
>>>> 
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> http://redhat.com
>>> http://blog.garytully.com
>> 
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>> 
>> 
> 
> 
> -- 
> Cheers,
> Jon
> ---------------
> Red Hat, Inc.
> Email: janstey@redhat.com
> Web: http://redhat.com
> Twitter: jon_anstey
> Blog: http://janstey.blogspot.com
> Author of Camel in Action: http://manning.com/ibsen

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message