Hi David.

I just started to review your commit:
http://source.jalview.org/gitweb/?p=jalview.git;a=commit;h=4cea7a0328724b90a6a7c16ae8c926e0cc12cedd

I'm afraid it's really too big for me to review quickly, and now it's 
been pushed, there isn't much that can be done, except withdraw any of 
the patches in subsequent commits, which always looks a bit ugly in the 
project's source history. I guess that can't be helped this time, but I 
think we can do better.

As a general strategy for future commits, please get into the habit of 
committing much more frequently, rather than do several hours of work 
and commit all the lines in one go. I'm sure you know all this, but I 
thought it worth repeating anyhow.

Please also use an informative commit message ... '(basic i18 support)' 
is not enough, you actually need to explain specifically what you did 
and/or why you patched the code.

More specifically:
* if you used an i18n refactoring tool to replace bare strings with new 
i18n lookups for a set of classes in a package, say that (and include 
the package name).
* if you changed GUI logic in order to allow formatted i18n messages, 
say which part of the GUI was affected
* do not combine i18n changes from different parts of the GUI into one 
commit unless they are directly related (e.g. an identical bit of code 
and keys used in all GUI elements).

Generally, a commit is too large if you can't come up with a short 
sentence explaining the where/what/why of the commit (in the context of 
the JAL-XXXX issue).

If you have got lots of changes, then use an interactive commit tool to 
select specific hunks that relate to each other (e.g. applying i18n 
string extraction to a particular window, and then committing the 
updated GUI code and the new keys added to the Message bundle). Eclipse 
isn't particularly good at this type of commit, so I'd recommend you try 
using 'git gui' from the command line, or download Atlassian SourceTree 
(or if you have a Mac, try GitX, which is far simpler and about as good !).

One final thing to remember: commits should (wherever possible) not 
introduce compilation errors, and the compiled system should be more or 
less functional. If you have a series of interdependent commits, then it 
should be obvious from the commit message (one or more common JAL-xxxx 
ids, etc).

It is *extremely important* that you get into these habits, because 
otherwise, it takes me much longer to review your work, and it makes it 
much harder to identify new bugs introduced from your commits.

apologies if I sound hectoring !  Writing this email has prompted me to 
begin documenting the coding guidelines on the wiki ;)
Jim.





_______________________________________________
Jalview-dev mailing list
[email protected]
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev

Reply via email to