NDT-DEV email list created

[Jason Zurawski <>]

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.

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.

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.

Thanks;

-jason

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