On 5 December 2011 12:21, Milamber <[email protected]> wrote: > On Mon, Dec 5, 2011 at 10:52 AM, sebb <[email protected]> wrote: > >> 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 discussions must stills in dev list / bugzilla. I would say, the wiki > page can be view by the advanced users or the developers (ASF or plugins), > and brings some ideas or suggests in theirs minds for improve a new > features which not release. > This wiki page can be a reference (temporary) for people which share a new > feature with a friend (via twitter/facebook/email) >
OK, I see. In that case it probably warrants a separate Wiki discussion page, separate from release notes. > >> >> > 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. >> > > > I thinks this will complicate the release process, and will not be easy > (how to convert the wiki page with embedded to a html page to include in > release tar? manually/ant?). I was hoping it could be mainly automated, by using a script to convert the content to a suitable format. Run the script, review the result and save to SVN. > We can have : > A wiki page with screen-shots / text for show the good stuff for new > release (JMeterNextRelease). This page can be archived > JMeterReleaseNotesX.X.X during the release process. > (like > http://archive.eclipse.org/eclipse/downloads/drops/R-3.4-200806172000/whatsnew3.4/eclipse-news-all.html- > this page isn't include in the eclipse release) > > The changes.xml with the summary section without screen-shots but with all > new features (like actually), and a link to the wiki page > JMeterReleaseNotesX.X.X > During the release process, some copy/paste from wiki page to populate the > summary section (if needed) It's probably easier to do it just prior to release. Quite often several changes are related, and make more sense described together. Or a change is reverted/redone in a different way. It's also quite a useful exercise to go through all the changes.xml entries to review if they make sense and perhaps reorder related items. This can reveal that some vital fix was accidentally omitted. Yes, it's a bit of extra work just prior to release, but it would have to be done at some point. > When the announcement email of new JMeter version is sent, inside we can > find the 2 links : changes.html for master reference (particulary id > bugzilla) and the wiki release page (with attractive screen-shots to > encourage users to update their version) Good idea. > Milamber > > >> >> > 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. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> > >> >> >>
