Skip to Content.
Sympa Menu

ndt-dev - Re: [ndt-dev] NDT new version release

Subject: NDT-DEV email list created

List archive

Re: [ndt-dev] NDT new version release


Chronological Thread 
  • From: Will Hawkins <>
  • To: Aaron Brown <>
  • Cc: "" <>
  • Subject: Re: [ndt-dev] NDT new version release
  • Date: Fri, 27 Jun 2014 13:14:12 -0400

Thanks Aaron!

On 06/27/2014 10:02 AM, Aaron Brown wrote:
> Hey Will,
>
> Seems to work for me. The compiler spit out a warning about assignments in
> if statements, so I modified the if statement to look like:
>
>> + var selfUrl:String = URLUtil.getServerName(this.loaderInfo.url);
>> + if (selfUrl) {
>> + server_hostname = selfUrl;
>> + }
>

I think that I was trying to be too clever here. I suppose that the
"assignments have values" idiom does not apply to ActionScript :-)

Will

> Cheers,
> Aaron
>
> On Jun 26, 2014, at 11:04 PM, Will Hawkins
> <>
> wrote:
>
>> How about this?
>>
>> Index: src/Main.as
>> ===================================================================
>> --- src/Main.as (revision 1112)
>> +++ src/Main.as (working copy)
>> @@ -16,6 +16,7 @@
>> import flash.display.Sprite;
>> import flash.events.Event;
>> import mx.resources.ResourceBundle;
>> + import mx.utils.URLUtil;
>> /**
>> * @author Anant Subramanian
>> */
>> @@ -45,6 +46,11 @@
>> private function init(e:Event = null):void {
>> removeEventListener(Event.ADDED_TO_STAGE, init);
>>
>> + var selfUrl:String = null;
>> + if (selfUrl = URLUtil.getServerName(this.loaderInfo.url)) {
>> + server_hostname = selfUrl;
>> + }
>> +
>> // Set the properties of the SWF from HTML tags.
>> NDTUtils.initializeFromHTML(this.root.loaderInfo.parameters);
>>
>>
>> Will
>>
>> On 06/26/2014 01:50 PM, Will Hawkins wrote:
>>>
>>>
>>> On 06/26/2014 09:13 AM, Aaron Brown wrote:
>>>> Hey Will,
>>>>
>>>> On Jun 25, 2014, at 9:51 PM, Will Hawkins
>>>> <>
>>>> wrote:
>>>>
>>>>> I am happy to create a branch for this, but I think that might be
>>>>> overkill. Here's what I added
>>>>>
>>>>> Index: src/Main.as
>>>>> ===================================================================
>>>>> --- src/Main.as (revision 1112)
>>>>> +++ src/Main.as (working copy)
>>>>> @@ -45,6 +45,14 @@
>>>>> private function init(e:Event = null):void {
>>>>> removeEventListener(Event.ADDED_TO_STAGE, init);
>>>>>
>>>>> + var selfUrl:String = this.loaderInfo.url;
>>>>> + if (selfUrl.indexOf("http://";, 0) == 0) {
>>>>> + selfUrl = selfUrl.replace("http://";, "");
>>>>> + selfUrl = selfUrl.replace(/:[0-9]+/, "");
>>>>> + selfUrl = selfUrl.replace(/\/.+$/, "");
>>>>> + server_hostname = selfUrl;
>>>>> + }
>>>>> +
>>>>> // Set the properties of the SWF from HTML tags.
>>>>> NDTUtils.initializeFromHTML(this.root.loaderInfo.parameters);
>>>>
>>>> Looking at the parsing there, it will definitely fail on IPv6 addresses.
>>>> It looks like actionscript has a URL library
>>>> (http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/mx/utils/URLUtil.html)
>>>> that would probably work for returning the address to test against.
>>>>
>>>
>>> Oh, I get it. You don't think that two quickly-hacked-together regexes
>>> covers all possible cases? You'd like me to use a library?
>>>
>>> NO. :-)
>>>
>>> Just kidding, of course. I was actually hoping that loaderInfo.url
>>> returned some type of object that I could easy inquire about the
>>> hostname. But, it seems like the URL library is the way to go. Standby
>>> for another rev.
>>>
>>> Will
>>>
>>>
>>>>> This will make it default to test against an NDT server running on the
>>>>> same host from which the swf was loaded. This does not preclude the user
>>>>> from overriding that value with their JS callback.
>>>>>
>>>>> The other, perhaps easier, option is to do something similar in the JS
>>>>> that hosts the Flash applet. JS would parse window.location and then
>>>>> return that value in the getNDTServer() callback.
>>>>>
>>>>> Let me know which route you prefer!
>>>>
>>>> My general preference would be to encode that default into the Flash
>>>> client to make it as simple as possible to embed the client in webpages.
>>>>
>>>> Cheers,
>>>> Aaron
>>>>
>>>>
>>>>> Will
>>>>>
>>>>> On 06/25/2014 02:22 PM, Aaron Brown wrote:
>>>>>> Hey Will,
>>>>>>
>>>>>> On Jun 25, 2014, at 1:59 PM, Will Hawkins
>>>>>> <>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey Aaron!
>>>>>>>
>>>>>>> I am working on this -- I promise :-)
>>>>>>
>>>>>> Excellent, no rush :)
>>>>>>
>>>>>>> Just to get some context, are you assuming that we would include an
>>>>>>> HTML
>>>>>>> wrapper for the Flash client and invoke the wrapped version to
>>>>>>> actually
>>>>>>> do the self testing? I'm just trying to figure out which of the
>>>>>>> Actionscript facilities I'll have access to in order to resolve this
>>>>>>> dilemma.
>>>>>>
>>>>>> That’s what I’m thinking. Similar to how the java applet works (e.g.
>>>>>> http://desk146.internet2.edu:7123/), you’d go to a webpage and the
>>>>>> flash client would be embedded in the page. You could then just hit
>>>>>> “start”, and it’d do a test from your machine to the server that
>>>>>> served it.
>>>>>>
>>>>>> Cheers,
>>>>>> Aaron
>>>>>>
>>>>>>>
>>>>>>> Will
>>>>>>>
>>>>>>> On 06/24/2014 10:13 AM, Aaron Brown wrote:
>>>>>>>> Hey Will,
>>>>>>>>
>>>>>>>> I’ve got the RPM working with the existing fakewww/Applet.
>>>>>>>>
>>>>>>>> I’d like to include the flash client in the RPM if possible
>>>>>>>> (otherwise, there’s not much benefit to the average RPM install for
>>>>>>>> the new release). Unfortunately, it doesn’t look like there’s a good
>>>>>>>> way to zero-configuration install (i.e. have it by default test back
>>>>>>>> to the server it was served from) without using something like PHP
>>>>>>>> (which would require swapping over to using Apache to serve the
>>>>>>>> clients). Would it be possible to include a setting for the flash
>>>>>>>> client to say “the server to use is the address of the server you
>>>>>>>> downloaded the SWF from”?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Aaron
>>>>>>>>
>>>>>>>> On Jun 20, 2014, at 8:02 PM, Will Hawkins
>>>>>>>> <>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Please let me know if/how I can help preparing the repo for RPM
>>>>>>>>> creation. I'm happy to give it a try on my own, but if there is
>>>>>>>>> expertise elsewhere (Aaron or Sebastian), then I am happy to take a
>>>>>>>>> back
>>>>>>>>> seat.
>>>>>>>>>
>>>>>>>>> As for testers, we (MLab) can definitely find a few places to test.
>>>>>>>>> I
>>>>>>>>> know that we've been running trunk versions of the server on several
>>>>>>>>> test nodes for a while and haven't had any problems (besides the
>>>>>>>>> ones
>>>>>>>>> that I've submitted patches for).
>>>>>>>>>
>>>>>>>>> Will
>>>>>>>>>
>>>>>>>>> On 06/20/2014 09:54 AM, Aaron Brown wrote:
>>>>>>>>>> Hey Sebastian,
>>>>>>>>>>
>>>>>>>>>> I’m untagging the release since I can guarantee we’ll need to make
>>>>>>>>>> changes to the codebase for the NDT RPMs, and those are a
>>>>>>>>>> requirement for outside testing since a very small percentage of
>>>>>>>>>> NDT servers out there are compiled from source. I’ll commit some
>>>>>>>>>> of the RPM bits, and then if you could go through, and make sure
>>>>>>>>>> that it gets updated as needed for the changes (new web UI, etc),
>>>>>>>>>> that’d be good. The goal of the NDT RPMs is that the
>>>>>>>>>> administrators can do “yum install ndt-server”, start NDT and it
>>>>>>>>>> just works. They don’t have to do any hand configuration to get an
>>>>>>>>>> NDT server up-and-running.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Aaron
>>>>>>>>>>
>>>>>>>>>> On Jun 20, 2014, at 5:15 AM, Sebastian Kostuch
>>>>>>>>>> <>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>> Will, I have merged your last fixes into trunk so they will be
>>>>>>>>>>> contained within
>>>>>>>>>>> new release :).
>>>>>>>>>>> Aaron, keeping in mind what you have said I have changed version
>>>>>>>>>>> numbers
>>>>>>>>>>> to be release candidate and tagged this. Such tagged version is
>>>>>>>>>>> now ready
>>>>>>>>>>> for being tested by outside folks. I hope that test stage will
>>>>>>>>>>> perform smoothly
>>>>>>>>>>> and we would release new NDT version ASAP!
>>>>>>>>>>> Also I have updated wiki pages to match new protocol changes.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Sebastian Kostuch
>>>>>>>>>>>
>>>>>>>>>>> On 18.06.2014 23:00, Will Hawkins wrote:
>>>>>>>>>>>> Aaron,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the information! We (M-Lab) are especially interested
>>>>>>>>>>>> in
>>>>>>>>>>>>
>>>>>>>>>>>> a) having the code "checked" to make sure that the measurements
>>>>>>>>>>>> are
>>>>>>>>>>>> still valid
>>>>>>>>>>>>
>>>>>>>>>>>> and
>>>>>>>>>>>>
>>>>>>>>>>>> b) having a release to deploy on the platform.
>>>>>>>>>>>>
>>>>>>>>>>>> Having said that, what is the best way to prepare a release
>>>>>>>>>>>> candidate to
>>>>>>>>>>>> start the process rolling? Are you able to help verify the
>>>>>>>>>>>> measurements
>>>>>>>>>>>> made with the new version of the tool? Will you be able to help,
>>>>>>>>>>>> generally, with the release process (since, I mean, you're
>>>>>>>>>>>> awesome!)?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks again for your email!
>>>>>>>>>>>> Will
>>>>>>>>>>>>
>>>>>>>>>>>> On 06/18/2014 04:46 PM, Aaron Brown wrote:
>>>>>>>>>>>>> Hi Sebastian,
>>>>>>>>>>>>>
>>>>>>>>>>>>> To do a full release, NDT will need to go through a release
>>>>>>>>>>>>> candidate process to ensure that outside folks have a chance to
>>>>>>>>>>>>> test it before something gets labeled as “released”. Beyond
>>>>>>>>>>>>> that, NDT will need verified to make sure that something didn’t
>>>>>>>>>>>>> break with existing clients (important since this is a less
>>>>>>>>>>>>> common use-case). The upgrade process needs to be verified as
>>>>>>>>>>>>> well to make sure that it doesn’t break an existing
>>>>>>>>>>>>> installation when someone goes to upgrade.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As part of the upgrade procedure above, the RPMs will need
>>>>>>>>>>>>> updated with any changes in the codebase since that’s the
>>>>>>>>>>>>> primary method folks use to install NDT (the vast majority of
>>>>>>>>>>>>> NDT installations in the wild are installed as part of the
>>>>>>>>>>>>> perfSONAR Performance Toolkit). This procedure will need tested
>>>>>>>>>>>>> to make sure that both new installs, and existing installs work
>>>>>>>>>>>>> as expected.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Once there’s a final release, the NDT RPMs will get added to
>>>>>>>>>>>>> the Internet2 RPM repository (where the Toolkit users get their
>>>>>>>>>>>>> RPMs from), and the source tarball will be added to the
>>>>>>>>>>>>> Internet2 site at software.internet2.edu). Presumably, this
>>>>>>>>>>>>> link could be used as canonical for NDT since any linked
>>>>>>>>>>>>> location is arbitrary from the end user perspective.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Aaron
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jun 18, 2014, at 6:04 AM, Sebastian Kostuch
>>>>>>>>>>>>> <>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi again,
>>>>>>>>>>>>>> new NDT version is coming soon, however there are last changes
>>>>>>>>>>>>>> to be performed
>>>>>>>>>>>>>> before this. I have merged all changes to release into trunk,
>>>>>>>>>>>>>> tested and fixed individual
>>>>>>>>>>>>>> small bugs. Next step will be to update our wiki pages to
>>>>>>>>>>>>>> match new version which I will
>>>>>>>>>>>>>> be working on in nearest time.
>>>>>>>>>>>>>> However I wanted to ask two last questions to you:
>>>>>>>>>>>>>> 1. So far new release package has been published in
>>>>>>>>>>>>>> "downloads" section of google code
>>>>>>>>>>>>>> project but recently Google has disabled this option.
>>>>>>>>>>>>>> Therefore should we place such archive
>>>>>>>>>>>>>> in some external source like Google drive where users could
>>>>>>>>>>>>>> directly download this (and update
>>>>>>>>>>>>>> wiki with such link)? Or maybe just publish link to release
>>>>>>>>>>>>>> tagged revision?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. Also what about updating NDT links/software on another
>>>>>>>>>>>>>> sites? I know that it will be performed
>>>>>>>>>>>>>> on M-lab but what about Internet2 website?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 18.06.2014 09:06, Sebastian Kostuch wrote:
>>>>>>>>>>>>>>> Hi Will
>>>>>>>>>>>>>>> indeed these changes results in higher speeds (I was able to
>>>>>>>>>>>>>>> get ~760 mbps
>>>>>>>>>>>>>>> which is quite similar to yours). Also I have checked flash
>>>>>>>>>>>>>>> client as background
>>>>>>>>>>>>>>> for new JS UI and both speeds are being updated correctly in
>>>>>>>>>>>>>>> real-time. This is
>>>>>>>>>>>>>>> really great work! Thanks for this. I have merged these
>>>>>>>>>>>>>>> changes into trunk so
>>>>>>>>>>>>>>> they would be also present in new release.
>>>>>>>>>>>>>>> Also as you probably have noticed I have fixed compilation
>>>>>>>>>>>>>>> error when using
>>>>>>>>>>>>>>> web100 so I closed appropriated issue related to this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 17.06.2014 22:52, Will Hawkins wrote:
>>>>>>>>>>>>>>>> Hello Sebastian and Aaron (and MLab'ers CC'd),
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We found a way to juice the Flash client and achieve the
>>>>>>>>>>>>>>>> performance
>>>>>>>>>>>>>>>> necessary to accurately measure high-speed network
>>>>>>>>>>>>>>>> connections.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The change is in r1082.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The solution was counterintuitive (at least for me). Instead
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> attempting to read data from the socket as quickly as
>>>>>>>>>>>>>>>> possible, the
>>>>>>>>>>>>>>>> TestS2C class just gets out of the way for the duration of
>>>>>>>>>>>>>>>> the test. It
>>>>>>>>>>>>>>>> registers only for the "socket close" event. The runtime has
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> necessary speed to keep up with the network.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only problem with this method is keeping the user
>>>>>>>>>>>>>>>> interface
>>>>>>>>>>>>>>>> up-to-date on progress throughout the test. Sebastian, this
>>>>>>>>>>>>>>>> is where I
>>>>>>>>>>>>>>>> need you to double check. I believe that the code in r1082
>>>>>>>>>>>>>>>> properly
>>>>>>>>>>>>>>>> updates _s2cByteCount in the appropriate spot for those
>>>>>>>>>>>>>>>> real-time
>>>>>>>>>>>>>>>> updates (specifically onSpeedUpdate). But, please double
>>>>>>>>>>>>>>>> check!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We were able to measure a connection at ~ 775 mbps using the
>>>>>>>>>>>>>>>> Flash
>>>>>>>>>>>>>>>> client, but it would be great to have as many people test
>>>>>>>>>>>>>>>> this as
>>>>>>>>>>>>>>>> possible. To do so, you can use a pre-compiled version at
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://files.opentechinstitute.org/~hawkinsw/flash/test.html
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On a separate, but related note, please also review r1083
>>>>>>>>>>>>>>>> for inclusion
>>>>>>>>>>>>>>>> in the NDT release. This change allows the client to
>>>>>>>>>>>>>>>> re-query JS for the
>>>>>>>>>>>>>>>> test's hostname just before launching a test. This gives the
>>>>>>>>>>>>>>>> wrapper
>>>>>>>>>>>>>>>> page the opportunity to do a AJAX query to determine the
>>>>>>>>>>>>>>>> test's
>>>>>>>>>>>>>>>> hostname. This is important for MLab because we do dynamic
>>>>>>>>>>>>>>>> server
>>>>>>>>>>>>>>>> selection using a web-based API.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I am eager to hear whether you have success with these
>>>>>>>>>>>>>>>> changes or not. I
>>>>>>>>>>>>>>>> hope you do!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Will
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 06/17/2014 10:53 AM, Will Hawkins wrote:
>>>>>>>>>>>>>>>>> Just FYI: I believe that we have happened on to an actual
>>>>>>>>>>>>>>>>> solution for
>>>>>>>>>>>>>>>>> the "limit" to the performance of the S2C test. I am going
>>>>>>>>>>>>>>>>> to implement
>>>>>>>>>>>>>>>>> it today and do some testing.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If possible, could we hold out on doing a release for a
>>>>>>>>>>>>>>>>> little while
>>>>>>>>>>>>>>>>> pending this investigation?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Will
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 06/16/2014 01:50 AM, Sebastian Kostuch wrote:
>>>>>>>>>>>>>>>>>> Hi Will,
>>>>>>>>>>>>>>>>>> what you mentioned seems reasonable. Would it be possible
>>>>>>>>>>>>>>>>>> to merge these
>>>>>>>>>>>>>>>>>> needed
>>>>>>>>>>>>>>>>>> changes into trunk in nearest time so we could make new
>>>>>>>>>>>>>>>>>> release for
>>>>>>>>>>>>>>>>>> example tomorrow
>>>>>>>>>>>>>>>>>> or the day after tomorrow?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards
>>>>>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 13.06.2014 17:36, Will Hawkins wrote:
>>>>>>>>>>>>>>>>>>> Sebastian,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks for sending this out! We (at MLab) are very
>>>>>>>>>>>>>>>>>>> interested in
>>>>>>>>>>>>>>>>>>> deploying a new version of the code so this 'release'
>>>>>>>>>>>>>>>>>>> looks like a
>>>>>>>>>>>>>>>>>>> good place to fit together! :-) In other words, we
>>>>>>>>>>>>>>>>>>> (again, MLab) are
>>>>>>>>>>>>>>>>>>> definitely going to do what you said in 3!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I am out of the office, but I wanted to quickly respond
>>>>>>>>>>>>>>>>>>> to point 2.
>>>>>>>>>>>>>>>>>>> See below!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks again for driving this process forward!!
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Will
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 6/13/14, 4:47 AM, Sebastian Kostuch wrote:
>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>> NDT has been updated recently with some major changes
>>>>>>>>>>>>>>>>>>>> (like
>>>>>>>>>>>>>>>>>>>> MSG_EXTENDED_LOGIN,
>>>>>>>>>>>>>>>>>>>> json support, new JS UI) so as I have mentioned in some
>>>>>>>>>>>>>>>>>>>> earlier mail
>>>>>>>>>>>>>>>>>>>> that would be probably
>>>>>>>>>>>>>>>>>>>> good time to make new release. I have few questions
>>>>>>>>>>>>>>>>>>>> related to this:
>>>>>>>>>>>>>>>>>>>> 1. New JS UI would fit well within this new release,
>>>>>>>>>>>>>>>>>>>> however changes
>>>>>>>>>>>>>>>>>>>> related to this are still
>>>>>>>>>>>>>>>>>>>> on work branches and need review. Any feedback would be
>>>>>>>>>>>>>>>>>>>> very
>>>>>>>>>>>>>>>>>>>> appreciated. These are
>>>>>>>>>>>>>>>>>>>> following issues: 129, 132, 133.
>>>>>>>>>>>>>>>>>>>> 2. Is Issue144 (URLLoader to flash) supposed to be
>>>>>>>>>>>>>>>>>>>> contained also in
>>>>>>>>>>>>>>>>>>>> nearest release version?
>>>>>>>>>>>>>>>>>>>> If yes, then how does progress with work on this look
>>>>>>>>>>>>>>>>>>>> like? If I recall
>>>>>>>>>>>>>>>>>>>> correctly then you, Will,
>>>>>>>>>>>>>>>>>>>> mentioned that they are well tested and thus almost
>>>>>>>>>>>>>>>>>>>> ready, right?
>>>>>>>>>>>>>>>>>>> Some of these are still up for debate. I am going to
>>>>>>>>>>>>>>>>>>> forward an email
>>>>>>>>>>>>>>>>>>> that I just sent to the MLab team with an update on the
>>>>>>>>>>>>>>>>>>> conundrum
>>>>>>>>>>>>>>>>>>> around the HTTP test to give you a sense about why they
>>>>>>>>>>>>>>>>>>> are up for
>>>>>>>>>>>>>>>>>>> debate.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But, there are also changes in that branch that *need* to
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> incorporated into anything that gets released. For
>>>>>>>>>>>>>>>>>>> instance, r1070.
>>>>>>>>>>>>>>>>>>> There are parts of r1064 that will have to be integrated
>>>>>>>>>>>>>>>>>>> no matter
>>>>>>>>>>>>>>>>>>> what (any of the changes that have to do with splitting
>>>>>>>>>>>>>>>>>>> start test and
>>>>>>>>>>>>>>>>>>> finalize test stages).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Does that make sense?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 3. Along with new release on googlecode what do you
>>>>>>>>>>>>>>>>>>>> think about pushing
>>>>>>>>>>>>>>>>>>>> these changes also
>>>>>>>>>>>>>>>>>>>> on M-Lab site? They bring many new features at all.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Looking forward to your answers and I hope that next
>>>>>>>>>>>>>>>>>>>> week could be
>>>>>>>>>>>>>>>>>>>> celebrated with making
>>>>>>>>>>>>>>>>>>>> new release of NDT :).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Kind regards
>>>>>>>>>>>>>>>>>>>> Sebastian Kostuch
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>



Archive powered by MHonArc 2.6.16.

Top of Page