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 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
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
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
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
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,
On Wed, Jan 22, 2014 at 1:04 PM, Daniel Kulp 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
> expec
On Jan 21, 2014, at 5:16 PM, Gary Tully wrote:
> inline
>
> On 21 January 2014 17:36, Daniel Kulp 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
So why didn't you guys work on this console "in-house"?
On Wednesday, January 22, 2014, Dejan Bosanac 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 proj
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
compone
inline
On 21 January 2014 17:36, Daniel Kulp wrote:
>
> On Jan 21, 2014, at 12:07 PM, Gary Tully wrote:
>
>> On 21 January 2014 16:30, Daniel Kulp wrote:
>>>
>>> 2) All the ActiveMQ related code needs to be moved into the ActiveMQ
>>> project. If someone is using ActiveMQ and wants to contri
On Tue, Jan 21, 2014 at 4:00 PM, Daniel Kulp wrote:
>
> On Jan 21, 2014, at 1:15 PM, Jon Anstey 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 tha
On Jan 21, 2014, at 1:15 PM, Jon Anstey 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
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 co
On Tue, Jan 21, 2014 at 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 brandin
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 w
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
On Jan 21, 2014, at 12:07 PM, Gary Tully wrote:
> On 21 January 2014 16:30, Daniel Kulp 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 o
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 Z
inline
On 21 January 2014 16:30, 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”.
>
This is my point. A new project has already done it and it is great
(being a great web ui is their whole reason for
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
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
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 th
[1] -1
[2] 0
[3] +1
[4] +1
Using the webconsole for development/debugging purposes is extremely
helpful. When moving to production systems, it should be a simple matter
to turn it off. This is no different than removing debug code from your
build when deploying.
On Fri, Jan 17, 2014 at 5:33 A
I said console in my statement, not web console. You need a way to manage
stuff.
On Friday, January 17, 2014, Christian Posta
wrote:
> well, karaf does ship with a console, the command-line shell.
>
> but i think we're talking about the web console.
>
> in 2.3.3, i don't see a webconsole shippe
well, karaf does ship with a console, the command-line shell.
but i think we're talking about the web console.
in 2.3.3, i don't see a webconsole shipped in the distro:
http://pastebin.com/zepcUHMX
in 3.0.0 i don't either:
http://pastebin.com/cfV3yG0Z
On Fri, Jan 17, 2014 at 3:19 PM, Hadrian
It has the tui on by default
On Friday, January 17, 2014, Robert Davies wrote:
>
> On 17 Jan 2014, at 21:53, James Carman
> >
> wrote:
>
> > Karaf ships with a console
>
> Yes - its not installed by default - which is equivalent to option 1.
>
> >
> > On Friday, January 17, 2014, Robert Davies
Rob, that's not quite correct. Karaf *ships with a console*, ActiveMQ
also ships with a console. The issue we are discussing now is the distro
content, right?
Hadrian
On 01/17/2014 05:07 PM, Robert Davies wrote:
On 17 Jan 2014, at 21:53, James Carman wrote:
Karaf ships with a console
On 17 Jan 2014, at 21:53, James Carman wrote:
> Karaf ships with a console
Yes - its not installed by default - which is equivalent to option 1.
>
> On Friday, January 17, 2014, Robert Davies wrote:
>
>>
>> On 17 Jan 2014, at 16:33, James Carman
>> >
>> wrote:
>>
>>> Agreed. My point wa
Karaf ships with a console
On Friday, January 17, 2014, Robert Davies wrote:
>
> On 17 Jan 2014, at 16:33, James Carman
> >
> wrote:
>
> > Agreed. My point was that we shouldn't just abandon the console that
> > comes with ActiveMQ. A messaging "product" should have its own
> > console, if it
On 17 Jan 2014, at 16:33, James Carman wrote:
> Agreed. My point was that we shouldn't just abandon the console that
> comes with ActiveMQ. A messaging "product" should have its own
> console, if it is to be taken seriously by potential "customers”.
I don’t buy in to that at all - having to h
On 17 Jan 2014, at 16:18, James Carman wrote:
> Can we get a rundown of the issues with the current console? I don't
> really see a lot of traffic on here complaining about it. Nobody has
> really touched it in a long time, right? So, why not get some folks
> who are interested in it to work
>
> Another -1 for the idea of not including users/devs/committers in this poll.
> Their voice counts.
Yes - not ideal but if we can’t get consensus amongst a smaller group, there’s
no hope of a larger one. So just starting small to see what happens.
>
>
>
> On 01/17/2014 08:33 AM, Robert D
Agreed. My point was that we shouldn't just abandon the console that
comes with ActiveMQ. A messaging "product" should have its own
console, if it is to be taken seriously by potential "customers".
Providing an even playing field for consoles shouldn't be ActiveMQ's
primary concern. ActiveMQ sho
James,
5. Is just business as usual, why should it be part of the poll? Users
raise an issue, it gets fixed.
My $0.02,
Hadrian
On 01/17/2014 11:25 AM, James Carman wrote:
1. -1
2. -1
3. -1
4. +1
5. Resurrect the "old" console and bring it up-to-date, fixing any
outstanding bugs - +1
On Fr
1. -1
2. -1
3. -1
4. +1
5. Resurrect the "old" console and bring it up-to-date, fixing any
outstanding bugs - +1
On Fri, Jan 17, 2014 at 8:33 AM, Robert Davies wrote:
> I want to take a straw poll to see where everyone stands, because opinion has
> varied, mine included. Straw polls can be a us
Can we get a rundown of the issues with the current console? I don't
really see a lot of traffic on here complaining about it. Nobody has
really touched it in a long time, right? So, why not get some folks
who are interested in it to work on it? I'd be willing to help with
it.
On Fri, Jan 17,
[1] +1 -- this gives the user choice -- if they choose the old
console, they accept the risks by doing so
[2] -1 -- this still endorses the old console, which should be treated
as deprecated, EOL, and removed
[3] 0 -- this seems to be a huge can of worms, yet probably beneficial
for the community
[
On Fri, Jan 17, 2014 at 2:33 PM, Robert Davies 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 bin
[1] +1 This would let users choose which console they want.
[2] -1 I think having 2 distros would just add confusion for end users.
[3] 0 As long as it's ActiveMQ branded, then it works for me.
[4] -1 The original console is a liability that I'd rather not carry anymore.
On Fri, Jan 17, 2014 at 8
[1] -1 (not a great idea to remove something still used and useful)
[2] +1 (status quo)
[3] -1 (unless relevant parts were donated to the ASF)
[4] +1 (status quo)
Another -1 for the idea of not including users/devs/committers in this
poll. Their voice counts.
Hadrian
On 01/17/2014 08:33 AM,
[1] 0
[2] -1
[3] +1
[4] -1
On 17 January 2014 13:33, Robert Davies 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,
[1] +1
[2] -1
[3] 0
[4] -1
On 01/17/2014 08:33 AM, Robert Davies 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 kee
[1] +1
[2] -1 since we'd be effectively endorsing deprecated, dead code which is
potentially a security risk. I'd change this to a 0 if we clearly called
the distro "apache-activemq-deprecated-distro" or something to highlight
users are using dead, unmaintained code that probably has security
vulne
[1] +1
[2] -1
[3] +1
[4] -1
Regards
--
Dejan Bosanac
--
Red Hat, Inc.
FuseSource is now part of Red Hat
dbosa...@redhat.com
Twitter: @dejanb
Blog: http://sensatic.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Fri, Jan 17, 2014 at 2:33 PM, Robert Davies 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 c
45 matches
Mail list logo
