On 5 December 2011 09:48, Milamber <[email protected]> wrote: > On Sun, Dec 4, 2011 at 11:08 PM, sebb <[email protected]> wrote: > >> On 4 December 2011 20:22, Milamber <[email protected]> wrote: >> > >> > >> > Le 04/12/2011 20:08, Philippe Mouawad a ecrit : >> >> Hello Sebb, Milamber, Rainer , All, >> >> Regarding changes.xml file, don't you think we should make it less >> >> "textual" and highlight some new features ? >> >> Or maybe create a new page called "New Features" >> >> >> > >> > Yes, good idea. Perhaps a new page "NewInJMeterX.X.X" in JMeter wiki >> > with screen-shots (can be update after a 'visual' improvement). >> > (and a link from changes.xml/html: "Some improvements are detailed on >> > this wiki page") >> > >> > I can initialize this page on Wiki, if you are agreed. >> >> I don't think it should be on the Wiki; it needs to be part of the >> release archives. >> > > > I'm not sure to be agree with you. I thinks Wiki in a good place because : > > * JMeter users can view a preview of new behaviors / improvements before > the new release (or download a nightly build)
That is a good idea. > * Easy to update / publish (and before the release) It's still possible to update the JMeter website after a release - I did that for the TLP move. However, it is a bit more awkard as the updates may have to be applied to trunk as well. > I thinks too, this can improve the JMeter's "visibility", users or > developers can discuss or suggest new improvements on the new behaviors > before release. Possibly, but discussion on the features would need to be done in a separate page (or perhaps as footnotes) otherwise the original page could quickly become unreadable. Not sure if MoinMoin makes that easy. > The Summary section in changes.xml can be reducing to a link to the Wiki > page. No, because it is important that the downloads contain the information. However, the Wiki is useful for supplementing the archives, so it would be OK to link to an page on the Wiki for late-breaking information. But the changes section needs to be as complete as possible when the release is cut. Maybe there is a way to have both? This would probably be easier with a separate release notes page in SVN which corresponds to a separate Wiki page. As the work progresses on a release, the WIki is updated, and just before the release is cut, the Wiki page is renamed ant converted into a suitable format for the achives. The Wiki page can then be corrected after release if necessary. There would need to be a separate page for each release. Probably ReleaseNotesCurrent, which is renamed to ReleaseNotes-2.5.2 just before the release is cut. We don't always know the exact version in advance - in fact, this next release should probably be 2.6 rather than 2.5.1 as there have been a lot of changes. > Another question, if we add some screen-shots to changes.xml (summary > section), how do with old screen-shots after a new release? keep in all > releases tarballs? Same as with all the other screenshots. They are in the source archive, and in the binary archive. > Milamber > > > >> >> That was the idea of the section "Summary of main changes" in changes.xmk >> >> Alternatively, there could be a RELEASE-NOTES.txt file at the top >> level with even more details. >> >> But not a Wiki page. >> >> Whilst working on fixes, it's enough to >> > Milamber >> > >> >> Because IMHO current page is sometimes hard to understand unless you go >> to >> >> bugzilla in details ? >> >> >> >> For example I missed some important features in 2.5. >> >> I think something like Miamber page would be useful: >> >> >> >> - >> >> >> http://blog.milamberspace.net/index.php/2011/08/18/apache-jmeter-2-5-est-sorti-964.html >> >> >> >> >> >> What's your opinion ? >> >> Regards >> >> Philippe >> >> >> >> On Sun, Dec 4, 2011 at 8:54 PM, Philippe Mouawad < >> [email protected] >> >> >> >>> wrote: >> >>> >> >> >> >>> From my tests, I don't have such a drop in performances (max 2%). >> >>> I also don't notice degradation on POST particularly. >> >>> I agree with Sebb, issue are in 2.5 and 2.5.1 so we won't degrade >> things >> >>> in a future 2.5.2. >> >>> >> >>> Regards >> >>> Philippe >> >>> >> >>> >> >>> On Sun, Dec 4, 2011 at 5:27 PM, sebb <[email protected]> wrote: >> >>> >> >>> >> >>>> On 4 December 2011 16:09, Rainer Jung <[email protected]> >> wrote: >> >>>> >> >>>>> On 01.12.2011 22:57, Philippe Mouawad wrote: >> >>>>> >> >>>>>> Hello Sebb, >> >>>>>> Don't you think we could make a release ? >> >>>>>> >> >>>>>> Lots of important fixes have been made and 2 months have passed >> since >> >>>>>> >> >>>> last >> >>>> >> >>>>>> release. >> >>>>>> >> >>>>> >> >>>>> First of all congrats to the huge progress you are making. >> >>>>> >> >>>>> What about BZ52189: "JMeter 2.5.1 slower than 2.4 for HTTP POST >> >>>>> >> >>>> requests" >> >>>> >> >>>>> Is that problem reproducible and really in the range described in the >> >>>>> >> >>>> first >> >>>> >> >>>>> comment, or was that due to comparing different http samplers? >> >>>>> >> >>>> Not sure; I've not been able to reproduce it yet, and the data so far >> >>>> does not give much clue as to what is happening. >> >>>> >> >>>> >> >>>>> A drop in throughput from 130 to 80 just because of a newer version >> >>>>> >> >>>> would be >> >>>> >> >>>>> pretty serious IMHO. Unfortunately I didn't yet have the cycles to >> try >> >>>>> >> >>>> it >> >>>> >> >>>>> myself, but wanted to provide a heads up. >> >>>>> >> >>>> Agreed; however if the problem is difficult to solve I see no harm in >> >>>> releasing another version so long as it is no worse than 2.5.1, and so >> >>>> long as the problem is eventually resolved. >> >>>> >> >>>> >> >>>>> Regards, >> >>>>> >> >>>>> Rainer >> >>>>> >> >>>>> >> >>>> >> >>> >> >>> >> >>> -- >> >>> Cordialement. >> >>> Philippe Mouawad. >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> > >>
