jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Donation of a New Dashboard for JMeter : Questions and more
Date Wed, 25 Nov 2015 17:55:00 GMT
Hello,
I am not an expert of IP Clearance so your help is welcome.

UbikLoadPack has created a new Bugzilla for donation:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=58653

I attached to bugzilla this evening the
ip-clearance-jmeter-report-bug-58653.xml document.

Let me know if it's ok for you ?
The next steps are not fully clear for me so @milamber your help proposal
is very welcome :-)

Regards



On Sat, Nov 21, 2015 at 4:42 PM, Milamber <milamber@apache.org> wrote:

>
>
> On 17/11/2015 19:06, UBIK LOAD PACK wrote:
>
>> Hello,
>> Can we start the IP clearance process or is there some step before ?
>>
>
> The IP clearance process seems needed for this donation, the actual patch
> (diff between trunk and your donation branch) is important and include some
> external components.
>
> The dashboard behavior isn't in the core of JMeter, its inclusion in
> JMeter will not affect the core behavior (load testing), I think we can
> include the dashboard under the JMeter source tree as a new 'beta'
> functionality. After we can improve the dashboard / fixes the little issues
> inside.
>
> I think that the next step are:
> 1/ Start a technical vote to accept or not the donation (I will do this)
> 2/ If the donation is accepted, start an IP clearance process [1] + vote
> on general@incubator.a.o (Probably Philippe, you can do this? or me)
> 3/ Inclusion in JMeter source tree
>
> Milamber
>
> [1] http://incubator.apache.org/ip-clearance/
>
>
>> Thanks
>> Regards
>>
>> On Tuesday, November 10, 2015, Richard Friedman <richfriedman@gmail.com>
>> wrote:
>>
>> I am not a committer but think very much this feature is needed for future
>>> JMeter and this is a good start.
>>>
>>> 1 - Great job on building it. I built it and integrated into some of my
>>> work already.  I have posted some issues.  I think there is some work to
>>> do
>>> before an official release, but would good to have this work started in
>>> apache proper.
>>>
>>> 2 - Definitely need architecture documentation and make sure it becomes
>>> very pluggable, especially if someone wants to contribute on the client
>>> side only.  I like the report-template separation allowing any template
>>> to
>>> happen.
>>>
>>> 3 -  Requirement for jmeter.save.saveservice.print_field_names=true
>>> I understand the need for this when generating the file, but I am run
>>> remotely and report locally.  I think the parser could be smarter looking
>>> for the common field names.   I think this becomes a different issue when
>>> there are custom fields from plugins vs the common.
>>>
>>> 4 - Configuration
>>> Why not put the configuration with the template instead of in
>>> jmeter.properties (or user.properties).  The configuration for the Report
>>> Generator that is not template or report specific ( ie template dir, temp
>>> dir, .. ) should be in jmeter.properties
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 10, 2015 at 3:45 AM, Antonio Gomes Rodrigues <
>>> ra0077@gmail.com
>>> <javascript:;>>
>>> wrote:
>>>
>>> Hi,
>>>>
>>>> I agree with Philippe, all the competitors (LoadRunner, Neoload,
>>>> Gatling,
>>>> SilkPerf, etc...) can generate a nice reporting at the end of the load
>>>> test.
>>>>
>>>> Each time I use another load test tool, I use this feature to analyze
>>>> the
>>>> load test.
>>>>
>>>> Each time I use JMeter, it's boring because I am forced to use another
>>>>
>>> tool
>>>
>>>> (QlickView, etc.) to make it
>>>>
>>>> It will be great to have it in JMeter because it's important (to be
>>>> competitive and it's useful)
>>>>
>>>> Antonio
>>>>
>>>>
>>>>
>>>> 2015-11-09 22:21 GMT+01:00 Philippe Mouawad <pmouawad@apache.org
>>>>
>>> <javascript:;>>:
>>>
>>>> Hello,
>>>>> As a JMeter commiter I think this feature should be integrated to Core.
>>>>>
>>>>> Lack of nice reporting in JMeter is no more acceptable nowadays, all
>>>>> Commercial and Open Source competitors have reporting now and it's a
>>>>>
>>>> weak
>>>
>>>> point of JMeter.
>>>>>
>>>>> The code respects JMeter best practices as far as I can tell, there is
>>>>> documentation (dev and users) and javadocs.
>>>>>
>>>>> PS : Note that I am not totally neutral here being a member of Ubik
>>>>>
>>>> Load
>>>
>>>> Pack Team.
>>>>>
>>>>> Regards
>>>>> Philippe
>>>>>
>>>>> On Fri, Nov 6, 2015 at 11:12 AM, UBIK LOAD PACK <
>>>>> ubik-load-pack-sales@ubik-ingenierie.com <javascript:;>> wrote:
>>>>>
>>>>> Hello,
>>>>>> We have completed our UATs for V1 milestone and fixed all bugs and
>>>>>> enhancements detected.
>>>>>>
>>>>>> We released Preview 1.0.0:
>>>>>> -
>>>>>>
>>>>>>
>>> https://github.com/ubikloadpack/jmeter/releases/tag/2.14-preview-ubikloapack-1.0.0
>>>
>>>> Users and Dev team can this way download the bundle and test it, page
>>>>>> above mentions all required informations to test, report issues and
>>>>>>
>>>>> see a
>>>>
>>>>> demo.
>>>>>>
>>>>>> We think this feature is really needed in JMeter and it has been
>>>>>>
>>>>> developed
>>>>>
>>>>>> to ensure it never impacts load testing, reports being generated
at
>>>>>>
>>>>> end.
>>>>
>>>>> If you look at code  there is 0 risk of regression as it's an
>>>>>>
>>>>> additional
>>>>
>>>>> behaviour that is activated by new command line options.
>>>>>>
>>>>>> We'll be happy to provide JMeter Team with all requested information
>>>>>> regarding design, implementation ...
>>>>>>
>>>>>> We really hope it will be accepted by the Team.
>>>>>>
>>>>>> Thanks in advance and kudos for all your work on JMeter.
>>>>>>
>>>>>> Regards
>>>>>> Ubik Load Pack Team.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>> --
>>> Richard Friedman
>>> 609.314.0129
>>>
>>>
>>
>


-- 
Cordialement.
Philippe Mouawad.

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