NDT-DEV email list created

[Kavitha Kumar <>]

Hi Thomas, Jason, everyone,

 I'd branched off from 
trunk@456.
 So, I actually did not get Thomas's commits (they were after 460) ; but 
thanks for letting me know the correct version to merge back to, Thomas!

I'll fetch these commits when they're merged back into a suitable location 
(or a similar action) after a decision on it. 

Thanks!
Kavitha


----- Original Message -----
| From: "Thomas Gideon" 
<>
| To: 

| Cc: "Jeff W. Boote" 
<>,
 
,
 "Kavitha Kumar" 
<>
| Sent: Friday, August 5, 2011 2:23:31 PM
| Subject: Re: [ndt-dev] Re: Commits to ndt
| -----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-----