Re: JMeter wiki

[Gavin McDonald]

We could look to migrating content to our Confluence wiki ?

Gav…


> On 12 Apr 2018, at 6:03 am, Antonio Gomes Rodrigues  wrote:
> 
> Hi,
> 
> I thnik we need to drop it
> 
> Antonio
> 
> 2018-04-11 21:56 GMT+02:00 Philippe Mouawad :
> 
>> Hello,
>> Looking at JMeter wiki, I wonder if it's useful and if it serves the
>> project.
>> IMO, a newbie seeing it might think JMeter is largely outdated
>> 
>>   - The look of pages is awful
>>   - The content is largely outdated and gives IMO a bad image of the
>>   project:
>>  - https://wiki.apache.org/jmeter/FutureReleases
>>  - https://wiki.apache.org/jmeter/Java14Proposals
>>  - https://wiki.apache.org/jmeter/BuildingJMeter
>>  - https://wiki.apache.org/jmeter/JMeterAndEclipseHowTo
>>  - https://wiki.apache.org/jmeter/JMeterArchitecturalOverview
>>  - https://wiki.apache.org/jmeter/JMeterDevelopment/Requirements
>>  - ...
>> 
>> 
>> So what should we do ?
>> 
>>   - Drop it ?
>>   - Make some spring cleanup ? Drop 70%
>> 
>> 
>> --
>> Regards.
>> Philippe
>> 

Re: About Mailing list guidelines

[Philippe Mouawad]

On Wed, Apr 11, 2018 at 10:15 PM, sebb  wrote:

> On 11 April 2018 at 20:41, Philippe Mouawad
>  wrote:
> > Hello,
> > Today when users want to ask a question about JMeter there are many ways:
> >
> >
> >- Our way:
> >   - User mailing list
> >   - Other ways:
> >   - https://stackoverflow.com/questions/tagged/jmeter
> >   - There is a slack for jmeter
> >
> > So if we look at our mailing list:
> >
> >- http://jmeter.apache.org/mail.html
> >- http://jmeter.apache.org/mail2.html
> >
> > The left link on website goes to mail.html and there is some long text to
> > read:
> >
> >- Do users read it ?
> >- If we look at its content, it is very defensive:
>
> I did not write the original, but I think it is sensible, rather than
> defensive.
>

I wrote part of it, and I think now reading it again that it can be seen as
distrustful to users.

>
> >   - *Respect the mailing list type *
> >   - *Join the lists that are appropriate for your discussion.*
> >   -
> > *Ask smart questions. *
> >   - *Keep your email short and to the point; use a suitable subject
> >   line. *
> >   - *Do your best to ensure that you are not sending HTML or
> "Stylized"
> >   email to the list.*
> >   - *Please don't send attachments or include large chunks of code*
> >   - *Do not cross post messages. *
> >   -
> > *Watch where you are sending email. *
> >- *Isn't it kind of scary for the newbie who wants to ask some
> question
> >?*
>
> Once an email has been sent, in general it cannot be removed or redacted.
>

Yes but this can happen today no ?

>
> >
> > Shouldn't we just remove mail.html and  directly link to mail2.html and
> > mention guidelines in it ?
>
> The point was to try and get people to read the guidelines.
>

I think people who don't want to read them won't wherever we put them and
will directly find the link or ask somewhere else which is what is
happening looking at number of question on SO vs questions on User mailing
list
People who want to read them will do even if we change the order.
So another  approach would be:

   - let's trust users and encourage this way of asking



> >
> > --
> > Regards.
> > Philippe
>



-- 
Cordialement.
Philippe Mouawad.

Re: About Mailing list guidelines

[sebb]

On 11 April 2018 at 20:41, Philippe Mouawad
 wrote:
> Hello,
> Today when users want to ask a question about JMeter there are many ways:
>
>
>- Our way:
>   - User mailing list
>   - Other ways:
>   - https://stackoverflow.com/questions/tagged/jmeter
>   - There is a slack for jmeter
>
> So if we look at our mailing list:
>
>- http://jmeter.apache.org/mail.html
>- http://jmeter.apache.org/mail2.html
>
> The left link on website goes to mail.html and there is some long text to
> read:
>
>- Do users read it ?
>- If we look at its content, it is very defensive:

I did not write the original, but I think it is sensible, rather than defensive.

>   - *Respect the mailing list type *
>   - *Join the lists that are appropriate for your discussion.*
>   -
> *Ask smart questions. *
>   - *Keep your email short and to the point; use a suitable subject
>   line. *
>   - *Do your best to ensure that you are not sending HTML or "Stylized"
>   email to the list.*
>   - *Please don't send attachments or include large chunks of code*
>   - *Do not cross post messages. *
>   -
> *Watch where you are sending email. *
>- *Isn't it kind of scary for the newbie who wants to ask some question
>?*

Once an email has been sent, in general it cannot be removed or redacted.

>
> Shouldn't we just remove mail.html and  directly link to mail2.html and
> mention guidelines in it ?

The point was to try and get people to read the guidelines.

>
> --
> Regards.
> Philippe

Re: JMeter wiki

[Antonio Gomes Rodrigues]

Hi,

I thnik we need to drop it

Antonio

2018-04-11 21:56 GMT+02:00 Philippe Mouawad :

> Hello,
> Looking at JMeter wiki, I wonder if it's useful and if it serves the
> project.
> IMO, a newbie seeing it might think JMeter is largely outdated
>
>- The look of pages is awful
>- The content is largely outdated and gives IMO a bad image of the
>project:
>   - https://wiki.apache.org/jmeter/FutureReleases
>   - https://wiki.apache.org/jmeter/Java14Proposals
>   - https://wiki.apache.org/jmeter/BuildingJMeter
>   - https://wiki.apache.org/jmeter/JMeterAndEclipseHowTo
>   - https://wiki.apache.org/jmeter/JMeterArchitecturalOverview
>   - https://wiki.apache.org/jmeter/JMeterDevelopment/Requirements
>   - ...
>
>
> So what should we do ?
>
>- Drop it ?
>- Make some spring cleanup ? Drop 70%
>
>
> --
> Regards.
> Philippe
>

JMeter wiki

[Philippe Mouawad]

Hello,
Looking at JMeter wiki, I wonder if it's useful and if it serves the
project.
IMO, a newbie seeing it might think JMeter is largely outdated

   - The look of pages is awful
   - The content is largely outdated and gives IMO a bad image of the
   project:
  - https://wiki.apache.org/jmeter/FutureReleases
  - https://wiki.apache.org/jmeter/Java14Proposals
  - https://wiki.apache.org/jmeter/BuildingJMeter
  - https://wiki.apache.org/jmeter/JMeterAndEclipseHowTo
  - https://wiki.apache.org/jmeter/JMeterArchitecturalOverview
  - https://wiki.apache.org/jmeter/JMeterDevelopment/Requirements
  - ...


So what should we do ?

   - Drop it ?
   - Make some spring cleanup ? Drop 70%


-- 
Regards.
Philippe

[Jmeter Wiki] Update of "SupportAndTraining" by Philippe Mouawad

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jmeter Wiki" for change 
notification.

The "SupportAndTraining" page has been changed by Philippe Mouawad:
https://wiki.apache.org/jmeter/SupportAndTraining?action=diff=13=14

Comment:
Update broken links

  JMeter and web applications performance testing trainings. Most effective, 
customized, cost effective training provider. 
  
  === UBIK-INGENIERIE ===
- JMeter Commercial Plugins for Flex, GWT and JSON:
-  * http://www.ubik-ingenierie.com/blog/ubik-load-pack/
+ JMeter Commercial Plugins for Video Streaming, GWT, Autocorrelator for 
VAADIN, JDEdwards..., Java Serialization, Flex:
+  * https://ubikloadpack.com/
  Load Testing, Tuning and Technical Auditing: 
-  * http://www.ubik-ingenierie.com/-Nos-metiers,3-
+  * https://ubikloadpack.com/our-services.php
  Training : 
   * http://www.ubik-ingenierie.com/blog/jmeter_training/
  

Jenkins build is back to normal : JMeter Windows #1076

[Apache Jenkins Server]

See 

Re: Volunteer: maven / Java9

[Philippe Mouawad]

Hello Márk,
Thanks for your proposal.

It is in scope to do that I think.
Regarding Java 9/10/11, for now we want to support Java 8 for some long
period + upper Java versions, so any work must not break the compatibility.
Regarding Maven, our issue is lack of time and the high customization in
JMeter build, but any improvement is welcome.

Finally, Github is the mirror of svn but you can propose PR without problem:

   - https://github.com/apache/jmeter/blob/trunk/CONTRIBUTING.md

Regards

On Wed, Apr 11, 2018 at 3:37 PM, Márk  wrote:

> Hi everyone,
>
> I got into performance testing (as a Java dev) a while ago and I am
> interested in helping out the tool I mostly use (jMeter).
> I do not know if there is a newcomer best practice in here, but I would
> participate in the development if possible.
>
> As I see the build is still based on Ant. I was thinking a bit and what if
> we try to migrate to maven and Java9 with proper modularization?
> I know that this is an enormous task, I just want to see if it is in scope
> to move to that direction.
>
> Is github the primary place for source code?
>
> ---
> Mark
>



-- 
Cordialement.
Philippe Mouawad.

Volunteer: maven / Java9

[Márk]

Hi everyone,

I got into performance testing (as a Java dev) a while ago and I am
interested in helping out the tool I mostly use (jMeter).
I do not know if there is a newcomer best practice in here, but I would
participate in the development if possible.

As I see the build is still based on Ant. I was thinking a bit and what if
we try to migrate to maven and Java9 with proper modularization?
I know that this is an enormous task, I just want to see if it is in scope
to move to that direction.

Is github the primary place for source code?

---
Mark

Re: Bug 60190 - Content-Type is added for POST unconditionally

[Philippe Mouawad]

Hello,
Bug is fixed in nightly build (use jenkins last build), if reported can
give us some feedback, it would be nice.

Thanks

On Mon, Oct 16, 2017 at 10:12 PM, Epp, J Wyatt  wrote:

> > -Original Message-
> > From: Philippe Mouawad [mailto:p.moua...@ubik-ingenierie.com]
> > Sent: Wednesday, 11 October, 2017 14:45
> > To: dev@jmeter.apache.org
> > Subject: Re: Bug 60190 - Content-Type is added for POST unconditionally
> >
> > Hello
> > Any feedback on this ?
>
> Sorry, been working on other things and haven't been following the list
> closely.
>
> > On Fri, Sep 8, 2017 at 2:12 PM, Philippe Mouawad <
> > p.moua...@ubik-ingenierie.com> wrote:
> >
> >> Hello,
> >> How about not adding this anymore if not set and having a property that
> >> allows to do that ?
> >>
> >>- post_add_content_type_if_missing=false
>
> If I read you correctly, the idea is to default to _not_ adding a default
> content-type, but leave the option? That seems fine.  As the OP for this
> bug, I would certainly like to see it fixed; it creates some annoying
> special cases for us.  Even setting aside our self-interest, from a design
> standpoint, it violates the principle of least astonishment: there's no
> indication anywhere that this behaviour exists, which makes debugging
> problems caused by it rather tricky.
>
> The way I see it, if you're recording, it should _always_ record,
> verbatim, exactly the traffic that passes between the client and server.
> The real world sucks and browsers don't always do what they "SHOULD"; no
> need to confuse the issue further.
>
> >> What is the risk ?
>
> Honestly, I'd be a bit surprised to find anything relying on this
> behaviour.  As you note from the spec, the default lowering should be to
> "application/octet-stream", not "application/x-www-form-urlencoded", so
> anyone looking for that type should have no reasonable expectation that
> they'll find it.
>
> Cheers,
> Wyatt
>
> Confidentiality Notice: This electronic message transmission, including
> any attachment(s), may contain confidential, proprietary, or privileged
> information from Chemical Abstracts Service ("CAS"), a division of the
> American Chemical Society ("ACS"). If you have received this transmission
> in error, be advised that any disclosure, copying, distribution, or use of
> the contents of this information is strictly prohibited. Please destroy all
> copies of the message and contact the sender immediately by either replying
> to this message or calling 614-447-3600.
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: buildbot exception in on jmeter-nightly

[Gavin McDonald]

> On 11 Apr 2018, at 10:06 pm, Philippe Mouawad  
> wrote:
> 
> Thanks Gavin.
> 
> It seems our nightly build builbot is down, is it due to current migration ?

I’ll be able to take a look at that in a few hours.

Gav…

> 
> 
> Thanks
> 
> On Fri, Apr 6, 2018 at 2:05 PM, Gavin McDonald 
> wrote:
> 
>> Disk space on this node has been fixed, sorry about that.
>> 
>> Gav…
>> 
>> 
>>> On 6 Apr 2018, at 12:23 pm, build...@apache.org wrote:
>>> 
>>> The Buildbot has detected a build exception on builder jmeter-nightly
>> while building . Full details are available at:
>>>   https://ci.apache.org/builders/jmeter-nightly/builds/1001
>>> 
>>> Buildbot URL: https://ci.apache.org/
>>> 
>>> Buildslave for this Build: bb_slave7_ubuntu
>>> 
>>> Build Reason: The Nightly scheduler named 'jmeterNightly' triggered this
>> build
>>> Build Source Stamp: [branch jmeter/trunk] HEAD
>>> Blamelist:
>>> 
>>> BUILD FAILED: exception shell_6 upload
>>> 
>>> Sincerely,
>>> -The Buildbot
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Cordialement.
> Philippe Mouawad.

Re: buildbot exception in on jmeter-nightly

[Philippe Mouawad]

Thanks Gavin.

It seems our nightly build builbot is down, is it due to current migration ?


Thanks

On Fri, Apr 6, 2018 at 2:05 PM, Gavin McDonald 
wrote:

> Disk space on this node has been fixed, sorry about that.
>
> Gav…
>
>
> > On 6 Apr 2018, at 12:23 pm, build...@apache.org wrote:
> >
> > The Buildbot has detected a build exception on builder jmeter-nightly
> while building . Full details are available at:
> >https://ci.apache.org/builders/jmeter-nightly/builds/1001
> >
> > Buildbot URL: https://ci.apache.org/
> >
> > Buildslave for this Build: bb_slave7_ubuntu
> >
> > Build Reason: The Nightly scheduler named 'jmeterNightly' triggered this
> build
> > Build Source Stamp: [branch jmeter/trunk] HEAD
> > Blamelist:
> >
> > BUILD FAILED: exception shell_6 upload
> >
> > Sincerely,
> > -The Buildbot
> >
> >
> >
>
>


-- 
Cordialement.
Philippe Mouawad.

Re: Move Bugzilla to JIRA ?

[Gavin McDonald]

The ASF supports writable Github (mirrored back to our own gitbox.a.o). 
Github Issues is also supported, and all Issues are sent to a mailing list of 
your choice.

If you don’t like BZ or Jira, Github is an option .. at a cost … we do not 
support GitHub 
for SVN based projects.

HTH

Gav…


> On 11 Apr 2018, at 5:00 pm, Vladimir Sitnikov  
> wrote:
> 
> Felix> Bugzilla looks old, but works.
> 
> +1
> I'm not sure if migrating to JIRA would attract more users/developers.
> 
> I'm not sure if Apache has mailing archive support for GitHub issues.
> Plain "GitHub issues" are not searchable (one does not simply find a GitHub
> issue in Google due to https://github.com/robots.txt ), so a sophisticated
> archiving of the comments should be installed.
> 
> There's on-going issue for "mailing list support" for Gitlab:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/4272
> 
> Vladimir

Re: Move Bugzilla to JIRA ?

[Vladimir Sitnikov]

Felix> Bugzilla looks old, but works.

+1
I'm not sure if migrating to JIRA would attract more users/developers.

I'm not sure if Apache has mailing archive support for GitHub issues.
Plain "GitHub issues" are not searchable (one does not simply find a GitHub
issue in Google due to https://github.com/robots.txt ), so a sophisticated
archiving of the comments should be installed.

There's on-going issue for "mailing list support" for Gitlab:
https://gitlab.com/gitlab-org/gitlab-ce/issues/4272

Vladimir