Skip to Content.
Sympa Menu

ndt-dev - Re: [ndt-dev] Re: [M-lab-ops] Deploy new NDT client that logs client application.

Subject: NDT-DEV email list created

List archive

Re: [ndt-dev] Re: [M-lab-ops] Deploy new NDT client that logs client application.

Chronological Thread 
  • From: "Jeff W. Boote" <>
  • To: Thomas Gideon <>
  • Cc: , M-Lab Operations <>,
  • Subject: Re: [ndt-dev] Re: [M-lab-ops] Deploy new NDT client that logs client application.
  • Date: Mon, 22 Aug 2011 12:00:46 -0600

On Aug 22, 2011, at 11:14 AM, Thomas Gideon wrote:

> Hash: SHA256
> On 08/22/2011 12:00 PM, Jeff W. Boote wrote:
>> This strategy is somewhat messy because I don't believe the version
>> of the protocol is differentiated very well from the version of the
>> software. We just completed a protocol document and I would assume
>> that you would want to tie this new version of the software to the
>> same version of the protocol.
>> If we come up with a reasonable way to address that issue (I don't
>> know, perhaps hyphenate the version so the protocol version is first
>> and then there is a software version appended) then this works for
>> releasing.
> I believe the code changes are consistent with the current version of
> the protocol as documented. I concur about making the software version
> distinct and clear from the protocol version. I am fine with hyphenating
> in the protocol version.


> Should this change than bump the least significant portion of the
> software version over the last release? What is your actual release
> process, in terms of tagging, merging/branching for further maintenance,
> building downloadable versions, etc.?

The process has not really been documented or formalized in the past since it
was primarily just Rich (and/or Jakub more recently) so a lot coordination
didn't need to take place. (Rich certainly had a specific process he went
through, but we will want to do something slightly different here to match it
up with the other projects we are supporting. For example, we will be
creating tags for releases.)

Since these changes are just in your client branch, I'll leave it up to you.
If you want to tag a release branch I think that is a fine idea so you have
an easier way to deal with any patches you may need. But this version is
likely pretty short lived so I don't care too much either way.

I do plan to have a release tagged from the restructuring work we are doing
once that is closer to complete. We will need to discuss if you want us to
put out a specific release from that. I suspect not directly since you will
want to incorporate your changes first. (We can coordinate more on that as
the time gets closer.)

>> This does not address the eventual merging of this functionality
>> back into the trunk and future releases. For that, I believe we
>> discussed waiting until the current code restructuring was complete.
>> (Nov 1 is current scheduled timeframe.) Thomas, didn't you say you
>> could merge these changes in at that point?
> Yes, the changes are pretty trivial so if they do not cleanly merge into
> the post-clean up code it shouldn't take very long at all to manually
> re-add them.

Sounds good. Thanks.


> - -T
>> On Aug 22, 2011, at 6:10 AM, Jason Zurawski wrote:
>>> All;
>>> On 8/19/11 4:47 PM, thus spake Thomas Gideon:
>>>> On 08/19/2011 04:39 PM, Tiziana Refice wrote:
>>>>>> To deploy the new client, do we need to contact all the
>>>>>> partners that are currently embedding the NDT client in
>>>>>> their own tools (BitTorrent, EETT, FCC, possible others)?
>>>> To deploy a new client, we need to coordinate with I2 first to
>>>> make sure we don't step on any toes in their release process and
>>>> so my changes get incorporated into subsequent releases. Once we
>>>> do, we can roll out to our servers which will update the web
>>>> client on the M-Lab site, too.
>>> CCing NDT-dev so they are aware. I believe as long as you choose
>>> a version number that reflects this is not the mainline (e.g.
>>> something that notes its from an mlab specific branch) you can
>>> release the server/applet on your own time. Jeff can comment if
>>> he would prefer to see this done in another way.
>>> Thanks;
>>> -jason
>>>> Deploying on our systems first should not cause any breakages
>>>> with other existing clients but, yes, we should advise others to
>>>> make the client changes as soon as possible. The change is
>>>> pretty trivial, just one extra message during the meta portion of
>>>> the test.
>>>> - -- Thomas Gideon Sr. Staff Technologist, Open Technology
>>>> Initiative New American Foundation
> - --
> Thomas Gideon
> Sr. Staff Technologist, Open Technology Initiative
> New American Foundation
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla -
> iEYEAREIAAYFAk5Sjm0ACgkQ65xMDm9EZnOVJwCgm/Xp9YeNndgr+8TlDTrijQpp
> iRYAn2MsSTqy8/F/YQsT75g6EKcc4Dwi
> =oJMx

Archive powered by MHonArc 2.6.16.

Top of Page