NDT-DEV email list created

[Thomas Gideon <>]

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

On 08/05/2011 02:13 PM, Jason Zurawski wrote:
> Hey Thomas;
> 
> Not to quibble (since this has already generated far more email and 
> panic than is healthy on a Friday afternoon), but it appears you
> backed out, then are still checking into trunk and not the fresh
> branch.

Yes, I failed to switch my local copy to the branch.

> In general "little changes" into the trunk are ok, "little" is a
> tough word to quantify though.  Single checkins to fix a typo for
> example, or documentation, I would call these things "little".  Based
> on the checkins you are making it looks like some things were
> untested (e.g. you missed a semi) so that makes me a little anxious.
> We don't want the trunk to be in a broken state, even if it is the
> bleeding edge.  For now, just continue.  Finish it off, alert us when
> done.  Kavitha: be sure you suck up these recent changes into your
> branches if you haven't done so.

I am making one more attempt to move these to the branch I created. It
has been a while (years) since I used svn on a regular basis. I
apologize for the thrash my rustiness has introduced into the history.

Kavitha: if you merge r466 to your branch, that should back out my small
set of changes for now so you don't have to worry about tracking any
further changes from my work. I work with you or whomever makes sense
down the line to re-merge my changes when it makes sense to do so.

> The rule of thumb that we use with all of our other repos is to
> follow the principal of least surprise:
> 
> - Single checkin to trunk w/ nice descriptive log message = good -
> Multiple checkins to trunk without clearing it = bad, even with log 
> messages - Branches = good - Branches where the changes are being
> moved back in to the trunk before a release = good, if you clear it
> with everyone
> 
> Sound good for ground rules?  Jeff will dig up a more formal
> treatment and pass it around if there is any confusion.

Makes sense and I will observe correctly in the future.


- -T

> On 8/5/11 1:54 PM, thus spake Thomas Gideon: 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/

iEYEAREIAAYFAk48NSMACgkQ65xMDm9EZnOtPACgumtheqjwx7LdJs3F8jNk51kn
gVIAnjf/OwPNwdVPwwnS9sOdHzWEFhZc
=PVjT
-----END PGP SIGNATURE-----