[DISCUSS] Remove the old ActiveMQ Console

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

Jon Anstey
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'm +1 on option [3] BTW (not a binding vote).


On Tue, Jan 21, 2014 at 2:06 PM, Daniel Kulp <[hidden email]> wrote:

>
> On Jan 21, 2014, at 12:07 PM, Gary Tully <[hidden email]> wrote:
>
> > On 21 January 2014 16:30, Daniel Kulp <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email] - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >
> >
> >
> > --
> > http://redhat.com
> > http://blog.garytully.com
>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: [hidden email]
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

Hadrian Zbarcea
In reply to this post by gtully
And how exactly do you plan to achieve this without changes in hawt.io,
and consequently buy-in from the hawt.io devs? Fork hawt.io?

Hadrian



On 01/21/2014 12:11 PM, Gary Tully wrote:

> hadrian, it is the activemq devs that want to include hawtio, not the
> other way around.
> lets concentrate on what we (activemq devs/pmc) can do to make the web
> experience better.
> The only technical issue with hawtio in 5.9 is the branding. I say we
> just fix that.
>
> On 21 January 2014 17:00, Hadrian Zbarcea <[hidden email]> wrote:
>> Agree.
>>
>> In the other thread it was clarified why the hawt.io console in the current
>> form cannot be included in the activemq distro. I would have expected the
>> hawt.io devs to come with a proposal on how they plan to address that if
>> they want #3 to happen. Suggestions were offered, but I saw no reply or
>> feedback. Continuing this conversation without an understanding of what the
>> hawt.io devs intentions are is, imo, not a great use of time.
>>
>> My $0.02,
>> Hadrian
>>
>>
>>
>>
>> On 01/21/2014 11:30 AM, Daniel Kulp wrote:
>>>
>>>
>>> There is a huge difference between “needing help” in that area (as you put
>>> it)  and “having someone else do it for us”.
>>>
>>> For #3 to work, IMO two things need to be done:
>>>
>>> 1) Skinning (obvious)
>>>
>>> 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.
>>>
>>> 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 <[hidden email]> 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 <[hidden email]> 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
>>>
>>>
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

James Carman
In reply to this post by gtully
On Tue, Jan 21, 2014 at 12:11 PM, Gary Tully <[hidden email]> wrote:
> hadrian, it is the activemq devs that want to include hawtio, not the
> other way around.
> lets concentrate on what we (activemq devs/pmc) can do to make the web
> experience better.
> The only technical issue with hawtio in 5.9 is the branding. I say we
> just fix that.
>

You say that as if they are not one and the same.
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

Daniel Kulp
In reply to this post by Jon Anstey

On Jan 21, 2014, at 1:15 PM, Jon Anstey <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>> On Jan 21, 2014, at 12:07 PM, Gary Tully <[hidden email]> wrote:
>>
>>> On 21 January 2014 16:30, Daniel Kulp <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email] - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> http://redhat.com
>>> http://blog.garytully.com
>>
>> --
>> Daniel Kulp
>> [hidden email] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
>
> --
> Cheers,
> Jon
> ---------------
> Red Hat, Inc.
> Email: [hidden email]
> Web: http://redhat.com
> Twitter: jon_anstey
> Blog: http://janstey.blogspot.com
> Author of Camel in Action: http://manning.com/ibsen

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

gashcrumb
In reply to this post by Hadrian Zbarcea
Just to address the technical question of skinning the console, we've a
vendor.js file just for that purpose.  So at the simplest level skinning
would be a matter of extending the existing hawtio-web.war and replacing
the vendor.js file, and likely adding your own .css file.

So in vendor.js you could do (for example):

var link = $("<link>")
$("head").append(link);

link.attr({
   rel: 'stylesheet',
   type: 'text/css',
   href: 'css/my-custom-css.css'
});

// ensure the built-in branding module doesn't kick in at all
Branding.enabled = false;

// then you need a plugin to customize the branding strings
angular.module('myBranding', ['hawtioCore',
'hawtio-branding']).run(function (branding) {

          branding.appName = 'ActiveMQ Web Console';
          branding.appLogo = 'img/branding/MyLogo.png';
          branding.loginBg = 'img/branding/MyLoginScreen.png';
          //gets rid of the header nav bar on the login screen
          branding.fullscreenLogin = true;
);

hawtioPluginLoader.addModule('myBranding');

Then in my-custom-css.css you can rework the UI as much as you like really.



On Tue, Jan 21, 2014 at 1:46 PM, Hadrian Zbarcea <[hidden email]> wrote:

> And how exactly do you plan to achieve this without changes in hawt.io,
> and consequently buy-in from the hawt.io devs? Fork hawt.io?
>
> Hadrian
>
>
>
>
> On 01/21/2014 12:11 PM, Gary Tully wrote:
>
>> hadrian, it is the activemq devs that want to include hawtio, not the
>> other way around.
>> lets concentrate on what we (activemq devs/pmc) can do to make the web
>> experience better.
>> The only technical issue with hawtio in 5.9 is the branding. I say we
>> just fix that.
>>
>> On 21 January 2014 17:00, Hadrian Zbarcea <[hidden email]> wrote:
>>
>>> Agree.
>>>
>>> In the other thread it was clarified why the hawt.io console in the
>>> current
>>> form cannot be included in the activemq distro. I would have expected the
>>> hawt.io devs to come with a proposal on how they plan to address that if
>>> they want #3 to happen. Suggestions were offered, but I saw no reply or
>>> feedback. Continuing this conversation without an understanding of what
>>> the
>>> hawt.io devs intentions are is, imo, not a great use of time.
>>>
>>> My $0.02,
>>> Hadrian
>>>
>>>
>>>
>>>
>>> On 01/21/2014 11:30 AM, Daniel Kulp wrote:
>>>
>>>>
>>>>
>>>> There is a huge difference between “needing help” in that area (as you
>>>> put
>>>> it)  and “having someone else do it for us”.
>>>>
>>>> For #3 to work, IMO two things need to be done:
>>>>
>>>> 1) Skinning (obvious)
>>>>
>>>> 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.
>>>>
>>>> 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 <[hidden email]> 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 <[hidden email]> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

Jon Anstey
In reply to this post by Daniel Kulp
On Tue, Jan 21, 2014 at 4:00 PM, Daniel Kulp <[hidden email]> wrote:

>
> On Jan 21, 2014, at 1:15 PM, Jon Anstey <[hidden email]> 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.


That is great. So you want to work with the hawtio community on this. It
just sounded like you didn't from the previous emails. Asking to move code
from another project is not a good way to work with them ;-)


>  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.
>

That is only your opinion though right? If hawtio is branded/skinned to
meet ASF requirements why can't it be included?


>
> 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.
>

No one is jumping on it probably (my opinion here) because discussion +
effort has already been put in since this past summer to move to a new
console so why invest more on the old console.

Haven't counted the poll results so not sure if most want hawtio to stay or
not... just stating my personal opinion here that I think its the best way
to go. I'm +0 on option [1] too if folks really don't like the hawtio
option.


>
> Dan
>
>
>
> >
> > I'm +1 on option [3] BTW (not a binding vote).
> >
> >
> > On Tue, Jan 21, 2014 at 2:06 PM, Daniel Kulp <[hidden email]> wrote:
> >
> >>
> >> On Jan 21, 2014, at 12:07 PM, Gary Tully <[hidden email]> wrote:
> >>
> >>> On 21 January 2014 16:30, Daniel Kulp <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
> >>>> [hidden email] - http://dankulp.com/blog
> >>>> Talend Community Coder - http://coders.talend.com
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> http://redhat.com
> >>> http://blog.garytully.com
> >>
> >> --
> >> Daniel Kulp
> >> [hidden email] - http://dankulp.com/blog
> >> Talend Community Coder - http://coders.talend.com
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Jon
> > ---------------
> > Red Hat, Inc.
> > Email: [hidden email]
> > Web: http://redhat.com
> > Twitter: jon_anstey
> > Blog: http://janstey.blogspot.com
> > Author of Camel in Action: http://manning.com/ibsen
>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>


--
Cheers,
Jon
---------------
Red Hat, Inc.
Email: [hidden email]
Web: http://redhat.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

gtully
In reply to this post by Daniel Kulp
inline

On 21 January 2014 17:36, Daniel Kulp <[hidden email]> wrote:

>
> On Jan 21, 2014, at 12:07 PM, Gary Tully <[hidden email]> wrote:
>
>> On 21 January 2014 16:30, Daniel Kulp <[hidden email]> 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.
>
That is not what I am asking.
How can choosing to adopt a better solution to an open problem be
giving up control? We can always change our minds and throw it out if
it does not serve our needs. The PMC will always be in control of what
is released.


> The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community.
Any goal that hopes to drive developers is a non starter. Developers
choose, they are not driven. I am suggesting we make a sensible choice
that helps our community by giving it a better web ui. hawtio wants to
have the best activemq web console, we want to ship the best activemq
console. The stars are aligned. If the alignment falters we address
that.

>
>> 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email] - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>
>>
>>
>> --
>> http://redhat.com
>> http://blog.garytully.com
>
> --
> Daniel Kulp
> [hidden email] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>



--
http://redhat.com
http://blog.garytully.com
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

dejanb
In my opinion, this "control issue" is totally overblown. First of all,
we're not some newcomers trying to put a malware into the project. We're
people that are developing this project for the last 5-7 years and are
trying to position it better for the future, by replacing its most obsolete
component.

But most importantly, you put it as if Apache releases are totally
uncontrollable and anybody can sneak into it anything they want. But you
know well that's not the case, as we use proper releases of other projects
and all "skinning" is done here. Additionally, every release is voted. So
there's no chance of any misuse at the release time and once it's released
it can't be changed. What happens when a project we use loses its track? We
deal with that at that point (find a replacement, fork and continue
developing, etc.) and it's the same for Spring, Jetty, HawtIO or any other
part. So the "risk of losing control" is not valid neither from technical
nor project image standpoint.

Regards
--
Dejan Bosanac
----------------------
Red Hat, Inc.
FuseSource is now part of Red Hat
[hidden email]
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/


On Tue, Jan 21, 2014 at 11:16 PM, Gary Tully <[hidden email]> wrote:

> inline
>
> On 21 January 2014 17:36, Daniel Kulp <[hidden email]> wrote:
> >
> > On Jan 21, 2014, at 12:07 PM, Gary Tully <[hidden email]> wrote:
> >
> >> On 21 January 2014 16:30, Daniel Kulp <[hidden email]> 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.
> >
> That is not what I am asking.
> How can choosing to adopt a better solution to an open problem be
> giving up control? We can always change our minds and throw it out if
> it does not serve our needs. The PMC will always be in control of what
> is released.
>
>
> > The goals of the Apache communities needs to be to make sure developers
> are driven into the Apache communities, not another community.
> Any goal that hopes to drive developers is a non starter. Developers
> choose, they are not driven. I am suggesting we make a sensible choice
> that helps our community by giving it a better web ui. hawtio wants to
> have the best activemq web console, we want to ship the best activemq
> console. The stars are aligned. If the alignment falters we address
> that.
>
> >
> >> 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 <[hidden email]> 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 <[hidden email]> 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
> >>> [hidden email] - http://dankulp.com/blog
> >>> Talend Community Coder - http://coders.talend.com
> >>>
> >>
> >>
> >>
> >> --
> >> http://redhat.com
> >> http://blog.garytully.com
> >
> > --
> > Daniel Kulp
> > [hidden email] - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
>
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

James Carman
So why didn't you guys work on this console "in-house"?

On Wednesday, January 22, 2014, Dejan Bosanac <[hidden email]> wrote:

> In my opinion, this "control issue" is totally overblown. First of all,
> we're not some newcomers trying to put a malware into the project. We're
> people that are developing this project for the last 5-7 years and are
> trying to position it better for the future, by replacing its most obsolete
> component.
>
> But most importantly, you put it as if Apache releases are totally
> uncontrollable and anybody can sneak into it anything they want. But you
> know well that's not the case, as we use proper releases of other projects
> and all "skinning" is done here. Additionally, every release is voted. So
> there's no chance of any misuse at the release time and once it's released
> it can't be changed. What happens when a project we use loses its track? We
> deal with that at that point (find a replacement, fork and continue
> developing, etc.) and it's the same for Spring, Jetty, HawtIO or any other
> part. So the "risk of losing control" is not valid neither from technical
> nor project image standpoint.
>
> Regards
> --
> Dejan Bosanac
> ----------------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> [hidden email] <javascript:;>
> Twitter: @dejanb
> Blog: http://sensatic.net
> ActiveMQ in Action: http://www.manning.com/snyder/
>
>
> On Tue, Jan 21, 2014 at 11:16 PM, Gary Tully <[hidden email]> wrote:
>
> > inline
> >
> > On 21 January 2014 17:36, Daniel Kulp <[hidden email]> wrote:
> > >
> > > On Jan 21, 2014, at 12:07 PM, Gary Tully <[hidden email]> wrote:
> > >
> > >> On 21 January 2014 16:30, Daniel Kulp <[hidden email]> 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.
> > >
> > That is not what I am asking.
> > How can choosing to adopt a better solution to an open problem be
> > giving up control? We can always change our minds and throw it out if
> > it does not serve our needs. The PMC will always be in control of what
> > is released.
> >
> >
> > > The goals of the Apache communities needs to be to make sure developers
> > are driven into the Apache communities, not another community.
> > Any goal that hopes to drive developers is a non starter. Developers
> > choose, they are not driven. I am suggesting we make a sensible choice
> > that helps our community by giving it a better web ui. hawtio wants to
> > have the best activemq web console, we want to ship the best activemq
> > console. The stars are aligned. If the alignment falters we address
> > that.
> >
> > >
> > >> 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
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

Daniel Kulp
In reply to this post by gtully

On Jan 21, 2014, at 5:16 PM, Gary Tully <[hidden email]> wrote:

> inline
>
> On 21 January 2014 17:36, Daniel Kulp <[hidden email]> wrote:
>
>> The goals of the Apache communities needs to be to make sure developers are driven into the Apache communities, not another community.
> Any goal that hopes to drive developers is a non starter. Developers
> choose, they are not driven.

That’s completely BS.     If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue.  I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.

If I’m in the *ActiveMQ* console provided/endorsed by the ActiveMQ community and I see that my message is displaying wrong or the data isn’t displaying correctly or the column sizes aren’t taking things into consideration properly or similar, then I, as a developer, completely expect that I can contribute patches to ActiveMQ to fix that.   Again, the download needs to drive developers to ActiveMQ, not an external community.   Also, the documentation around how to use what is provided by ActiveMQ needs to be on the ActiveMQ web site.  Any errors in that documentation should be handled by the ActiveMQ community.   Patches for the documentation should go through ActiveMQ’s process.  


Dan


> I am suggesting we make a sensible choice
> that helps our community by giving it a better web ui. hawtio wants to
> have the best activemq web console, we want to ship the best activemq
> console. The stars are aligned. If the alignment falters we address
> that.
>
>>
>>> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> [hidden email] - http://dankulp.com/blog
>>>> Talend Community Coder - http://coders.talend.com
>>>>
>>>
>>>
>>>
>>> --
>>> http://redhat.com
>>> http://blog.garytully.com
>>
>> --
>> Daniel Kulp
>> [hidden email] - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

chirino
On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <[hidden email]> wrote:
> That’s completely BS.     If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue.  I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>

If this is true then we should not be using ANY 3rd party libs at all.
 Most users cannot tell where the line is between 3rd party libs and
ActiveMQ's source.  The ActiveMQ project is ultimately responsible for
all functionality shipped (if its 3rd party or not).  If it's a 3rd
party defect then the ActiveMQ project needs to either work around the
defect, patch the defect in the 3rd party library or work with the 3rd
party to fix the defect.  All 3 approaches are possible with hawtio
too.

--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

James Carman
This whole "then we shouldn't use any 3rd party libraries" argument is
getting old, Hiram.  You know there's a difference between using a
library behind the scenes and the entire web console itself that the
users interact with directly. Come on, man.  Give it up.


On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <[hidden email]> wrote:

> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <[hidden email]> wrote:
>> That’s completely BS.     If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue.  I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>
>
> If this is true then we should not be using ANY 3rd party libs at all.
>  Most users cannot tell where the line is between 3rd party libs and
> ActiveMQ's source.  The ActiveMQ project is ultimately responsible for
> all functionality shipped (if its 3rd party or not).  If it's a 3rd
> party defect then the ActiveMQ project needs to either work around the
> defect, patch the defect in the 3rd party library or work with the 3rd
> party to fix the defect.  All 3 approaches are possible with hawtio
> too.
>
> --
> Hiram Chirino
> Engineering | Red Hat, Inc.
> [hidden email] | fusesource.com | redhat.com
> skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

Hadrian Zbarcea
Let's get the discussion back on track and try to reach some consensus.

Without the hawt.io community donating the relevant ActiveMQ portions to
the ASF we will not be able to get a consensus around proposal #3. Thus,
that needs to be taken off the table.

We have users specifically asking to retain the console. We also have
people who have stepped up and volunteered to help enhancing the
existing console. Thus, option #1 is off the table.

This leaves #2 and #4. Out of the two, #4 is the status quo and has more
support. The remaining question is if we want two distros or not?

Cheers,
Hadrian



On 01/22/2014 04:47 PM, James Carman wrote:

> This whole "then we shouldn't use any 3rd party libraries" argument is
> getting old, Hiram.  You know there's a difference between using a
> library behind the scenes and the entire web console itself that the
> users interact with directly. Come on, man.  Give it up.
>
>
> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <[hidden email]> wrote:
>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <[hidden email]> wrote:
>>> That’s completely BS.     If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue.  I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>
>>
>> If this is true then we should not be using ANY 3rd party libs at all.
>>   Most users cannot tell where the line is between 3rd party libs and
>> ActiveMQ's source.  The ActiveMQ project is ultimately responsible for
>> all functionality shipped (if its 3rd party or not).  If it's a 3rd
>> party defect then the ActiveMQ project needs to either work around the
>> defect, patch the defect in the 3rd party library or work with the 3rd
>> party to fix the defect.  All 3 approaches are possible with hawtio
>> too.
>>
>> --
>> Hiram Chirino
>> Engineering | Red Hat, Inc.
>> [hidden email] | fusesource.com | redhat.com
>> skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

chirino
In reply to this post by James Carman
I don't really see much of a difference.  As long as the PMC is happy
with the end product that we produce what's the problem?  You don't
like the way some UI element works? Then raise an ActiveMQ jira issue.
 We can follow the normal deficiency resolution processes to fix it.
If you think we can't for some reason, I'd like to understand why you
think that.

Perhaps there some special ASF policy your talking about that I'm not
aware of?  If so, could you you provide me a pointer to where it's
documented?


On Wed, Jan 22, 2014 at 4:47 PM, James Carman
<[hidden email]> wrote:

> This whole "then we shouldn't use any 3rd party libraries" argument is
> getting old, Hiram.  You know there's a difference between using a
> library behind the scenes and the entire web console itself that the
> users interact with directly. Come on, man.  Give it up.
>
>
> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <[hidden email]> wrote:
>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <[hidden email]> wrote:
>>> That’s completely BS.     If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue.  I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>
>>
>> If this is true then we should not be using ANY 3rd party libs at all.
>>  Most users cannot tell where the line is between 3rd party libs and
>> ActiveMQ's source.  The ActiveMQ project is ultimately responsible for
>> all functionality shipped (if its 3rd party or not).  If it's a 3rd
>> party defect then the ActiveMQ project needs to either work around the
>> defect, patch the defect in the 3rd party library or work with the 3rd
>> party to fix the defect.  All 3 approaches are possible with hawtio
>> too.

--
Hiram Chirino
Engineering | Red Hat, Inc.
[hidden email] | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

Hadrian Zbarcea
Well, not all the PMC is happy. And you know full well that raising an
AMQ JIRA issue won't help if the code is somewhere else.

Sounds like the the options we can reach consensus on are #2 and #4.
Let's focus on that.

Hadrian



On 01/22/2014 05:30 PM, Hiram Chirino wrote:

> I don't really see much of a difference.  As long as the PMC is happy
> with the end product that we produce what's the problem?  You don't
> like the way some UI element works? Then raise an ActiveMQ jira issue.
>   We can follow the normal deficiency resolution processes to fix it.
> If you think we can't for some reason, I'd like to understand why you
> think that.
>
> Perhaps there some special ASF policy your talking about that I'm not
> aware of?  If so, could you you provide me a pointer to where it's
> documented?
>
>
> On Wed, Jan 22, 2014 at 4:47 PM, James Carman
> <[hidden email]> wrote:
>> This whole "then we shouldn't use any 3rd party libraries" argument is
>> getting old, Hiram.  You know there's a difference between using a
>> library behind the scenes and the entire web console itself that the
>> users interact with directly. Come on, man.  Give it up.
>>
>>
>> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <[hidden email]> wrote:
>>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <[hidden email]> wrote:
>>>> That’s completely BS.     If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue.  I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>>
>>>
>>> If this is true then we should not be using ANY 3rd party libs at all.
>>>   Most users cannot tell where the line is between 3rd party libs and
>>> ActiveMQ's source.  The ActiveMQ project is ultimately responsible for
>>> all functionality shipped (if its 3rd party or not).  If it's a 3rd
>>> party defect then the ActiveMQ project needs to either work around the
>>> defect, patch the defect in the 3rd party library or work with the 3rd
>>> party to fix the defect.  All 3 approaches are possible with hawtio
>>> too.
>
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] - Remove the old ActiveMQ Console

rajdavies
The poll proved there’s no consensus - and none is likely to be reached - so closing this down and will put forward a new proposal.

On 22 Jan 2014, at 23:12, Hadrian Zbarcea <[hidden email]> wrote:

> Well, not all the PMC is happy. And you know full well that raising an AMQ JIRA issue won't help if the code is somewhere else.
>
> Sounds like the the options we can reach consensus on are #2 and #4. Let's focus on that.
>
> Hadrian
>
>
>
> On 01/22/2014 05:30 PM, Hiram Chirino wrote:
>> I don't really see much of a difference.  As long as the PMC is happy
>> with the end product that we produce what's the problem?  You don't
>> like the way some UI element works? Then raise an ActiveMQ jira issue.
>>  We can follow the normal deficiency resolution processes to fix it.
>> If you think we can't for some reason, I'd like to understand why you
>> think that.
>>
>> Perhaps there some special ASF policy your talking about that I'm not
>> aware of?  If so, could you you provide me a pointer to where it's
>> documented?
>>
>>
>> On Wed, Jan 22, 2014 at 4:47 PM, James Carman
>> <[hidden email]> wrote:
>>> This whole "then we shouldn't use any 3rd party libraries" argument is
>>> getting old, Hiram.  You know there's a difference between using a
>>> library behind the scenes and the entire web console itself that the
>>> users interact with directly. Come on, man.  Give it up.
>>>
>>>
>>> On Wed, Jan 22, 2014 at 1:48 PM, Hiram Chirino <[hidden email]> wrote:
>>>> On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp <[hidden email]> wrote:
>>>>> That’s completely BS.     If I download “activemq-###.tar.gz” from ActiveMQ’s website and I run the startup scripts and such that are documented in that bundle and I find a problem that directly pertains to ActiveMQ, I COMPLETELY expect to be able to go to ActiveMQ’s JIRA and log an issue.  I also completely expect to be able to do a “git clone” of ActiveMQ’s repo, diagnose the problem, and submit a patch back to ActiveMQ.
>>>>>
>>>>
>>>> If this is true then we should not be using ANY 3rd party libs at all.
>>>>  Most users cannot tell where the line is between 3rd party libs and
>>>> ActiveMQ's source.  The ActiveMQ project is ultimately responsible for
>>>> all functionality shipped (if its 3rd party or not).  If it's a 3rd
>>>> party defect then the ActiveMQ project needs to either work around the
>>>> defect, patch the defect in the 3rd party library or work with the 3rd
>>>> party to fix the defect.  All 3 approaches are possible with hawtio
>>>> too.
>>

Rob Davies
————————
Red Hat, Inc
http://hawt.io - #dontcha
Twitter: rajdavies
Blog: http://rajdavies.blogspot.com
ActiveMQ in Action: http://www.manning.com/snyder/

1234