NDT-DEV email list created

["Jeff W. Boote" <>]

At this point, I'd probably prefer to take Thomas up on his offer to merge 
his changes in after we complete the code refactoring. That will give us both 
a 'known' state to be basing our work from.

Normally, I would agree with Jason's rules about minor changes being ok in 
trunk.

However, as I said earlier. Since we are doing full scale refactoring of the 
code I would prefer that not happen during this time.

thanks,
jeff

On Aug 5, 2011, at 1:20 PM, Kavitha Kumar wrote:

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