activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: [VOTE] Apache Artemis 1.2.0
Date Thu, 24 Dec 2015 00:45:30 GMT
My bad. Missread johns original message. Thought we was saying have prompt
to enable libaio. Apologies.

On Wednesday, December 23, 2015, Daniel Kulp <dkulp@apache.org> wrote:

>
> > On Dec 23, 2015, at 6:34 PM, Hiram Chirino <hiram@hiramchirino.com
> <javascript:;>> wrote:
> >
> > -1 that seems silly. There is no legal reason to do that and it gives our
> > users a worse experience out of the box.
>
> Giving our users the information they would need to make it perform better
> is giving them a worse experience?
>
> Dan
>
>
>
> >
> > On Wednesday, December 23, 2015, John D. Ament <johndament@apache.org
> <javascript:;>>
> > wrote:
> >
> >> +1 for a prompt on broker creation.
> >>
> >> It could even include a prompt, say "No libaio detected, to make your
> >> Artemis server faster please install libaio and {do necessary step to
> >> enable in broker}" but if it is installed, just prompt/given flag.
> >>
> >> John
> >>
> >> On Wed, Dec 23, 2015 at 5:07 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>
> >> <javascript:;>> wrote:
> >>
> >>>
> >>>> On Dec 23, 2015, at 4:55 PM, Andy Taylor <andy.tayls67@gmail.com
> <javascript:;>
> >> <javascript:;>> wrote:
> >>>> I Guess it depends on what they mean by enabled. If the user has to
> >>>> explicitly install it then to me it's optional. Saying that if it's
> >>>> installed by default on the OS you could argue the opposite.
> >>>
> >>> The issue with the is that the user may not even know if they have it
> >>> installed or not.    For example, on my two gentoo linux boxes, one has
> >> it
> >>> installed and one doesn’t.   I have no idea why the one that has it
> >>> installed has it.   With the package management and such, something I
> >>> installed there some time in the past must have caused it to install.
> >>> (likely mysql)
> >>>
> >>>> We could change the cli to prompt for a choice at create time.
> >>>
> >>> That would certainly work.
> >>>
> >>> Dan
> >>>
> >>>
> >>>
> >>>> On Wed, 23 Dec 2015 21:41 Daniel Kulp <dkulp@apache.org
> <javascript:;> <javascript:;>>
> >> wrote:
> >>>>
> >>>>>
> >>>>>> On Dec 23, 2015, at 4:07 PM, John D. Ament <johndament@apache.org
> <javascript:;>
> >> <javascript:;>>
> >>>>> wrote:
> >>>>>>
> >>>>>> Are you referring to the bin or src distribution?
> >>>>>
> >>>>> Kind of both…
> >>>>>
> >>>>> By removing the binary from the src distribution, that covers that
> >> case.
> >>>>> The user would have to cd into the appropriate directory and
> >> explicitly
> >>>>> run the “make” or whatever to build the binary.   It’s an
explicit
> >>> choice
> >>>>> they make.   Thus, I’m completely OK with that now.
> >>>>>
> >>>>>
> >>>>> The bin distribution is still an issue.   If the default was to
not
> >> use
> >>>>> the libaio at all unless the user either edited a config file to
> >> enable
> >>> it
> >>>>> or pass a command line flag or similar to take explicit action,
I’d
> be
> >>> OK
> >>>>> there as well.     The new wording on the legal pages is completely
> >>>>> confusing.  The original suggested wording in:
> >>>>> https://issues.apache.org/jira/browse/LEGAL-54
> >>>>> makes so much more sense:
> >>>>>
> >>>>> "However, projects may use LGPL licensed works in optional features
> >> that
> >>>>> are not enabled by default.”
> >>>>>
> >>>>>
> >>>>> Dan
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> On Wed, Dec 23, 2015 at 4:05 PM Daniel Kulp <dkulp@apache.org
> <javascript:;>
> >> <javascript:;>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> Question: If I grab Artemis 1.1.0 tarbal/zip and start up
the
> broker
> >>>>> “out
> >>>>>>> of the box”, does it use libaio or not?  If I specifically
have to
> >>>>>>> configure something (pass a flag, edit a config file, etc…)
to
> >> enable
> >>>>> use
> >>>>>>> if the LGPL library, then fine.    However, if it’s something
that
> >>>>> occurs
> >>>>>>> completely automatically without the user even knowing that
it’s
> >>>>> occurring,
> >>>>>>> then I have a major problem with it.  It needs to be something
that
> >>> the
> >>>>>>> user has to explicitly CHOOSE to use.
> >>>>>>>
> >>>>>>> Dan
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Dec 23, 2015, at 2:02 PM, Clebert Suconic <
> >>>>> clebert.suconic@gmail.com <javascript:;> <javascript:;>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> also, there has also been questions about it during
the donation
> >>>>>>>> process.. licenses reviewed.. etc.. so I don't think
we need to
> >> open
> >>> a
> >>>>>>>> new discussions over this. the binary inclusion on the
source was
> >>>>>>>> something that was fixed now.
> >>>>>>>>
> >>>>>>>> The dependency on libaio on the C code is through through
dynamic
> >>>>>>>> linked library, and is the same as any C code depending
on libc or
> >>>>>>>> gcc.
> >>>>>>>>
> >>>>>>>> On Wed, Dec 23, 2015 at 1:58 PM, Clebert Suconic
> >>>>>>>> <clebert.suconic@gmail.com <javascript:;> <javascript:;>>
wrote:
> >>>>>>>>> On Wed, Dec 23, 2015 at 1:55 PM, John D. Ament <
> >>> johndament@apache.org <javascript:;> <javascript:;>
> >>>>>>
> >>>>>>> wrote:
> >>>>>>>>>> Just wondering, does anyone plan to raise the
LGPL question w/
> >>> legal
> >>>>>>>>>> discuss?  If we're waiting for the new year
to do the next
> >> release,
> >>>>>>> would
> >>>>>>>>>> be good to at least start the discussion.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> We had such discussion long ago with legal. I couldn't
find that
> >>> email
> >>>>>>>>> on my inbox but we specifically asked questions
about it. We were
> >> ok
> >>>>>>>>> as I remember. Maybe someone else (Martyn?) will
have it on their
> >>>>>>>>> inboxes. For that reason I don't want to go over
the same issue
> we
> >>> had
> >>>>>>>>> asked before.
> >>>>>>>>>
> >>>>>>>>> The use of libaio is optional anyways and the system
works as
> >>>>>>>>> expected. what also covers other questions we had
here on this
> >>> thread.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Clebert Suconic
> >>>>>>>
> >>>>>>> --
> >>>>>>> Daniel Kulp
> >>>>>>> dkulp@apache.org <javascript:;> <javascript:;>
-
> http://dankulp.com/blog
> >>>>>>> Talend Community Coder - http://coders.talend.com
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Daniel Kulp
> >>>>> dkulp@apache.org <javascript:;> <javascript:;> -
> http://dankulp.com/blog
> >>>>> Talend Community Coder - http://coders.talend.com
> >>>>>
> >>>>>
> >>>
> >>> --
> >>> Daniel Kulp
> >>> dkulp@apache.org <javascript:;> <javascript:;> -
> http://dankulp.com/blog
> >>> Talend Community Coder - http://coders.talend.com
> >>>
> >>>
> >>
> >
> >
> > --
> > Hiram Chirino
> > Engineering | Red Hat, Inc.
> > hchirino@redhat.com <javascript:;> | fusesource.com | redhat.com
> > skype: hiramchirino | twitter: @hiramchirino
>
> --
> Daniel Kulp
> dkulp@apache.org <javascript:;> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

-- 
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino

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