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: Stephen Stuart <>
  • To: "Jeff W. Boote" <>
  • Cc: Thomas Gideon <>, , M-Lab Operations <>
  • Subject: Re: [M-lab-ops] [ndt-dev] Re: Deploy new NDT client that logs client application.
  • Date: Mon, 22 Aug 2011 11:23:04 -0700
  • Domainkey-signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=QcNCzsT+jKc322jzjrkZtfMOh/VLr75XaMlu/euhvwhH9pi2z6QRdb4ZZ7MMtp73K E2jdDuE2cIwCmiui9nt/g==

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:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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.
>
> 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
>>>
>>
>>
>> - --
>> Thomas Gideon
>> Sr. Staff Technologist, Open Technology Initiative
>> New American Foundation
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEAREIAAYFAk5Sjm0ACgkQ65xMDm9EZnOVJwCgm/Xp9YeNndgr+8TlDTrijQpp
>> iRYAn2MsSTqy8/F/YQsT75g6EKcc4Dwi
>> =oJMx
>> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> M-lab-ops mailing list
>
> http://mail.measurementlab.net/mailman/listinfo/m-lab-ops_measurementlab.net
>



Archive powered by MHonArc 2.6.16.

Top of Page