NDT-DEV email list created

[Thomas Gideon <>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/05/2011 01:45 PM, Jeff W. Boote wrote:
> Hi Thomas,
> 
> Does that mean you are done? If so, I'm fine with what is here - no 
> need to revert. If you have on-going work, then I'd like to talk and 
> coordinate that with you. I just wanted to get a good idea of the 
> scope of work you have going here.

I am not done but should be shortly. In the interest of harmony and to
allow me to commit at the granularity I personally prefer without
creating any more difficulties, I just went I ahead and backed out my
sole commit and created a new branch to house this work.

> I'm sorry, I'm just now going through and starting to clean this up 
> from a project/release-mgmt perspective and think about adding the 
> next release tag. I also should have sent something to the list to 
> say that we were starting some comprehensive work.

No worries, my eagerness to work on this long overdue change (plus a
head full of multiple source files in multiple languages) overrode my
common courtesy in a project owned by someone else. I am grateful you
were much more on the ball and cut this pretty much as it happened
rather than multiple interleaved commits down the line.

> The work we are starting will restructure most of the code, so 
> functions and files will be moving around a lot. This will make 
> merging much more complicated and difficult than a normal
> development cycle which is why it is a good idea for me to find out
> what on-going or pending work people are currently doing.

The scope of the change is small, just adding another field to the meta
file. I am following the changes made a few months back to do this for
the browser info. I am also trying to make it reverse compatible,
testing in a personal sandbox on mlab4.nuq01, to make a rollout a bit
more flexible.

> So... Lets just make this a call for all developers to please let me 
> know if you have outstanding commits or ongoing work you plan to do 
> in the next 2-3 months so we can coordinate it.

Once this is tested and complete, we can discuss release timing. This
has been on the list of asks from Google for a while so I'd prefer to do
it sooner rather than later. If we had a maintenance branch (or could
create one retroactively) for the current stable version (assuming it
includes the browser info changes), that would be a sane merge target if
we could get these changes out before the larger set on which I know I2
is working.

I don't mind personally doing the work to re-merge these changes after
I2 is finished with the re-org/cleanup if the relevant files change
substantially.

Sorry, again, for not thinking before committing and thank you for
catching my mistake so quickly.


Thomas

> On Aug 5, 2011, at 11:21 AM, Thomas Gideon wrote:
> 
> On 08/05/2011 01:12 PM, Jeff W. Boote wrote:
>>>> 
>>>> Can I ask who this is? (Your email address is not very 
>>>> informative in this sense.)
> 
> Sorry, it is Thomas from OIT/NAF.
> 
>>>> I'm curious what changes you are committing to trunk? What is 
>>>> the scope here? Typically changes should be discussed with the
>>>>  developers before being committed to trunk. I would expect
>>>> you to commit them to a branch and then suggest them for
>>>> inclusion in the next release. We are actively modifying the
>>>> code for a planned release right now, and do not want things
>>>> changing in trunk causing undue time merging.
> 
> The changes are to add an identifying string that each client can
> set so that collected data can be divvied out by which client ran
> the test, if desired.
> 
> Apologies, I should have pinged you to coordinate these changes. They
> seemed so small, very similar to the client browser changes that I
> didn't think about the impact on other active development.
> 
> I can back out my changes, branch from r394, and re-commit my
> changes to that branch.
> 
>>>> I would appreciate it if you would create a branch for
>>>> whatever your ongoing work is, and communicate with the rest of
>>>> the developers before merging things into trunk.
> 
> Again, I didn't think the changes were intrusive and there is no tag 
> for a release later than 3.6.1. That release doesn't include the 
> client browser meta data changes from which I was basing the client 
> application metatdata changes. Ideally we'd like to stage an 
> incremental updated that adds the client identifier ASAP if at all 
> possible so that Tizian Refice at Google can adjust her data parsing 
> and we can get the client identifier into the data stream sooner 
> rather than later.
> 
> 

- -- 
Thomas Gideon
Sr. Staff Technologist, Open Technology Initiative
New America Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREIAAYFAk48LmwACgkQ65xMDm9EZnOLUgCghHnhTmECOHnDou6lbnfhIPnj
emQAnilVCLjXJ3t6onQ3N0QWM8vM3ekl
=AtwF
-----END PGP SIGNATURE-----