Skip to Content.
Sympa Menu

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

Subject: NDT-DEV email list created

List archive

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

Chronological Thread 
  • From: Thomas Gideon <>
  • To: Stephen Stuart <>
  • Cc: "Jeff W. Boote" <>, , M-Lab Operations <>
  • Subject: Re: [M-lab-ops] [ndt-dev] Re: Deploy new NDT client that logs client application.
  • Date: Mon, 22 Aug 2011 15:13:03 -0400
  • Organization: New America Foundation

Hash: SHA256

It was fully my intent to create a tag, just as a matter of best
practice. My original query was as much to see if Jeff had a preference
for where that tag should be cut, which he answered along the way.

- -T

On 08/22/2011 02:23 PM, Stephen Stuart wrote:
> Point of order - there MUST be a tag describing what is deployed in
> M-Lab so that we can credibly say to the community that 1) we know
> what is deployed on our platform, and 2) someone else can inspect the
> specific running code that is running on the platform.
> On Mon, Aug 22, 2011 at 11:00 AM, Jeff W. Boote
> <>
> wrote:
>> On Aug 22, 2011, at 11:14 AM, Thomas Gideon wrote:
> 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.
>>> great.
> 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.
>>> jeff
> -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
>> _______________________________________________ M-lab-ops mailing
>> list

- --
Thomas Gideon
Sr. Staff Technologist, Open Technology Initiative
New American Foundation
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Archive powered by MHonArc 2.6.16.

Top of Page