NDT-DEV email list created

[Thomas Gideon <>]

-----BEGIN PGP SIGNED MESSAGE-----
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 
>> 
>>  
>> http://mail.measurementlab.net/mailman/listinfo/m-lab-ops_measurementlab.net
>>

- --
>>
>> 
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/

iEYEAREIAAYFAk5Sqj4ACgkQ65xMDm9EZnNJuQCgrkzRxeZXoYtvadp064zsj3yu
VJIAoKQyHEcU8g46MAPlH76qi8CvPyVX
=Syq0
-----END PGP SIGNATURE-----